How to Use .Net 4.0 ?

[dhdurgee]

Interesting. I tried adding '' to the front of my ⎕USING and the behavior changed. With only the System.Device.Location entry I get the value error without a status message. After I added '' I still get the value error, but I now get a status message of:

Could not load file or assembly 'file:///C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\System.Device.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

The status message is repeated twice.

Adding '' and 'System' still yields a value error with the same status message.

Adding only 'System' yields a value error without the status message. So it appears that having the '' is what is causing the change in behavior here.

I also thought to try this as:

HOME←⎕NEW Location.GeoCoordinate

with ⎕USING set to only the System.Device.Location entry. This yields a value error with a single copy of the same status message.

My program shortcut points to "C:\Program Files\Dyalog\Dyalog APL 12.1 Unicode\dyalog.patched.exe", so I created "C:\Program Files\Dyalog\Dyalog APL 12.1 Unicode\dyalog.patched.config.exe" with the code PGilbert posted on 11 October. So it looks like I am still missing something here.

Any further suggestions?

Dave

[MikeHughes]

You usually get that message because .Net 4 has not been loaded by Dyalog and you are using an earlier version of .Net.
You should have the config file suggeseted by Pierre in the same directory as the dyalog.exe that is invoked

(ie) The file is called Dyalog.exe.config and it contains

<?xml version ="1.0"?>
<configuration>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true"/>
</runtime>

<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319" />
</startup>
</configuration>

[MikeHughes]

I forgot to say the file Dyalog.patched.exe is not the interpreter file per se. When you run the patch workspace then the new Dyalog.exe file downloaded is called Dyalog.patched.exe because patch is running using the old Dyalog.exe so it cant be replaced directly.

When patch has finished
The current Dyalog.exe needs to be backed up and deleted
Dyalog.patched.exe should be renamed to Dyalog.exe
and the config file should be named Dyalog.exe.config - NOT Dyalog.patched.exe.config as in my previous post.

The the next call to Dyalog.exe should invoke .Net4 as required

[AndyS|Dyalog]

On the patching side of things .. one of the advantages of using the Patch Wizard shortcut rather than just )LOADing the PATCH workspace is that the Wizard uses $DYALOG\Base\dyalog.exe .. so (unless you've got other Dyalog sessions running) you can update $DYALOG\dyalog.exe without having to go through the rigmarole of exiting Dyalog and renaming the executable. And if you're on Vista or W7, you can alter the permissions so that you don't have to remember to Run As Administrator each time.

[dhdurgee]

I renamed the file from *.config.exe to *.exe.config and now I appear to have access to .Net 4.0 as I am able to instantiate the class I was previously unable to use. Unfortunately I now seem to have other problems.

One of the tools I have been using in this testing I copy/pasted directly from the "web scraping" example on page 23. Now that I have activated .Net 4.0 I am getting an exception thrown at the WebRequest.Create step as follows:

Message: Configuration system failed to initialize
Source: System.Configuration
StackTrace:
at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
at System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(String sectionName)
at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
at System.Configuration.ConfigurationManager.GetSection(String sectionName)
at System.Configuration.PrivilegedConfigurationManager.GetSection(String sectionName)
at System.Diagnostics.DiagnosticsConfiguration.GetConfigSection()
at System.Diagnostics.DiagnosticsConfiguration.Initialize()
at System.Diagnostics.DiagnosticsConfiguration.get_Sources()
at System.Diagnostics.TraceSource.Initialize()
at System.Net.Logging.InitializeLogging()
at System.Net.Logging.get_On()
at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
at System.Net.WebRequest.Create(String requestUriString)

The URI I was using in this particular case was:

http://local.yahooapis.com/MapsService/ ... r%2C+20877

I have used this successfully in the past, so this is puzzling.

As a test I shut down Dyalog, renamed the '*.exe.config' to '*.exe.confug' and restarted Dyalog. After doing so the "web scraping" code is working as designed.

This is certainly a problem, but whose?

Dave

[dhdurgee]

Found my error and corrected it. Turns out my *.exe.config file was erroneous and causing the problem.

Dave

[RossHale]

I have been revisiting using .Net 4.0 with Dyalog APL v13.0 Unicode and using xml config file Dyalog.exe.config
to specify .Net 4.0.
This works well in general execept for WPF assemblies such as PresentationFramework.dll.
Except for WPF, it is simple to just specify .Net NameSpace and assembly .dll pairings in ⎕using and life is good.

My efforts at tinkering with Dyalog.exe.config to get WPF assemblies handled as graciously as the rest
indicated that entries without specific lead directory specifications were being resolved through
the system windows directory and down through Microsoft.NET directory such as
C:\Windows.NET\Framework\Framework\v4.0.30319 or
C:\Windows.NET\Framework\Framework64\v4.0.30319 for 64 bit flavor.
Both of these have a sub folder (directory) WPF for the Windows Presentation Foundation assemblies.

Now the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
folder contains both WPF and all the (nearly) rest of the .Net 4.0 assemblies,
so that an explicit full directory and file reference will succeed if so given to ⎕using.

A little helper function allows specifying ⎕using without providing leading directory specs for WPF assemblies.
After specifying ⎕using, just filter ⎕using to add the WPF directory to any WPF assemblies.

Code: Select all

mark←{
     ⍺←'v4.0'
     ⎕USING←'' 'System' 'System.IO'
     windows←Environment.GetFolderPath Environment.SpecialFolder.Windows
     path←windows,'\Microsoft.NET\Framework',(∧/Environment.(Is64BitOperatingSystem Is64BitProcess))/'64'
     netpath←⊃(∨/⍺⍷↑folders)/folders←Directory.GetDirectories⊂path  ⍝ desired .net version folder
     di←⎕NEW DirectoryInfo(⊂WPF←netpath,'\WPF')                     ⍝ expect WPF folder to exist
     files←⊂di.GetFiles(('*.dll')SearchOption.TopDirectoryOnly)     ⍝ .dll assemblies in WPF folder
     check←{
         ~','∊⍵:⍵                        ⍝ pass through if assembly not specified
         lead←(⌽∨\⌽⍵=',')/⍵              ⍝ lead is namespace and comma
         assembly←(⍴lead)↓⍵              ⍝ assembly name follows comma
         ~∨/mask←(⊂assembly)⍷⍺.Name:⍵    ⍝ pass through if assembly not in WPF folder
         lead,,↑(mask/⍺).FullName        ⍝ expand assembly with FullName (includes directory)
     }
     files check¨⍵
 }


Example of use:

Code: Select all

      ⎕using←'' 'System' 'System.IO' 'System.Windows,PresentationFramework.dll'
      ⎕using
   System  System.IO  System.Windows,PresentationFramework.dll
      mark ⎕using
   System  System.IO  System.Windows,C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll
      'v4.0' mark ⎕using
   System  System.IO  System.Windows,C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll
      ⎕using←'v4.0' mark ⎕using ⍝ make the change



The mark function tries to choose between 32bit and 64bit libraries by checking .Net Environment
and pretends to allow choosing .Net versions, but .Net v3.5 does not keep WPF in quite the same cubbyholes
as does .Net v4.0. The code is simple in concept but a little rough in going back and forth twixt .Net and APL.

Perhaps others can see a better way...