How to inject additional installer into the AutoCAD OEM 2023 installer

When creating the installer for an AutoCAD OEM 2023 based application, the Installer Wizard is used to assemble all needed file into a single directory for publication. The resulting directory can (and should) be put into a Zip or Rar archive for distribution. With AutoSTAGE (Disclaimer: I am the lead developer for AutoSTAGE), we use WinRar to create a self-extracting archive, which is an executable that automatically extracts the files and runs the installation process when double clicked (or executed otherwise).

Depending on the OEM application you are building, you may need to include other installers that need to be installed to run your application, for example for the licensing mechanism. With this post, I will show to you how to inject external additional installers into the AutoCAD OEM installer workflow to get it installed during the overall installation process of the OEM application.

I will show the workflow with an example from our AutoSTAGE application.
When installing AutoSTAGE, we need to install four additional installers:

  • AuStPreviewLib.exe
  • AuStUninstaler.exe
  • The AutoSTAGE Runtime, which installs additional files and registry entries that are needed for the functioning of our AutoCAD OEM based application. This is an MSI installer.
  • The CodeMeter Runtime, which is needed for the licensing mechanism. This is also an MSI installer.

After the OEM Installer Wizard has run its course, the resulting directory looks like this:

Oem_Installer_Directory

You’ll notice the folder labelled 3rdParty. This is the location where additional installers can be placed. With AutoSTAGE, we make a subfolder called AuSt, which is a shorthand for AutoSTAGE and the short name of our OEM application. All the needed additional installers are placed in the 3rdParty\AuSt folder.

Oem_Installer_Directory_3rdParty_AuSt

Every installer needs to have a package xml file, which adds some metadata for the OEM installer. These package xml files are vital for the integration of our installers into the general OEM installation workflow.

#1 Package xml for exe files

The content of the package xml file for exe installers looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package version="1.0" xsi:schemaLocation="https://emsfs.autodesk.com/schema/manifest/1/0 https://emsfs.autodesk.com/schema/manifest/1/0/manifest.xsd" xmlns="https://emsfs.autodesk.com/schema/manifest/1/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Identity>
        <Publisher thirdParty="true">AutoSTAGE GmbH</Publisher>
        <DisplayName>AutoSTAGE Preview Library</DisplayName>
        <BuildNumber>2.3.29</BuildNumber>
        <UPI2>{EB2CF898-EB2E-4C79-8399-C251372D28CD}</UPI2>
        <UpgradeCode>{19E65AA5-D76B-4254-9E62-0C124624C3FD}</UpgradeCode>
        <ConstantId>{088043EC-2C99-42A6-85F5-E05683BD542A}</ConstantId>
    </Identity>
    <Configuration>
        <InstallFile type="EXE" contents="File" installParams="/install" file="3rdParty/AuSt/AuStPreviewLib.exe">
	</InstallFile>
        <Attributes diskCost="200000000" ignoreFailure="true" permanent="true"/>
        <Platforms>
            <Platform name="Windows" architecture="x64" minVersion="8.1"/>
        </Platforms>
        <Languages languageNeutral="true"/>
        <LogFilePath>%temp%/AuStPreviewLib.log</LogFilePath>
    </Configuration>
</Package>

Lets have a look what is important to the working of the installer:

Change Publisher and DisplayName to your needs.

The values for BuildNumber, UPI2 and UpgradeCode should change for each new installer build to be distinct between published versions

(Side note: I have not found out if the UpgradeCode should stay the same for different versions. Usually, with MSI installers, there is an upgrade code that must not change to recognize the (previous) installer when updating with a new version installer of the same appication. I will post any future findings here).

The file attribute from the InstallFile node needs to be the path to the installer, starting with the 3rdParty folder. Do not use backslash \ for path indentifier! Use slash / between the folder names. Otherwise, the installer will fail!

The diskCost attribute from the Attributes node is the size of the application in bytes (this will be, in general, most likely a big number). This figure is used to ascertain the amount of disk memory needed for the installation and should reflect the accurate file size of the installer.

Add a valid LogFilePath to create an install log to see if everything runs ok during the installation.

#2 Package xml for msi files

