AutoCAD has provided so called AutoLoader for a while. It is announced to be environment friendly (no need to mess up the Windows Registry anymore), support multiple versions, support both AutoCAD and its flavors (such as AutoCAD Mechanical and AutoCAD Architecture) at the same time in a single place, support various AutoCAD applications such as .NET, ARX, DBX, and AutoLISP, support multiple Operating Systems (such as Microsoft Windows 64, Microsoft Windows 32, and even Apple Mac), and more.
It sounds huge and complex, but in fact, it is nothing but an XML file that is supposed to specify what the application/addin/plugin is, what it does, and what it needs. That is about it in a single sentence.
Though simple, it has many subtle details for us to sort out due to lack of good documentation, not open at all the AutoLoader schema if any, and far from set yet at this time. Thus, mysteries about the AutoLoader are here and there in spite that the XML format itself is not a thing at all to most developers.
As demonstrated previously, the relative ModuleName works well for the .NET assembly.
ModuleName=".\Application\TestApp.dll"
However, many times, people do not want to put their assemblies under the ApplicationPlugins folder. Instead, they may want to use an absolute and full path like the following:
ModuleName="C:\Temp\TestApp\bin\Debug\TestApp.dll"
Does it work?
Let’s do a small experiment to sort it out. Copy and paste the following XML content to a file and name it as PackageContents.xml first.
<?xml version="1.0" encoding="utf-8"?>
<ApplicationPackage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
HelpFile="./Application/UsersGuide.chm"
OnlineDocumentation="spiderinnet1.typepad.com"
Name="TestApp"
Description=""
Icon="./Application/app.ico"
Author="spiderinnet1">
<CompanyDetails Name="nss"
Url="http://spiderinnet1.typepad.com"
Email="spiderinnet1@nss.com">
</CompanyDetails>
<Components>
<RuntimeRequirements OS="Win64" Platform="AutoCAD" SeriesMin="R18.0" SeriesMax="R18.2" />
<ComponentEntry
ModuleName="C:\Temp\TestApp\bin\Debug\TestApp.dll"
LoadOnAutoCADStartup="false"
LoadOnCommandInvocation="true"
AppDescription="This is assembly TestApp."
AppName="TestApp"
AppType=".NET">
<Commands GroupName="CmdGroup1">
<Command Local="Command1" Global="Command1" />
</Commands>
</ComponentEntry>
</Components>
</ApplicationPackage>
Then please create a folder and put the AutoLoader into it:
C:\Program Files\Autodesk\ApplicationPlugins\TestApp.bundle\
Next, make sure the TestApp.dll is located as is specified in the AutoLoader.
Now we launch AutoCAD 2012 and run the command:
Command: COMMAND1
Demand load failed due to missing module:
Name: TestApp
Description: This is assembly TestApp.
Module Path: C:\Program Files\Autodesk\ApplicationPlugins\TestApp.bundle\C:\Temp\TestApp\bin\Debug\TestApp.dll
Demand load failed due to missing module:
Name: TestApp
Description: This is assembly TestApp.
Module Path: C:\Program Files\Autodesk\ApplicationPlugins\TestApp.bundle\C:\Temp\TestApp\bin\Debug\TestApp.dll
Unknown command "COMMAND1". Press F1 for help.
So apparently, AutoCAD tries to append the ModuleName regardless of relative or absolute to the folder where the AutoLoader (ApplicationPackage) resides, thus the failure occurs.
Absolute module path may not seem a good idea always, but what about adding one more attribute like RelativePath or WhatDotInPathRepresents to the ApplicationPackage element and making it optional. In this way, both consistency and flexibility can be guaranteed.
By the way, the TestApp project and the sample command were all generated by the leading edge AutoCAD .NET Addin Wizard (AcadNetAddinWizard) automatically in a moment. AcadNetAddinWizard provides various project wizards, item wizards, coders including a Ribbon Creator, and widgets to help program AutoCAD .NET addins.
Posted by: |