Fixing the System.IO.FileLoadException Upon Building An Application Using A Downloaded Assembly

If you ever download applications or assemblies from CodePlex or other open source communities that were originally zipped up (.zip) and either contain references to additional assemblies within or reference the assembly in one of your own applications, you may run across the following 'System.IO.FileLoadException' exception upon building the application in VS.NET:

"System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Dev\TestApp\Components\Some3rdParty.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) File name: 'file:///C:\Dev\TestApp\Components\Some3rdParty.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 http://go.microsoft.com/fwlink/?LinkId=155569 for more information."

As you can see the exception message is recommending a link on how to fix this error. The link refers to a <loadFromRemoteSources> element within the <runtime> parent element in the application's configuration file. The IDE thinks that this resource is being loaded from a network drive or a non-sandboxed environment and is trying to protect you the developer and the application from security risks.

However you can see within the exception I posted that the .dll is located within the project on a local drive. So adding any additional configuration here is not what I wanted to do.

In reality what has happened is that the .dll I extracted from the original .zip that I downloaded from Codeplex was already built (in this case it’s a 3rd party assembly and I do not have the source for it to recompile) and was automatically marked as coming from "another computer" and might be a security risk. The compiler will not allow the application to successfully build in this state with the security flag.

Removing the security flag is simple. Just navigate to the file in Windows Explorer and right-click it to view its properties. On the main tab at the bottom you will see the following:


Simply press 'Unblock' and then close the Properties window. Now rebuild your application in VS.NET and you should no longer see the exception.
I see the problem most often with using the pre-built AjaxControlToolkit.dll that comes from the .zip downloaded from CodePlex as well. However, you would not see this issue if you have the actual source code and compile the .dll yourself prior referencing.