1

I am creating a new version of an existing setup with WiX. In the process, the version of an included third party product has been updated. It consists of several files (DLLs, Configs, exes), each of which is in its own component.

Do I need to change the GUIDs of all these components?

The new version of the third party product requires a newer VC redist package than the old version, so it is not backward compatible.

The names and destinations of the affected files are the same.

I have read
https://learn.microsoft.com/en-us/windows/win32/msi/changing-the-component-code?redirectedfrom=MSDN
Change my component GUID in wix?
but I am honestly even more confused now.

If it wasn't for the redist dependency change thing, I would have just put the new files in the places of the old ones and left the GUIDs the same.

But now?

sawie
  • 241
  • 2
  • 9

1 Answers1

2

The names and destinations of the affected files are the same.

Overall: This basically means that you should keep the same component GUIDs as before. The component GUID essentially identifies a target destination. If the target destination (the absolute path) changes you need a new component GUID.

File Name Change: Keep in mind that renaming a file changes the absolute path even if the path stays the same - hence you need a new component GUID for such file name changes.

Runtime: The incompatibility of the runtime should be irrelevant for the component GUID issue. What third party product is this? Perhaps it has its own installer? If it does it can potentially interfere with your installation in other ways (COM registration etc...).

Setup.exe Launcher: The standard procedure is to bundle runtimes in a setup.exe wrapping your MSI and all runtimes it requires. WiX offers the Burn framework to make such setup.exe launchers. Perhaps try my deployment info search grid for info on Burn. Also: Make yourself a single page PDF explaining your application's runtime requirements for corporate use and include it in your setup.exe so your setup is easy to deploy large scale.

The MSI File Itself: You can also add launch conditions to the MSI to identify that a required runtime is missing (so you can abort) - or you can use a custom action to inspect the system (I find this more flexible, but custom actions in general are complex. Use them read-only - for inspection only, and they are safer).

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164