The packet xml file for msi files looks almost like the version for exe files, with some minor distinct differences.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package version="1.0" xsi:schemaLocation="https://emsfs.autodesk.com/schema/manifest/1/0 https://emsfs.autodesk.com/schema/manifest/1/0/manifest.xsd" xmlns="https://emsfs.autodesk.com/schema/manifest/1/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Identity>
        <Publisher thirdParty="true">AutoSTAGE GmbH</Publisher>
        <DisplayName>AutoSTAGE Runtime</DisplayName>
        <BuildNumber>2.3.29</BuildNumber>
        <UPI2>{E9C9B1C1-6A14-4501-9B76-7AA18390A33C}</UPI2>
        <UpgradeCode>{A704EDA3-693D-40BD-A827-417358B6A322}</UpgradeCode>
        <ConstantId>{CE9D168F-5237-442E-9AA8-7704D76EF02F}</ConstantId>
    </Identity>
    <Configuration>
        <InstallFile type="MSI" contents="Folder" file="3rdParty/AuSt/AutoSTAGE_2023__Runtime_Installer_2.3.29.msi" />
        <AdditionalPackageInfo identifier="{A5CAE148-805A-4F63-91E6-DE3031896CAB}" upgrade="{22F7A6FA-221E-49BB-8A50-2C6B5523ACB8}" version="2.3.29" />
        <Attributes diskCost="50000000" ignoreFailure="true" permanent="true"/>
        <Platforms>
            <Platform name="Windows" architecture="x64" minVersion="8.1"/>
        </Platforms>
        <Languages languageNeutral="true"/>
        <LogFilePath>%temp%/AutoSTAGE_2023__Runtime_Installer_2.3.29.log"</LogFilePath>
    </Configuration>
</Package>

The InstallFile node must not have the installParams attribute! Otherwise, the OEM installer will present an error message very early during the installation process.

Also, type should me MSI and contents should be Folder. Again, do not use backslash \ for path indentifier in the file attribute! Use slash / between the folder names. Otherwise, the installer will fail!

For MSI installation, we need an additional node called AdditionalPackageInfo with the identifier and upgrade attributes, which are both GUIDS. These should change for each new installer build to be distinct between published versions

(Side note: I have not found out if the one or both if them should stay the same for different versions. Usually with MSI installers, there is an upgrade code that must not change to recognize the (previous) installer when updating with a new installer. I will post any future findings here).

Also, there is a version attribute which should contain the version number of the referenced installer.

#3 Make the package xml files know to the OEM installer

We have copied our installers to the 3rdparty folder and added respective package xml files. Now we need to tell the OEM installer to integrate these into the installation process. This is done in a package xml file of the main installation msi for the OEM application.

The package xml file can be found in the folder x64\{short-name-of-application}\.

In this folder you find the aust.msi file, which is the main installation file of the OEM based application. The package xml file pkg.aust.xml is a description file for the overall OEM installation mechanism.

When opening that file in an editor, it looks something like this:

We need to add some new Package nodes under the Dependency node to tell the installer where to find our additional installers.

<Package installAs="core" name="AutoSTAGE Preview Library" external="true" path="3rdParty/AuSt/pkg.AuStPreviewLibExe.xml" upi2="{EB2CF898-EB2E-4C79-8399-C251372D28CD}" upgradeCode="{19E65AA5-D76B-4254-9E62-0C124624C3FD}" />

Use the value of DisplayName from the installer package xml as the name attribute. The path must point to the installer package xml file. The GUIDS for upi2 and upgradeCode must be the same GUIDS used in the installer packet xml (otherwise, an error will occur very early in the installation).

#4 Find install errors

Adding additional installers is in itself almost a very straightforward task. But, as always, the devil is in the details. There is always the chance that a parameter or path is not right. If the OEM installer throws an error message during installation, consult the install logs under

%temp% as well as the DDA.log file under C:\Users<user>\AppData\Local\Autodesk\ODIS.

Usually, you will find the source of the error in these logs.
Finding these may take some detective work and can be tricky, reserve some time for this!

#5 Conclusion

When all files, names, paths and GUIDS are aligned, the OEM installer will find and execute our additional installers in the installation process of the OEM application. With this, we can package any needed additional installers with the OEM application for installation.
2 Likes

Thanks for this post. It really helped me out with upgrading from 2022 to 2023.

By the way, are you able to produce patch’es or service packs for an oem application?
So far, the only way I’ve managed to apply an update for our product to a customer is to do an uninstall of previous version as part of the setup process. Thus the whole package must be provided as opposed to a msp or a update.exe.

Best regards,
Øystein Wiger
Focus Software AS

1 Like