Resolution: Error "Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. (0x80131515)


Call to a .NET Framework assembly on a network folder fails with error:

"Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)


In this particular case, I wanted to call an assembly with tests which had been deployed using Team Build to a shared folder, then use MSTest in the command line to run them.

MSTest behaved differently depending on whether it is being called from a Windows 2008 R2 Standard server or Windows 8 Client. Using the following command line:

MSTest /testcontainer:\\server\path\file.dll /detail:debugtrace /detail:traceinfo

  • From Windows 8 client, user as local administrator: command works as expected. It loads the tests and executes them.
  • From Windows 2008 R2 Standard, user as a local administrator: command fails with the following message:

Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

Further troubleshooting using 1) a mapped drive 2) PowerShell 3) /testcontainer parameter between quotes show that all these would also fail under Windows 2008 R2 Standard.

The error “Could not load file or assembly” (0x80131515) is a catch-all error. For instance, it is also reported when the exe or dll was downloaded from an unsafe zone. This is fixed by right-clicking the assembly and choosing “Unlock” from the General tab. Sometimes the “Unlock” option won’t show, and in this case it wasn’t.

Blocking is done based on a Zone Identifier alternate stream that is added to a file when it is copied from the Internet. To validate that the file is actually blocked, display this Zone Identifier using the following command (note the direction of the “<” sign – the opposite one would erase the file):

more < file.dll:Zone.Identifer

If ZoneId = 3 or 4, your file is blocked. In our case, the files show no alternate Zone.Identifier stream.

Since copying the files locally to a folder in the Window 2008 R2 Standard server allowed MSTest to execute the tests, this showed that the issue was constrained to some security policy differences between Windows 8 and Windows 2008 R2 Standard. This also confirmed that the files were not blocked.

Next step I looked into the .NET Framework security policy configuration. Using the instructions from this Microsoft blog post I modified the CAS policy settings using the following command prompt:

CasPol.exe -m -ag 1.2 -url file://\\server\path\file\* FullTrust

This added the following record into the CAS policy (CasPol.exe -l):

   1.2.  Zone - Intranet: LocalIntranet
      1.2.1.  All code: Same site Web
      1.2.2.  All code: Same directory FileIO - 'Read, PathDiscovery'
      1.2.3.  Url - file://\\server\path\file\*: FullTrust

This did not resolve the issue as expected, but the following error started to be reported on the Event log:

Log Name:      Application
Source:        VSTTExecution
(MSTest, PID 2000, Thread 1) AssemblyEnumerator.EnumerateAssembly threw exception: System.IO.FileLoadException: Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

File name: 'file://\\server\path\file.dll' ---> 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 for more information.

By following the link recommended in the log, I got more information on the issue and how to solve it with the configuration switch loadFromRemoteSources.

From MSDN documentation:

“In the .NET Framework version 3.5 and earlier versions, if you loaded an assembly from a remote location, the assembly would run partially trusted with a grant set that depended on the zone in which it was loaded. For example, if you loaded an assembly from a website, it was loaded into the Internet zone and granted the Internet permission set. In other words, it executed in an Internet sandbox. If you try to run that assembly in the .NET Framework version 4 and later versions, an exception is thrown; you must either explicitly create a sandbox for the assembly (see How to: Run Partially Trusted Code in a Sandbox), or run it in full trust.

The <loadFromRemoteSources> element lets you specify that the assemblies that would have run partially trusted in earlier versions of the .NET Framework are to be run fully trusted in the .NET Framework 4 and later versions. By default, remote assemblies do not run in the .NET Framework 4 and later […]. If you set enabled to true, remote applications are granted full trust.

If <loadFromRemoteSources> enabled is not set to true, an exception is thrown under the following conditions:

  • The sandboxing behavior of the current domain is different from its behavior in the .NET Framework 3.5. This requires CAS policy to be disabled, and the current domain not to be sandboxed.
  • The assembly being loaded is not from the MyComputer zone.”

And, in the same article:

In the .NET Framework 4.5, assemblies on local network shares are run as full trust by default; you do not have to enable the<loadFromRemoteSources> element.

This part of the documentation also shows why it worked on Windows 8: .NET Framework 4.5 is the default for Windows 8.

For validation purposes, I originally applied the recommended setting to machine.config, which is too wide. Later I tested with just MSTest.exe.config and it also worked, which is a smaller recommended scope.


[Verified] Add the following entry to the MSTest.exe.config file (at C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE):

      <loadFromRemoteSources enabled="true"/>


[According to documentation] Use .NET Framework 4.5.

Comments are closed


<<  January 2018  >>

View posts in large calendar

Month List