.NET 4.0 introduces some nice changes that makes it easier to run .NET EXE type applications directly off network drives. Specifically the default behavior – that has caused immense amount of pain – in previous versions that refused to load assemblies from remote network shares unless CAS policy was adjusted, has been dropped and .NET EXE’s now behave more like standard Win32 applications that can load resources easily from local network drives and more easily from other trusted remote locations.

Unfortunately if you’re using COM Interop or you manually load your own instances of the .NET Runtime these new Security Policy rules don’t apply and you’re still stuck with the old CAS policy that refuses to load assemblies off of network shares. Worse, CASPOL configuration doesn’t seem to work the way it used to either so you have a worst case scenario where you have assemblies that won’t load off net shares and no easy way to adjust the policy to get them to load.

However, there’s a new quick workaround, via a simple .config switch:

<configuration>
 <startup>    
    <supportedRuntime version="v4.0.30319"/>   
    <!-- supportedRuntime version="v2.0.50727"/-->    
  </startup>
  <runtime>
      <loadFromRemoteSources enabled="true"/>
  </runtime>
</configuration>

This simple .config file key setting allows overriding the possible security sandboxing of assemblies loaded from remote locations. This key is new for .NET 4.0, but oddly I found that it also works with .NET 2.0 when 4.0 is installed (which seems a bit strange). When I force the runtime used to 2.0 (using the supporteRuntime version key plus explicit loading .NET 2.0 and actively checking the version of the loaded runtime) I still was able to load an assembly off a network drive. Removing the key or setting it to false again failed those same loads in both 2.x and 4.x runtimes.

So this is a nice addition for those of us stuck having to do Interop scenarios. This is specifically useful for one of my tools which is a Web Service proxy generator for FoxPro that uses auto-generated .NET Web Service proxies to call Web Services easily. In the course of support, I would say a good 50% of support requests had to do with people trying to load assemblies off a network share. The gyrations of going through CASPOL configuration put many of f them off altogether to chose a different solution – this much simpler fix is a big improvement.

Security policy management is pretty damn confusing and I’m thankful that .NET 4.0 makes this at least a little simpler. If you’re interested in more background and the implications of .NET 4.0 on sandboxing and security policy, this post on the .NET Security Blog goes into much more detail – enough to make my head spin. Some of this seems really confusing, but the bottom line is that the above switch allows allows your applications to override the settings when appropriate. Options are good… Phew.