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:


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.


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="" xmlns="" xmlns:xsi="">
        <Publisher thirdParty="true">AutoSTAGE GmbH</Publisher>
        <DisplayName>AutoSTAGE Preview Library</DisplayName>
        <InstallFile type="EXE" contents="File" installParams="/install" file="3rdParty/AuSt/AuStPreviewLib.exe">
        <Attributes diskCost="200000000" ignoreFailure="true" permanent="true"/>
            <Platform name="Windows" architecture="x64" minVersion="8.1"/>
        <Languages languageNeutral="true"/>

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="" xmlns="" xmlns:xsi="">
        <Publisher thirdParty="true">AutoSTAGE GmbH</Publisher>
        <DisplayName>AutoSTAGE Runtime</DisplayName>
        <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"/>
            <Platform name="Windows" architecture="x64" minVersion="8.1"/>
        <Languages languageNeutral="true"/>

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 Things that can go wrong

As Bruno Fregosi *(thanks for sharing)* discovered, you need to sign the additional files you inject into the OEM Installer with a valid certificate (as you should always to). When your additional files are not signed, the OEM installer will fail when executed.

#6 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.

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


We struggled with this in the past and in the end we opted to create a separate installer for our updates. It take a little work but once your done it is pretty robust and easy to copy over to the next year. It gave us the ability to apply changes to our application to multiple years of OEM’s in a very straightforward and seamless manner without having to deploy a new installer each time.
In a nutshell, here is what we do to build an update for the year we want:

  1. We make changes to our application and output the new files to a location.
  2. Run the OEM Make Wizard so that it incorporates the changes and binds the files
  3. Once your changes are pushed to the OEM Make Wizard build folder you can then use a program like InstallShield or others like it to package only the changed files into an exe that can then be deployed as an update on the users OEM without having to Uninstall and Reinstall OEM each time.

Once you get the above in place you can completely automate all the processes so that it is done at the click of a button.

This works for us because the core of OEM is typically always the same and the only changes we make are to our own application. If we have to tweak the core of OEM then we have to make a new installer but it is rare that we have to go that far.
Shawn Golden

Jens and others,
It has been asked if there is a way to execute a third party application installer after the Core OEM portion is installed in the OEM installation process. This may be needed if your application is dependent on certain files or registry values being available to provide logic during your applications install process. A simple example would be if your application looks to the registry value to get the install folder from your CORE OEM so that it knows where to install to. There is more valid reasons than that one but I want to keep it simple.

We tried to get an answer from ADN but none were available at the time and those that asked about it either did not get an answer or were given links that were either broken or did not really answer the question. It seems the only information provided for the new ODIS Installer and OEM is just a blanket statement telling us that they are using the new ODIS Installer…LOL. I am confident they will come out with something more in the future for those of us who build products with OEM. For now we are forced to figure it out by using our own intelligence, logic, and good old trial and error.

The answer some have been waiting for is…
YES you can execute your application after the Core of OEM is installed by changing one parameter in the line that you insert into the xml for you package.
Go ahead and create the pkg.MYAPP.xml in the same folder your application is in like Jens mentions.
For the package pointer though you will have to use a different XML located in the “\Manifest” folder of the OEM Installer. It will be named something like app.MYAPP.xml.
You just need to insert the package pointer into the section but change the installAs parameter. It needs to have the value of:
So your line should look something like the one in this picture:

What we discovered is that the parameter “core-update” tells it to install after the Core OEM is installed. Now your application installer has access to OEM registry and files and can perform the logic needed to install itself!
Shawn Golden

Hi Shawn,

I’m recently looking at creating an updater for our clients that runs on top of their existing install.

When I looked at your solution, there are some questions hoping you can provide help with -

  • What version of AutoCAD OEM you are using? Can AutoCAD OEM 2020 work with the approach you suggested?
  • Are the changes of the application include the changes in the dlls we bind with the Make Wizard?



Good questions.

  • We support a 3 year span of OEM’s every year and drop the 4th year. For instance, in 2023 we support OEM 2021, 2022, and 2023 and have dropped OEM 2022.
  • OEM 2020 can definitely be set up to do this.
  • We make changes to our primary application once and then run the OEM Make Wizard for each year to pull and Bind the files for the years we support. We then use 3 separate Installshield projects we created to pull the necessary files for the correct OEM year and package it into an exe for the year it was made for for deployment.

Hope this helps



Thanks for your quick reply.

I’m not sure how often you send out a new patch installer to your client but to us, it’s quite often - every once a week.

Did you reset your computer date to the date your project was built before rebuilding your project?

I read a help file saying that this is necessary and the Scree.dll file has to be included in the updater otherwise it won’t work - at least for OEM 2006, 2007, and 2008, not sure if this is still required for version 2020 or above.

Article URL:


Hello Weiyang,

let me add my experiences.

We have been building our AutoSTAGE application since OEM 2016, and at least since then it is not necessary to reset any computer date or something else.

In general, integrating any new OEM version is very easily done and requires usually not much refactoring of existing code or procedure. The biggest change happend from OEM 2022 to OEM 2023, where Autodesk fundamentally changed the installer process from the “classic” installer to the ODIS installer. That has been some additional work, but this investment will last some years, provided Autodesk will not change the procedure anytime soon.

We use an automated build pipeline that builds our product as a plug-in for vanilla AutoCAD (2018-2023) as well as for AutoCAD OEM (2018-2023). For the latest version, we also build dedicated language version in German and English language.

Please check out my other post regarding this:

