How do I create a Prerequisite Package for Windows Installer?

Question

Can anyone point me to a good introduction on creating prerequisite packages that can be used in WiX? Are these the same thing as "bootstrapper packages"?

This will be for a C# Windows desktop application (actually an ASCOM driver) that is built on .NET Framework 4.7.1.

Pettiford

What are you distributing? What type of runtime or component? – Ansley

@SteinÅsmul good question. "This will be for a Windows application that is built on .NET Framework 4.7.1.". Question updated. – Pettiford

Are you familiar with "Burn" - the setup.exe bootstrapper creator which is part of the WiX toolkit? (the link shows a "hello burn" sample). It bundles together different types of packages such as EXE, MSI, MSP, etc... Just want to check that first. – Ansley

I am running out of time tonight, so please pardon the link-lobbing, but here is a piece on driver deployment. – Ansley

And finally, I'll dare link to my experimental web-site (which never gets finished): installdude.com. Have a search for more if desirable. It is a "deployment jump-gate" (yes, it is a joke ;-) - "take me to your leader"). Do type into the actual search box for auto-complete hits. – Ansley

@SteinÅsmul Don't be taken in by the word "driver", they are not Windows drivers in the sense you may be thinking. They are actually out-of-proc COM components, but essentially something that just has to be installed like a normal app. – Pettiford

Answer 1

Separate MSI: I prefer to deploy prerequisites via a separate MSI and then bundle it all in a Burn-bundle setup.exe or the equivalent constructs from Advanced Installer or Installshield (suite projects). I like this because I can update the prerequisite without touching the main MSI.

Merge Module: The built-in mechanism in Windows Installer intended to deploy prerequisites or components shared by many applications is a merge module. Merge modules are fragment databases merged into the main MSI database at compile time (sort of static linking). Using these modules make all files reference-counted in the right way making it possible to determine if the file can be uninstalled on uninstall, or if there are other applications still using the runtime / prerequisite component. For the record: with an MSI, uninstalling the prerequisite MSI makes all applications that depend on it fail immediately. I find this OK, especially for corporate deployment where this is what you might want (for example to downgrade to a previous prerequisite version easily).

---

WiX Include Files: There is a WiX alternative to merge modules. Here are two answer which describe them - essentially like C++ include files that you can include to many source files:

• How to express a file dependency using WiX
• Setup-Flavours

Basic construct:

<?include include.wxi ?>

I would use auto-component GUIDs.

---

Personal Opinion: I don't like merge modules because they are merged into so many packages, and suddenly you have to rebuild them all for a new merge module update? Bad cohesion and coupling? (no consensus here). Note that due to the design of Windows Installer it is enough to install one package with updated prerequisites to update the system for all applications that use the merge module to install. Why? Because the new package - if the merge module is properly authored - should upgrade all shared files. You still need to update all installers to get the new merge module version in there for systems that don't have many other applications installed that use the same merge module. So you are just as far?

---

COM: Everyone's favorite legacy technology: COM. For out of process COM files (EXE files) I assume you need to register the AppId as well as the Class guid and ProgIds. Use the proper tables for classes and progids, and I believe the AppId table should be tried. Some settings need to go into the registry table.

Commercial tools feature a lot of auto-magic for COM, but WiX unfortunately has some challenges. Here is a messy piece on COM registry data extraction: Registering COM EXE with WIX. Will take some time I think.

The tool heat.exe from the WiX toolkit can extract COM information for dll files, but not from EXE files and not from 64-bit components. The commercial branch of WiX, Firegiant has a tool that does it all.

---

Links:

• Merge Modules
• Removing Default dialogs from MSI
• DLL not registered when connecting to the computer with a different account
• WiX (Windows Installer Xml), Create universal variables

Godin