Registering DLL and OCX Files in MSI Packages - 3 Recommended Techniques
In order to allow a program to execute, you must first register its extension as a DLL or OCX.
And although you may be tempted to use the SelfReg table method, you should know that Microsoft strongly advises against this because of various reasons.
One of the reasons is related to advertisement -- if you use SelfReg instead of the corresponding advertised tables specifically designed for this (Class, ProgID, TypeLib), then your application will not benefit from these entry points, reducing the ability to use advertisements.
Aligned with Microsoft's recommendation, Advanced Installer also discourages the usage of a self-registration mechanism.
You can review the SelfReg table here to find a full
list of reasons for avoiding the self-registration mechanism.
In this article, we will be going through the alternative options that follow Microsoft's best practices to register DLL or OCX files. Let's get started.
1. Registering Files as DLL or OCX through Application Repackaging
The first option you have for registering your files as DLL or OCX is repackaging your application. If you need to repackage your application, then you don’t need to follow any specific step – the registration info will be captured during the repackaging process.
For more information about the repackaging process, you can check our
Repackager guide article.
What to Do If The Application Has Already Been Repackaged?
If you already repackaged your application using Advanced Installer and you still have the project file, then you have a few options:
1. Extract the registration information
1.1. Right-click on the file you want to register.
1.2. Enable the “Auto register file (DLL OCX, etc).
1.3. Extract registration info from native library” option.
2. Capture the registration info into a new project file (you can use the Repackager Session Monitoring option) and then import the newly created project file into the project file of your application.
3. Capture the registration info into a new project file (you can use the Repackager Session Monitoring option), export the registry keys and then import them back into the project file of your application.
2. Registering DLL/OCX files from a Repackaged or Vendor MSI
If you already have an MSI for your application (either a repackaged or vendor MSI), then you can use a similar approach to option 3:
Capture the registration info into a new project file (you can use the Repackager Session Monitoring option), export the registry keys, and then import them back into your application MSI.
3. Using Custom Actions To Register DLL/OCX Files
If you prefer to use Custom Actions, you can also use a script to register the DLL/OCX file(s) during the installation process.
If you take this route, make sure to create a separate CustomAction to unregister your files during the uninstallation process.
You can register and unregister DLL/OCX files(s) using the Microsoft
utility tool – RegSvr32.
Since this type of Custom Actions changes the system state, it must be set to “Deferred”.
You can find more information in our article about “Deferred” Custom Actions and when to use them.
Conclusion
Although the SelfReg table is still accessible via the Table Editor page, it is not recommended that you use the self-registration mechanism to register your DLL/OCX files.
Advanced Installer offers various options to help you register your DLL/OCX file(s) without the need of employing a legacy self-registration mechanism.
I hope you find one of the above scenarios useful for your particular case. Please let us know your feedback and any additional questions down in the comments.
Subscribe to Our Newsletter
Sign up for free and be the first to receive the latest news, videos, exclusive How-Tos, and guides from Advanced Installer.