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. 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
Convert EXE to MSI: 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:
After installing PACE Suite, launch MSI Generator.
If you have User Account Control enabled
, click Yes
in the opened window.
Click Capture installation
Review the issues, which were detected on your system, and try to resolve them by closing the non-essential applications and stopping services. Thereafter, click Next
Select the Monitoring
method for the quicker capturing (or use the Snapshotting
one if you need to continue capturing after the system restart) and click Next
Here you can review and update package name, disable needless exlusion filters and scanning areas. Click Next
to start the capturing.
Click Select and run…
to choose source installation for repackaging.
Select the installer file (e.g. Firefox Setup.exe) and click Open
. Follow the installation dialogs of the launched source installation to complete it. Once the source installation is completed, we recommend to check if the Detected MSI installations
tab does not contain found MSI installers. Even if your sources installation is an EXE file, it could contain embedded MSI installers, launched hiddednly. As you may know, repackaging existing vendor MSI installers into MSI is against Microsoft best practices. So, if the Detected MSI installations tab contains a found MSI installer, consider canceling this capturing (repackaging) process and switching to editing it in MSI Editor. Note that the found MSI installers are copied to the project folder.
Now you can make any changes to the file system and registry, which you want to capture and include to the package. For instance, you can create new or copy-paste existing files, import REG file to the system registry, changes permission settings, or launch the installed application in order to capture the necessary application configurations, like disabling updates and so on.
Finaly, to complete the capturing, select I have finished the installation and click Next
Wait a little, while the capturing process is finishing, filtering captured data and creating the project. Leave selected the Customize project in editor
and Copy all captured files to the project folder now
options are selected and click Finish
The following dialog displays captured files, which could not be copied to the project folder because they do not exist anymore or locked by the system or by an application. Try to resolve these issues and then click Retry
. Click Finish
to skip copying the missing and locked files and mark them as Excluded resources.
Once the project is opened in the project editor, you can just click Build MSI
button, and that’s your 6 steps to convert EXE to MSI. However, we recommend reviewing the captured resources at the Files, Registry, System resources, Permissions,
and Shortcuts and FTAs
tabs and excluding unnecessary ones from the project. Unnecessary resources are files, registry entries, which are usually created or modified in the 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 almost 100% do not refer to your captured application (e.g. NOD32 antivirus files couldn’t be a part of Firefox application).
In order to review and exclude unnecessary files or folders, go to the Files
tab, and select Exclude
from the context menu of an item, which is located in the left ‘Files Included
In order to review and exclude unnecessary registry keys or values, go to the Registry
tab, and select Exclude
from the context menu of an item, which is located in the left ‘Registry Included
In order to review and exclude unnecessary services, go to the System resources
tab, and uncheck the checkbox, located before the service name in the list, for those services, which you want to exclude.
In order to review and remove unnecessary Environment variables, go to the System resources
-> Environment variables
tab, and select Delete
from the context menu of an item, which you want to remove.
On the Permissions
tab you will find captured permissions for the file system and registry. For excluding unnecessary permission changes, either uncheck the checkbox, located before the path, for which permission changes were detected, or select Do not apply
in the Apply to MSI
field, located in the botton of the window.
In order to review and exclude unnecessary shortcuts, go to the Shortcuts and FTAs
-> MSI shortcuts
tab, and uncheck the checkbox, located before the shortcut name in the list, for those shortcuts, which you want to exclude.
Finaly, to convert EXE to MSI and build an MSI package from the project, navigate to the Package
tab, update Application details
such as name, publisher, version, language, select INSTALLDIR
and click Build MSI
. Once the package is built, 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.