Our build tool builds the full installer set (the result of the OEM Installer Wizard) as well as update patches, which are separate msi-files that update only the differences between the old and new version. The user installes the full installer at first and then applies only the update msi file to install all changes with any new version we publish. This has been running very robust for a couple of years now.

The full build for all products takes about 12 hours to run and generates about 50GB of data. In theory, we could publish an update twice a day (which we do not!).

Best regards,
Jens Mueller, AutoSTAGE

1 Like

Jens is correct. You should not have to reset your computer date.
We create updates at least once a week.
Yes you will definitely want to include the Scree.dll as well as the “Application.dll.Sig” files that you generate for your application dll’s. Start with those and see what results you get. There may be a few other files you will want to include that are updated for the OEM in the Make Wizard process. I will have to take a look at our automated compiler and installer software to see what additional files we are pulling. I know it is not that many. Jens may have a list of OEM files that are updated and that he adds to his installer in addition to the application. If he has them handy before I have a chance to look I am sure he will list them for you.

1 Like

Hello Weiyang,

when building an update installer for an OEM product, there is a simple rule for the selection of files to be included in the update installer: Build your OEM product with the OEM Make Wizard and look in the build output folder for the files with the date and time that correspondents (roughly) with the date and time when you started the build. These are the most recent ones and are changed by the OEM Make Wizard. Include these files into your update installer, and copy the files with the installer to the path where the OEM application is installed on the target machine. This has worked for us for a long time and seems to be a robust way to deliver updates.

Jens, AutoSTAGE

1 Like

Hi Jens,

Really appreciate your help.
I’m now struggling in setting up a Digital Signature for testing purposes with the OEM 2023.
I have two more questions about the updater -

  1. What software did you use to create the updater? InnoSetup? InstallShield?
  2. Why need to copy the files that are already in the update installer and the installer itself to the target machine?



you have to look at the life cycle of your application.

Today you are building version 1.0 of your application. You build the AutoCAD OEM with the Make Wizard. You build the Installer with the Installer Wizards. You may wrap the resulting installer folder in a self extracting zip or rar file (this is what we do with WinRar ) to make it very easy for the end user to install the application. This installer file will be about 2GB in size. This is what you will publish to your customers and users.

In 6 month, you will have version 2.0 of your application. With this, you make the same workflow as above.

To new users, you deliver the new version 2.0 2GB installer file.

To existing users that already use version 1.0, you could also deliver the BIG new version 2.0 installer file (provided you change the ProductGuid in the installer xml file for version 2.0). But that is not very efficient, because the user would have to install 2GB in data, where the actual aplication differences may account only for (lets say) 100MB.

To give existing users with version 1.0 an efficient way to update the application to version 2.0, you publish also an update installer that contains only the differences (all files with the current build date). This update installer should be much smaller (like said 100MB from above) and is much easier to distribute and deploy that a monolithic 2GB installer file. This is the sole reason for the update installer.

We use the free Wix Toolset to create our installers.

Hope this helps to get you up and running.

Jens, AutoSTAGE

1 Like


Have you reset your product install path from Program Files to something else?
I found that I couldn’t use the Wix Toolset to add 32-bit components(eg. scree.dll) to the Program Files.



no, we install to the preset folder in Program Files. This works smoothly for us, I am not aware of any problems with scree.dll.



I had trouble creating an updater with Wix Toolset, instead, InnoSetup gave me a good result.

One thing worth mentioning is that I couldn’t make the updater work if I change the Registry Release number in my MakeWizard - an error of loading the MyProjectres.dll would encounter.
I had to stick with the same version number to get it rolling.

Thanks for all your help.

Best Regards,

Hi all,

we followed the procedure explained in the original post, but we couldn’t make it work properly, as we continue to get the same error once we run the setup.exe
The error text is pretty generic, as it only says that an error occured while preparing for installation.

This is a screenshot of our pkg.test23.xml and setupTest23.xml:

Hi Bruno,

you have to look into the logfiles of the AutoCAD OEM ODIS installer. You find the logfiles under


Searching the installer logfiles can be tedious, but it is worthwhile. In my experience, there is the state of the installer logged with many details. Start the search with the name of your application and/or some name strings from you installer xml.


Hi jens,
thanks for your answer.

I’ve seen that log file before, but there’s a generic error code :

ADPUtil::trackEvent: {“component_attributes”:{“error_code”:8,“error_tip”:“An error occurred while preparing for installation. Please exit and start the install again.”,“error_title”:“Installation error”,“priority”:“FATAL”},“component_name”:“initialization_failure_page_opened”,“component_type”:“page”,“product_meta”:{“target_product_id”:null,“target_product_line_name”:null,“target_product_name”:“”,“target_product_release_id”:null},“scope”:“A”,“type”:“V”,“session”:“ca454ff8-635e-41cc-b71b-ee2535982cd0”,“odis_session_id”:“”,“installation_id”:“726bf489-5690-4ea7-97aa-8a6b6b476f60”}

Can you help me to understand it?

Best Regards,


I do not recognize the error code you posted.

Check the ODIS logfiles very carefully. In my experience, the answer is there (somewhere). As I said, this can be tedious.

Start with a simple installer to integrate and then iterate until you hit the wall. In general, this is a good principle for debugging: start simple and iterate until you get the desired outcome.

Look again at the original workflow and compare, if every step is exactly the same.


Hi Jens,

Is the installParams in the package xml file for exe installers always equal to “/install”? If not, how do we set it up?