Topic: PackageContents.xml

[BlackBox]

I am relatively new to the Autoloader system... Thus, I made the mistake of making my PackageContents.xml more 'wordy' than it needed to be, and after reading this Autoloader White Paper I thought I'd share to help others avoid a similar issue.

The original method I used works, it's can just be done in +/-half the original XML, as you'll see.

Here's what I started with:

Code - C#: [Select]

1. <?xml version="1.0" encoding="utf-8"?>
2. <ApplicationPackage
3.         AppVersion="1.0.0.1"
4.         Author="Autodesk Developer Network"
5.         Description="ArxDbg"
6.         Icon=" "
7.         Name="Autodesk DWG ArxDBG"
8.         ProductType="Application"
9.         SchemaVersion="1.0"     >
10.         <CompanyDetails
11.                 Name="Autodesk"
12.                 Email="AutoCAD.apps@autodesk.com" />
13.         <Components>
14.                 <RuntimeRequirements
15.                         OS="Win32"
16.                         Platform="AutoCAD|Civil3D|Map|AIS|ADT|ACADM|MEP|ACADE|PNID|Plant3D|Civil|LDT"
17.                         SeriesMin="R18.2"
18.                         SeriesMax="R18.2" />
19.                 <ComponentEntry
20.                         AppName="Autodesk DWG ArxDBG"  
21.                         AppDescription="ArxDbg"
22.                         ModuleName="./Contents/Windows/2010/Win32/ArxDbg.2010.arx"
23.                         Version="1.0.0.1" />
24.         </Components>
25.         <Components>
26.                 <RuntimeRequirements
27.                         OS="Win64"
28.                         Platform="AutoCAD|Civil3D|Map|AIS|ADT|ACADM|MEP|ACADE|PNID|Plant3D|Civil|LDT"
29.                         SeriesMin="R18.2"
30.                         SeriesMax="R18.2" />
31.                 <ComponentEntry
32.                         AppName="Autodesk DWG ArxDBG"  
33.                         AppDescription="ArxDbg"
34.                         ModuleName="./Contents/Windows/2010/Win64/ArxDbg.2010.x64.arx"
35.                         Version="1.0.0.1" />
36.         </Components>
37.         <Components>
38.                 <RuntimeRequirements
39.                         OS="Win32"
40.                         Platform="AutoCAD*"
41.                         SeriesMin="R19.0"
42.                         SeriesMax="R19.1" />
43.                 <ComponentEntry
44.                         AppName="Autodesk DWG ArxDBG"  
45.                         AppDescription="ArxDbg"
46.                         ModuleName="./Contents/Windows/2013/Win32/ArxDbg.2013.arx"
47.                         Version="1.0.0.1" />
48.         </Components>
49.         <Components>
50.                 <RuntimeRequirements
51.                         OS="Win64"
52.                         Platform="AutoCAD*"
53.                         SeriesMin="R19.0"
54.                         SeriesMax="R19.1" />
55.                 <ComponentEntry
56.                         AppName="Autodesk DWG ArxDBG"  
57.                         AppDescription="ArxDbg"
58.                         ModuleName="./Contents/Windows/2013/Win64/ArxDbg.2013.x64.arx"
59.                         Version="1.0.0.1" />
60.         </Components>
61. </ApplicationPackage>
62.  

... And here's the succinct version, which does exactly the same thing... Note the combining of the OS XmlAttribute, and the addition of the ModuleNameWin32, and ModuleNameWin64 XmlAttributes :

Code - C#: [Select]

1. <?xml version="1.0" encoding="utf-8"?>
2. <ApplicationPackage
3.         AppVersion="1.0.0.1"
4.         Author="Autodesk Developer Network"
5.         Description="ArxDbg"
6.         Icon=" "
7.         Name="Autodesk DWG ArxDBG"
8.         ProductType="Application"
9.         SchemaVersion="1.0"     >
10.         <CompanyDetails
11.                 Name="Autodesk"
12.                 Email="AutoCAD.apps@autodesk.com" />
13.         <Components>
14.                 <RuntimeRequirements
15.                         OS="Win32|Win64"
16.                         Platform="AutoCAD|Civil3D|Map|AIS|ADT|ACADM|MEP|ACADE|PNID|Plant3D|Civil|LDT"
17.                         SeriesMin="R18.2"
18.                         SeriesMax="R18.2" />
19.                 <ComponentEntry
20.                         AppName="Autodesk DWG ArxDBG"  
21.                         AppDescription="ArxDbg"
22.                         ModuleNameWin32="./Contents/Windows/2010/Win32/ArxDbg.2010.arx"
23.                         ModuleNameWin64="./Contents/Windows/2010/Win64/ArxDbg.2010.x64.arx"
24.                         Version="1.0.0.1" />
25.         </Components>
26.         <Components>
27.                 <RuntimeRequirements
28.                         OS="Win32|Win64"
29.                         Platform="AutoCAD*"
30.                         SeriesMin="R19.0"
31.                         SeriesMax="R19.1" />
32.                 <ComponentEntry
33.                         AppName="Autodesk DWG ArxDBG"  
34.                         AppDescription="ArxDbg"
35.                         ModuleNameWin32="./Contents/Windows/2013/Win32/ArxDbg.2013.arx"
36.                         ModuleNameWin64="./Contents/Windows/2013/Win64/ArxDbg.2013.x64.arx"
37.                         Version="1.0.0.1" />
38.         </Components>
39. </ApplicationPackage>
40.  

I also have it on good authority, that one can simply ignore the OS XmlAttribute altogether, within the RuntimeRequirements XmlNode as well, if you like.

