10

My problem begins with moving a .Net 2.0 application to .Net 4.0. The reason I had to do this was that Windows 8 does not enable the earlier .Net versions by default and my application cannot ask the user to enable it.

The application is a NPAPI plugin which uses .Net components via UnmanagedExports. I designed it as a low integrity application and therefore it has to reside in the users 'LocalLow' directory.

In my application I used a dynamic assembly loading mechanism to load several assemblies at runtime. I used the following method to load an assembly,

MyInterface Instance;

Assembly assembly = Assembly.LoadFrom(AssemblyFile);
Type type = assembly.GetType(Identifier); // Identifier is implementing the MyInterface 
Instance = Activator.CreateInstance(type) as MyInterface;

// Do something with the Instance

After modifying the project to .Net 4.0, I noticed that the plugin crashes when the binaries are placed inside the LocalLow directory (It works in other places). My next step was to create a minimalistic plugin with least possible code to figure out the issue. I noticed that the dynamic assembly loading failed with the following exception,

System.IO.FileLoadException: Could not load file or assembly '<assemblyPath>' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515 (COR_E_NOTSUPPORTED)) --->

System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=131738 for more information.

I tried the following approaches to create a separate domain and load the assemblies but with no luck,

Adding the configuration 'loadFromRemoteSources' did not work either. It seems that the .Net component does not load .dll.config files. (Could be because of UnmanagedExporting)

My questions are,

  • Is it possible to dynamically load an assembly from LocalLow?
  • Does the new CAS policy in CLR 4.0 apply to LocalLow as well? From what I understood so far it should affect only assemblies loaded over the network
  • Is there any other way to overcome this issue?
Isuru
  • 594
  • 1
  • 5
  • 19
  • 1
    Why are you in LocalLow? That is a directory which is specifically secured to be writable by untrusted applications (Low integrity processes). It is probably viewed as a "Network Location" due to it's use for Internet Explorer and other browsers, but it could just be a MOTW on the dll. – Mitch Oct 29 '13 at 21:08
  • The reason why I had to switch to LocalLow is because Internet Explorer blocks access to all other paths when running a plug-ins, especially if we are writing to files, [check this link](http://www.codeproject.com/Articles/18866/A-Developer-s-Survival-Guide-to-IE-Protected-Mode#writingfiles). The only option was to use LocalLow. – Isuru Oct 30 '13 at 05:09
  • 1
    exactly my point. By virtue of it being writable to plugins, .Net is blacklisting it from loading an assembly. LocalLow is for files which need to be written *by* plugins, not for the plugins themselves. Locate the plugin in another directory (Program Files comes to mind) and write your temporary data files to LocalLow. – Mitch Oct 30 '13 at 18:35

1 Answers1

1

While it doesn't address your LocalLow issue specifically, if you are able to "read a file" from the directory, you might be able to use the "work around" detailed here: How can I get LabView to stop locking my .NET DLL?

Community
  • 1
  • 1
Aerophilic
  • 885
  • 2
  • 9
  • 22