This site uses cookies to offer you a better browsing experience. Find out more on how we use cookies and how you can opt out. Accept
PACE Suite - Application Packaging & Virtualization Software PACE Suite - Application Packaging & Virtualization Software

    Request a quote
    Please fill in this quick form and we will send you a free quote shortly.
    I have read and agree to the Privacy Policy

      Request a quote
      Please fill in this quick form and we will send you a free quote shortly.
      I have read and agree to the Privacy Policy

        Contact PACE Products Team
        Please fill in this quick form to contact our expert directly.
        I have read and agree to the Privacy Policy

        Best Practices of Repackaging EXE to MSI

        If you are a sysadmin or an app packaging engineer, you probably need to have an MSI package at hand to install software using group policies remotely. However, some applications come only in .exe formats. To alleviate the task of the EXE to MSI repackaging, we share the best practices of how you can do it most effectively.

        We’ve picked some of the significant best practices on converting EXE to MSI from MSDN. This list is not exhaustive, but it’ll come in handy for you to produce a quality package when converting EXE to MSI file:

        Don’t use the SelfReg and TypeLib tables when converting EXE to MSI

        Installation package authors are firmly recommended to refrain from using self-registration and the SelfReg table. Rather, they should author one or more tables in the Registry Tables Group to register modules.

        The Windows Installer has many benefits, but many of them are lost when self-registration routines hide critical configuration details. In the SelfReg table, you can find a list of reasons why self-registration should be avoided.

        There are strong recommendations against using the TypeLib table by installation package authors – type libraries can be registered using the Registry table instead. If the TypeLib table fails during installation and the system has to be rolled back, the rollback may not restore it to its original state.

        Do not try to replace protected resources

        • While installing or updating, Windows Installer packages shouldn’t try to replace protected resources. As system files, folders, and registry keys are prevented from being replaced, the Windows Installer doesn’t remove or replace these resources. These resources must be safeguarded to prevent app failures and the operating system.
        • Windows Installer skips installation when a file or registry key is protected by Windows Resource Protection (WRP). The WI logs a warning in the log file before continuing with the installation without an error.
        • The new name for Windows File Protection or WFP is WRP. It protects registry keys, folders, and essential system files. When encountering a file protected by WFP, the Windows Installer will request the WFP to install the file.

        Organize the installation of your app around components

        Installations and removals of components are made possible by the Windows Installer service. Considering that components are often shared, installation package authors must follow the next rules when describing components of an app or feature:

        • Follow the component rules when you organize applications into components to ensure that the new components or their new versions can be installed and removed without inflicting other apps.
        • The installer traces each component by the individual component ID GUID determined in the Component table. It’s critical for the seamless functioning of the reference-counting mechanism of the Windows Installer that the component ID GUID is valid.
        • If your package violates the component rules, you should be ready for the potential consequences. You should also ensure that your installation won’t install the components as they might impair the user’s system.
        • It would be best if you watched out for the way the WI enforces the File Versioning rules when substituting existing files. It checks if the component’s key file is installed before trying to set up any of its files. If the WI discovers a file with an identical name to the component’s key file in the target location, it will compare the two files’ versions, date, and language.

        The installer will also apply the rules to decide if to install the component provided by the package or not. If the WI selects to replace the component based on the key file, it will use the rules on every installed file to decide whether to substitute it.

        Clean EXE to .MSI Repackaging

        MSDN provides a dozen of recommendations on how to convert Exe to MSI for application packagers to follow. Yet, it’s possible to cut time on executing all of them manually – you can have the application packaging solution do it for you, plus grant that the output package will be stable, safe and secure.

        When you convert Exe to MSI, the application packaging tool will:

        • Manage your app installation around components
        • Decrease large-size MSI packages
        • Adhere to assembly practices (in case assembly is used)
        • Ensure consistency in Package codes and package names
        • Provide the option to install without a user interface.

        PACE Suite also helps to:

        • Plan and test a servicing strategy before shipping the app
        • Make sure that the source files of packages are kept secure and accessible to users
        • Turn on verbose logging on the user’s PC when troubleshooting deployments
        • Decrease the dependency on sources for updates
        • Keep away from patching admin installations
        • Make sure the installation package is thoroughly tested
        • Fix all validation errors before deploying a revised or new installation
        • Author a secure installation

        You can test all this works by requesting a 21-day fully-functional trial of PACE Suite.