[BlackBox]

Also, to pose a related question... Does anyone know how to add multiple SupportPath XmlAttributes to a given RuntimeRequirements XmlNode? 

Searching for an answer to this, is what allowed me to stumble upon the above methodology in the first place.

The Word Document linked (the White Paper), on page 10, defines the SupportPath XmlAttribute as:

<snip>

SupportPath (optional): Semicolon separated list of support paths used by this set of components (this is normally a relative path to a location within the plug-in application bundle). You may specify a localized version of this attribute if required. This path is added to the product’s Support path.

<snip>

... However, when I attempt to do so, it doesn't work.

Code - C#: [Select]

1. SupportPath="./Contents/Resources;./Contents/Resources/Images"

More specifically, the paths are in fact added to the SFSP as indicated, however the <CuixName>.mnl file is not loaded, where <CuixName>.cuix, and <CuixName>.mnl both reside in "./Contents/Resources", and I have some other images in "./Contents/Resources/Images"

The images seem to load fine, but the <CuixName>.mnl does not.

[BlackBox]

Apparently changing the .MNL to .LSP with a new ComponentEntry XmlNode, with PerDocument XmlAttribute specified does the trick. *sigh*

Example:

Code - C#: [Select]

1. <?xml version="1.0" encoding="utf-8"?>
2. <ApplicationPackage SchemaVersion="1.0" ProductType="Application"
3.         Name="Minimal LISP"
4.         AppVersion="1.0.0"
5.         Description="Fentons Minimal LISP Application"
6.         Author="Fenton Webb"
7.         Icon="./Contents/Resources/icon1.ico"
8.         HelpFile="./Contents/Resources/MyHelpfile.htm"
9.         ProductCode="**Unique Code**" UpgradeCode="**Set by Autodesk**">
10.  
11.   <CompanyDetails Name="FentCAD" />
12.   <Components>
13.     <ComponentEntry ModuleName="./Contents/MyLispApp.lsp" PerDocument="True" />
14.     <ComponentEntry ModuleName="./Contents/Resources/MyPartialCUI.cuix" />
15.   </Components>
16.  
17. </ApplicationPackage>
18.  
19.  

So... In other words, the default functionality where an .MNL of the same name as the .CUIx it is collocated with automatically loads with the .CUIx as partial no longer works... That is, with the Autoloader mechanism.

[BlackBox]

So... In other words, the default functionality where an .MNL of the same name as the .CUIx it is collocated with automatically loads with the .CUIx as partial no longer works... That is, with the Autoloader mechanism.

Having just spoken briefly with Fenton here, it appears that I am mistaken about Autoloader not subscribing to the same built-in behavior regarding .MNL, however it also appears that I am experiencing some very much undesired behavior as described in that exchange.

[graces]

I have just been struggling with the same issue you were talking about here.
My plugin cuix is loading but the associated mnl file only loads the first time the plugin is found.
All subsequent restarts of AutoCAD do not load the mnl.

Well, It turns out that the cuix is copied from the:
%AppData%\Roaming\Autodesk\ApplicationPlugins\My.bundle
to the:
%AppData%\Roaming\Autodesk\AutoCAD 20**\R18.*\enu\support
and every launch after the first one uses this location cuix, which does not have a copy of the mnl file.

If I copy the mnl file to the support folder, everything works.
Obviously, this isn't how it is supposed to work, is it?

Have you had any more feedback on a proper solution to this?
-steve

[BlackBox]

I have just been struggling with the same issue you were talking about here.
My plugin cuix is loading but the associated mnl file only loads the first time the plugin is found.
All subsequent restarts of AutoCAD do not load the mnl.

Well, It turns out that the cuix is copied from the:
%AppData%\Roaming\Autodesk\ApplicationPlugins\My.bundle
to the:
%AppData%\Roaming\Autodesk\AutoCAD 20**\R18.*\enu\support
and every launch after the first one uses this location cuix, which does not have a copy of the mnl file.

If I copy the mnl file to the support folder, everything works.
Obviously, this isn't how it is supposed to work, is it?

Have you had any more feedback on a proper solution to this?
-steve

I can tell you that the system that I experienced this behavior on was a system used for Beta testing, which ended up requiring me to wipe clean and re-install the OS to correct.

No, you shouldn't have to do anything about manually copying the MNL, etc., and aside from the unnecessary copying of the CUIx, the MNL does load properly on my other, non-Beta systems.

I'm still working with Autodesk to understand why the need to copy the CUix into each-and-every-single product's ..\Support\ folder is there in the first place, as there can be undesired behavior if one manually renames their .bundle, or removes it altogether.

[Peter2]

...More specifically, the paths are in fact added to the SFSP as indicated, however the <CuixName>.mnl file is not loaded, where <CuixName>.cuix, and <CuixName>.mnl both reside in "./Contents/Resources", and I have some other images in "./Contents/Resources/Images"...

The posting is 2 years old - is it still valid or are some improvements?
On another place I read that the problem comes from dots in the filename: "my.fine.app.cuix" will not load the mnl, it should be changed e.g. to "my_fine_app.cuix"

What's the current state?

[BlackBox]

Not sure; what behavior have you observed in your own testing?

I moved to just using LISP back then, and haven't had a single issue since, but to clarify I've never added file.names.like.this either... So take from this what you like.

Cheers

[Peter2]

...what behavior have you observed in your own testing?...

I just tested quickly with AutoCAD 2015 and 2016 and can confirm:

- "my_app.cuix" loads "my_app.mnl"
- "my.app.cuix" does NOT load "my.app.mnl"

So it seems that the bug from 2014 (or before??) still exists in 2016.