When you first get into .net API programming – for AutoCAD plugins, you learn this cardinal rule: make sure the three AutoCAD dlls you refer to have copy local set to false.
Why exactly is this the case? I couldn’t find a better answer than the one offered by Fenton Webb. Here it is in full:
Take a second to look at the AcMgd.dll and AcDbMgd.dll in this folder…. Do you notice that they are much smaller than the ones in the AutoCAD installation folder? There is a big reason for this which is that since the 2010 release of the ObjectARX SDK, we have “liposuctioned” the managed reference DLL’s. I say “liposuctioned” because we literally sucked out the body of the code from each function in the assembly DLL. What we did to create these DLL’s was to actually ILDASM (MSIL disassemble) the original DLL’s, strip all the body code from them and then reassembled them using ILASM (MSIL assembler). OK, now why on earth would we do that, right? Let me explain: the WPF UI designer (and indeed the WinForms designer) in Visual Studio is pretty cool in that it does a great job of showing the design of the UI on screen obviously. The problem is that the designer does like a half-hearted parse of the code behind that controls the UI in order to work out things like how it’s displayed for instance, which when we reference the external AutoCAD managed DLL’s can cause unresolved dependency errors and thus stop the VS Designer from working properly. These dependency errors are caused by the fact that the ac*mgd.dll’s depend on acad.exe which of course the VS Designer finds impossible to load in order to resolve the dependencies. By using the “liposuctioned” assemblies in your project, all of the object definitions are in place to resolve designer parsing issues. You’ll be glad to hear that it still compiles, and loads too! Just as long as you keep the Reference property “Copy Local” set to false for each DLL.
(Taken from Fenton’s WPF AutoDesk University course notes).
Leave a Reply