As you're probably mostly aware, many of our 2012 products use .NET 4 as standard. This has proven "interesting" (i.e. challenging) when it comes to loading – for example – plugin DLLs downloaded from the web, due to .NET's updated security model.
Our ADN Plugins of the Month on Autodesk Labs are a prime example: most were posted prior to AutoCAD 2012 shipping, but when downloaded locally and NETLOADed into AutoCAD 2012, very often a security error gets reported:
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.
It also happens in our other products making use of .NET 4 (Revit, in particular).
This is now by far the most common problem reported regarding these plugins, in spite of efforts to document the problem and the solution. (There's also some helpful information on MSDN, in case.)
When this problem first arose, it took a while for it to be understood (by me, at least). If you build the DLLs locally, clearly there isn't a problem. And if *.autodesk.com happens to be in your trusted sites zone in Internet Explorer (which it is for most Autodesk employees, understandably) then the issue doesn't happen, either. Luckily it doesn't occur for the Exchange Store as every app is wrapped in a simple installer and so doesn't suffer from this issue.
Anyway, to make life easier when working with these plugins, I make use of a little trick – modifying acad.exe.config, to add the loadFromRemoteSources element – to stop the issue from occurring. Here's my current acad.exe.config, which also includes the change to reduce debugger output noise mentioned previously:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
<system.diagnostics>
<sources>
<source name="System.Windows.Data" switchName="SourceSwitch">
<listeners>
<remove name="Default" />
</listeners>
60; </source>
</sources>
</system.diagnostics>
</configuration>
The loadFromRemoteSources change works well for Revit, too. Interestingly it doesn't have any effect in Inventor 2012, which is still using .NET 3.5.
One other important thing to note: this allows you to load .NET assemblies from network locations, something that has been an issue for a long time. This is especially needed now that I'm working inside Parallels on my MacBook Pro: I don't store data inside my Windows 7 installation, I leave it on the native hard-drive which gets mapped through to Windows as a network location. Which means I can now load .NET DLLs from that drive into AutoCAD and Revit (but not into Inventor, as yet).
I will say that making this change could potentially leave your (or – more importantly – your users') system(s) more open to the execution of malicious, so make it at your own risk.
Leave a Reply to Jerad Cancel reply