The Microsoft .NET Framework is a programming and run-time environment that runs on Microsoft Windows. Programs written for the .NET Framework execute in a software environment known as the Common Language Runtime (CLR). The CLR is an application virtual machine instead of accessing the hardware directly. A program written for .NET requires that the .NET framework must be installed before the new program can run. source: wikipedia.org
Many of the Autodesk Developer Network Plugins of the Month are developed using the .NET framework. In an email exchange with a customer who was having trouble loading the Room/Door Renumbering Plugin for Revit, Senior Manager, Worldwide DevTech, Kean Walmsley, noted:
Many of the 2012 family of products use version 4 of the .NET Framework. .NET 4.0 implements slightly more stringent security than prior versions of the framework: if a Dynamically Loadable Library (DLL) is suspected as having been downloaded from the web – as is clearly the case with our “Plugins of the Month” – the .NET 4.0 runtime will treat that DLL as if it has been loaded from a network share. And as many of you have found out, from trying to load DLLs from network shares, this results in a reduced set of privileges on the local machine, which can often result in a load error such as this one:
Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Program Files\Autodesk\AutoCAD 2012 – English\ADNPlugin-QRCodes.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) File name: 'file:/// C:\Program Files\Autodesk\AutoCAD 2012 – English\ADNPlugin-QRCodes.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.
The CLR has less control over hardware that is not local. Kean recommended a solution:
The solution is straightforward: you simply need to “Unblock” the DLL by right-clicking on it in Explorer and selecting “Properties” and “Unblock”. It’s actually better to do this for the .ZIP prior to extracting the contents, as this makes sure all files contained in the archive are unblocked. For example, if you were to do this for the QRCodes for AutoCAD plugin:
Thanks Kean. You can peruse the current and past Plugins of the Month:
We always enjoy hearing from you at email@example.com.
Putting fiber in the Windows CLR diet is alive in the lab.