Wix installer does not overwrite previous version of an executable

Question

I have a very simple installer - copy a single dll to a Program Files subfolder and register it with regsvr32.exe. Works great, but if an older version of the dll is install

Answer 1

I am surprised that this line actually is allowed by the Wix compiler and linker:

 <?define PackageId   = "45F34788-66AC-441C-B666-707FFA7F1EE9" ?>

If this actually works and goes through, which I haven't tested, it means your package has a hard coded package id. I thought Wix featured protection against this problem? Perhaps it does? We should check with the Wix community if it ever makes any sense to allow hard coded package guid. I suppose it could be necessary for debugging and testing purposes - but there should at least be a compiler warning.

The idea of a package GUID is that it should be unique for each compiled MSI file. It is simply there to uniquely identify a file. Two different MSI files with the same package guid will be treated by Windows Installer as the same file by definition. All kinds of x-files problems result. Accordingly a package GUID should always be auto-generated since it is simply supposed to be unique. Please try to resolve this problem first to check if this solves your overall problem. Set it equal to *.

My advice is to auto-generate package id and product id but to set a hard coded upgrade code. An upgrade code identifies a "family of products" and is useful for identifying any instance of your product regardless of language and version. It might be useful to use a separate upgrade code for your 64 vs 32 bit setups since both versions can be installed at the same time on some systems.

You might also want to eliminate the use of regsvr32.exe for self-registration and extract COM data from your dll for proper MSI support: MSI register dll - Self-Registration considered harmful. And perhaps also check this: Register ActiveX exe server using WiX (check out RegSpy2 if Heat doesn't work).

Also note that you can leave out a lot of source attributes from your Wix xml file and rely on Wix defaults instead of hard coding values.

Some further details on GUIDs and file replacement:

• Change my component GUID in wix?
• MSI Reference Counting: Two products install the same MSIs
• Forcing an upgrade of a file that is modified during its initial installation
• msi version numbers
• File Versioning Rules
• Replacing existing files (diagram, both files have version)
• Plain English file versioning description by Aaron Stebner

Answer 2

If you want a major uprade, start with the WiX MajorUpgrade element. The general rules for an upgrade are:

1. Different ProductCode and PackageCode from older product.
2. Increment ProductVersion somewhere in the first three fields.
3. Same UpgradeCode as older product.
4. Do something (like Wix MajorUprade or Upgrade elements) to ensure that you have an upgrade in place.
5. A per user install will not upgrade a per system install, or vice versa.

In your original case, failure to follow rules 1 and 2 meant that Windows thought the same product was already installed and went into Repair mode. That should have been your first warning because a major upgrade looks like a fresh install, not a repair. If you have two entries in Programs&Features it means that one or more of those 4 requirements has not been met. If you get "Another version of this product is already installed" it means you didn't follow rule 1, and variations in behavior are about ProductCode and PackageCode values compared with the installed product.

Answer 3

Short answer (the other one became too messy): try removing this line and let the package ID be auto generated by setting it to "*":

 <?define PackageId   = "45F34788-66AC-441C-B666-707FFA7F1EE9" ?>

Note that you must stop using all previous MSI builds after uninstalling them all. This is due to the faulty hard coded package guid which can cause unpredictable and unforeseen problems.