24

I've recently set up a new Windows Server 2012 R2 environment and installed Visual Studio 2012.

Now I'm having a problem with multiple .NET 4.5 project's I migrated from my old server, a Windows Server 2008 machine. This never occurred on the old server.

When trying to load an assembly from a network location, I run into the following issue:

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=155569 for more information.

I've looked at some other questions, but none of them provide a working solution.

This is what I've tried so far:

  • Added the loadFromRemoteSources switch to devenv.config, XDesProc.exe.appx.config and XDesProc.exe.config.
  • Checked whether the assembly was blocked, which it wasn't.
  • Tried using the CasPol utility, even though this only applies to pre .NET 4.0 projects.

All without success.

Is there another solution to solve this problem?

Stijn
  • 1,970
  • 3
  • 27
  • 36

2 Answers2

53

Adding the loadFromRemoteSources switch to machine.config solved the problem.

MSDN

The loadFromRemoteSources element specifies whether assemblies from remote sources should be granted full trust.

Example

<configuration>
    <runtime>
       <loadFromRemoteSources enabled="true"/>
   </runtime>
</configuration>

You can find machine.config here:

32-bit

%windir%\Microsoft.NET\Framework\[version]\config\machine.config

64-bit

%windir%\Microsoft.NET\Framework64\[version]\config\machine.config
Community
  • 1
  • 1
Stijn
  • 1,970
  • 3
  • 27
  • 36
  • Curiously, the machine.config file on the old Windows Server 2008 machine does not contain the `loadFromRemoteSources` switch. My guess is it might have something to do with VS 2008 and VS 2010 being installed on that machine, before VS 2012. This is not the case on the Windows Server 2012 machine. – Stijn Feb 05 '15 at 08:32
  • much thank! I used profiler to see which Machine.config was being loaded, then made the change. It worked – Dennis Jan 22 '16 at 18:00
  • 7
    Adding to `machine.config` broke nuget. Adding to `app.config` worked. –  Feb 06 '17 at 18:07
  • 2
    This is not a valid and safe answer. The problem is probably about a compressed file downloaded from the internet, the solution is to simply unlock the zip like @Piper mentioned. – Julian Corrêa Oct 14 '21 at 13:11
  • 1
    This "solution" will broke your .NET Framewrok on Windows, with all sorts of strange "bugs" (errors in Visual Studio, VS Installer, etc.). If your reading this in 2021+ don't do this! – Petr Abdulin Oct 27 '21 at 07:31
  • 1
    Based on the comment from @PetrAbdulin above, I used the 'Unblock' method in the answer below this and it worked perfectly. Adding `loadFromRemoteSources` to the `machine.config` is _**DEFINITELY NOT**_ the way to resolve this issue. That will leave your machine vulnerable to nefarious files downloaded from a remote source. – Todd Powers Nov 16 '21 at 19:03
  • This worked for me. I was getting the error when trying to add a migration using EF Add-Migration command – Waheed Bhatti Sep 17 '22 at 22:25
20

I had the same problem, when trying to load a DLL on a local drive which came from a ZIP from the internet. The solution was to unlock the ZIP in its file properties. Finally, extracting the DLL again and now it loads without the error. No need to change the machine.config.

Piper
  • 851
  • 11
  • 14
  • 3
    This worked for me, although I got the "Unblock" option on the extracted DLLs and not the zip. – Fahad Sep 22 '20 at 15:07
  • Where I can find this "Unblock" property? – Dovchik Nov 18 '20 at 14:59
  • 1
    [Here](https://singularlabs.com/tips/how-to-unblock-a-zip-file-on-windows-10/) is a good description. – Piper Nov 19 '20 at 16:33
  • 1
    In my case the problem was that the files were being copied from another machine and they got "blocked" by Windows. Using this powershell command solved the issue: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/unblock-file?view=powershell-7.1 – xautau Sep 07 '21 at 09:42