How to convert EXE to MSI: a complete guide
December 20, 2016 | Video |
How to convert EXE to MSI
Repackaging EXE to Windows Installer (MSI) package is one of the most widespread tasks in managing any IT environment. The typical use case is to convert EXE to MSI to run a silent installation that does not require any interactions with the end user.
Watch the video guide below or follow the step-by-step instruction to convert EXE to MSI installer. After the instruction, you can also find some best practices for repackaging EXE to MSI packages. Also, if you want to learn more about MSI packages, read this article.
A step-by-step repackaging guide
In this tutorial, we are using MSI Generator, a part of our PACE Suite application packaging solution. Download a free trial here. After installing PACE Suite, launch MSI Generator.
If you have User Account Control enabled, click Yes in the opened window.
Click Capture installation and select the Monitoring method (use the Snapshotting method if your source installation requires system restart).
Please wait a little, while the capturing process is starting (in case you have selected the Snapshotting method, wait while the initial system snapshot is taking).
Once the capturing process is started, click Browse… to choose your source installation (the one for which you want to convert EXE to MSI).
Choose an executable file of source installation (e.g. Firefox Installer.exe), which you want to repackage and click Open.
If needed, change the package name typing new value to the Package name field, or disable exclusion filters by unchecking checkboxes next to filters in the list. Note that we do not recommend disable exclusion filters, because they detect and exclude system resources, which are not a part of your package. Such resources could be created or changed as a result of ordinary system work. The Capture installation guide automatically checkbox runs Docu Generator, which serves taking screenshots and saving them into a document.
Click Run to launch the selected source installation file.
Follow installation steps of the launched source installation to complete it. At this phase, you can make any application configuration you need to be captured and included into your package.
Once the source installation is completed, check if the Detected MSI installations tab contains discovered MSI installers. Your source installation (EXE) could contain embedded MSI installers, launched hiddednly. As you may know, it is not recommended to recapture vendor MSI into MSI, because they could contain custom business logic in binary Custom Actions. This custom logic could not be captured and re-created again in MSI properly. So, if you have detected MSI installation, cancel the capturing process and switch to editing MSI, which is extracted from your source installation and copied to the project folder. Read our How to Edit MSI guide.
In our example, ‘Firefox Installer.exe’ does not have embedded MSI installations, so we go next to complete the capturing process.
Click Finish Capturing to complete the capturing process.
Please wait a little, while the capturing process is finishing, filtering captured data and creating the project. Once the project is opened, go through the Files, Registry and Shortcuts tabs in order to review captured resources and exclude unnecessary ones from the project. Unnecessary resources are files, registry entries, which are usually created or modified as a result of operating system work, and such resources could not be a part of your captured application. Unfortunately, there is no universal rule to discover which of captured files or registry entries should be excluded, so exclude only those ones, which are almost 100% do not refer to your captured application (e.g. NOD32 antivirus files could be a part of Firefox application).
In order to build MSI package from your project, navigate to the Package -> MSI tab and click Build MSI.
Click Go to…, located next to the MSI file name field, to open the package-containing folder in Windows Explorer.
Congratulatuions, you’ve finished our convert EXE to MSI guide!
Repackaging best practices
We have picked certain important best practices from MSDN. The following list is not exhaustive but it may help you produce a quality package when you convert EXE to MSI:
Do not use the SelfReg and TypeLib tables.
- Installation package authors are strongly advised against using self registration and the SelfReg table. Instead they should register modules by authoring one or more of the tables in the Registry Tables Group. Many of the benefits of the Windows Installer are lost with self registration because self-registration routines tend to hide critical configuration information. For a list of the reasons for avoiding self registration see SelfReg table.
- Installation package authors are strongly advised against using the TypeLib table. Instead of using the TypeLib table, register type libraries by using Registry table. If an installation using the TypeLib table fails and must be rolled back, the rollback may not restore the computer to the same state that existed prior to the rollback.
Do not try to replace protected resources.
Windows Installer packages should not attempt to replace protected resources during installation or update. The Windows Installer does not remove or replace these resources because Windows prevents the replacement of essential system files, folders, and registry keys. Protecting these resources prevents application and operating system failures.
- Windows Installer skips the installation of any file or registry key that is protected by Windows Resource Protection (WRP), the installer enters a warning in the log file, and continues with the remainder of the installation without an error.
- WRP is the new name for Windows File Protection (WFP). WRP protects registry keys and folders as well as essential system files. When the Windows Installer encountered a WFP-protected file, the installer would request that WFP install the file.
Organize the installation of your application around components.
The Windows Installer service installs or removes collections of resources referred to as components. Because components are commonly shared, the author of an installation package must follow rules when specifying the components of a feature or application.
- Adhere to the component rules when Organizing Applications into Components to ensure that new components, or new versions of components, can be installed and removed without damaging other applications
- The installer tracks every component by the respective component ID GUID specified in the Component table. It is essential for the operation of the Windows Installer reference-counting mechanism that the component ID GUID is correct.
- If your package must break the component rules, be aware of the possible consequences and ensure that your installation never installs these components where they may damage components on the user’s system.
- Be aware how the Windows Installer applies the File Versioning Rules when Replacing Existing Files. The Windows Installer first determines whether the component’s key file is already installed before attempting to install any of the files of the component. If the installer finds a file with the same name as the component’s key file installed in the target location, it compares the version, date, and language of the two key files and uses file versioning rules to determine whether to install the component provided by the package. If the installer determines it needs to replace the component base upon the key file, then it uses the file versioning rules on each installed file to determine whether to replace the file.
Share this blog article: