Utility: Project refactoring for MSI Factory

[Ulrich]

When you wish to create or derive a new MSI Factory project from an existing project, you can use this utility to generate new GUIDs, so you won't cause Windows Installer compatibility issues when both projects - the original and the new - are deployed on the same computer.

Benefits

• Replaces Package ID GUID;
• Replaces Upgrade code GUID;
• Replaces GUIDs of all Components in the project;
• Save to use: The converted project file will have a "-new" suffix in the file name, for example, "sample.msifact" will be saved as "sample-new.msifact".

Download and further info here.

Ulrich

[acenes]

I use to create each new version by generating a new new upgrade code and a new product code in the project settings, so the customers can install (and uninstall) several versions side-by side. The package ID is automatically generated new each time when left empty as far as I understand.

Now my question is, will using this tool make it obsolete to change the product code? Or are there Windows Installer compatibility issues anyway because of identical components GUIDs, even if the product code is changed?

[acenes]

Forgot to mention: For my side-by-side installation scenarios I also include the version in the product name, in the menu folder name and in the installation folder name. So it is completely separated like two separate products.

I came across a thread on stackoverflow where it seems that changing each component GUID is not necessary then:

http://stackoverflow.com/questions/5866954/wix-project-allowing-side-by-side-installation/5869087#5869087

Other sources on microsoft tell the vice versa, or are they just not complete:

https://msdn.microsoft.com/en-us/library/aa372830.aspx?f=255&MSPPError=-2147217396

[Ulrich]

This utility was created for a user of MSI Factory who wanted to create a new project from an existing one, and replace all GUIDs because the projects wouldn't share the same files. While the filenames might be the same, there would be different binaries in the MSI, as he wanted to build similar projects using localized, debug, or OEM versions of his files.

In normal situations, replacing just the product code and upgrade codes should be enough - unless you also are using different releases of files with the same name, so they perhaps shouldn't share the same GUID.

Ulrich

[acenes]

Now I did some testing in the topic with side-by-side installations in a typical order as my customers often do:

• Install version 2.1.0
• Install version 2.2.0
• Uninstall version 2.1.0
• Uninstall version 2.2.0

My first test was as described above, without using your tool. The result is:

• Program files of both versions are uninstalled. :yes
• Services of 2.1.0 are removed, but services of 2.2.0 remain.
• Shortcuts of 2.1.0 are removed, but shortcuts of 2.2.0 remain.

Now I ran your tool against the installer for 2.2.0, and the result is better yet still not perfect:

• Program files of both versions are uninstalled. :yes
• Services of both versions are uninstalled. :yes
• Shortcuts of 2.1.0 are removed, but shortcuts of 2.2.0 remain.

Any idea why the shortcuts are still not completely removed?

[acenes]

I compared the files before and after running the tool. It appears that the GUIDs in UserProfileComponentGuid are still identical, could this be the cause why the shortcuts of one version remain?

[acenes]

I manually changed that GUID for one of my exe files having a shortcut, and now that shortcut is deleted properly.