Safely resolving duplicate component GUIDs in Wix

2019-07-15 21:52发布

问题:

Recently we discovered that we have a duplicate component GUID in our Wix script. The common GUID is used for 2 files with different names but in the same directory. I did some searching on the net found that, this can lead to problems later on, but cannot find any satisfactory resolutions of the same problem.

Is there a safe way of resolving this issue? Thanks.

回答1:

Can you rename the files and give them both a new guid each? This is the safest approach - it decouples all reference count issues. By renaming a file you create a new absolute path (path + file name) for each file, and Windows Installer essentially reference counts an absolute path by assigning a single guid.

Some further explanation of the concept. Recommended read, I think it will be clearer: Change my component GUID in wix?

Note: Be careful renaming your dll files if you are writing c/c++ using lots of delay load.



回答2:

I will add this as another answer, since it is effectively a different approach to "solve" the problem.

You can "solve this" by assigning two new guids to the files and use a major upgrade with RemoveExistingProducts early in the InstallExecuteSequence to "decouple" the two product versions from one another entirely. This form of upgrade effectively disregards Windows Installer's component rules and installs the upgrade as if the older version never existed. Many companies standardize on this type of upgrade scenario, though it is both inefficient and slow, since it eliminates most of the problems resulting from component referencing.

Important rule of thumb: No minor upgrade or patch can be used when you don't do component referencing correctly. I guess most Wix users know this.

(When two files share a guid, it is technically possible to just give one of the files a new guid, but I never do this to avoid legacy problems resurfacing. In particular older style legacy sharedll reference counting may end up interferring: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs. This flag is written if the Wix component has the msidbComponentAttributesSharedDllRefCount bit set):

This is the reference counting from before Windows Installer, and it is used by Windows Installer too in order to "communicate" with legacy style installers that otherwise might just delete files that are reference counted by Windows Installer.

I do not set this flag for any files that I don't install to shared locations, and I believe this to be a good approach. Installshield used to set this shared dll property for all components, and this causes many strange stray files to be left behind on uninstall. In other words: only enable this flag if you install to a genuinely shared location since the flag is generally more a problem than a solution.

If you share files between your own applications and don't need the files available for third party applications, just install them to ProgramFiles and share them via Wix include files.