2

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.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
whywhywhy
  • 278
  • 1
  • 5
  • 15

2 Answers2

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.

Community
  • 1
  • 1
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • @Glytzkof thanks for the quick response, we will try this approach! – whywhywhy Sep 19 '14 at 09:48
  • Also note that [**you can leave out a lot of source attributes from your Wix xml file**](http://stackoverflow.com/a/24769965/129130) and rely on Wix defaults instead of hard coding values. – Stein Åsmul Sep 19 '14 at 10:01
  • Just out of curiosity, if it was a .net file that cannot be renamed how would we do it ? – whywhywhy Sep 19 '14 at 10:18
  • 2
    A final comment: some .net assemblies are by definition multi-file. In these cases ALL files making up the assembly, should be installed with the same Wix component. This is to make the files an "atomic unit" as a collection, rather than as a single file. This is a fringe case of the general advice to always use a single file per component in Wix to avoid upgrade problems. – Stein Åsmul Sep 19 '14 at 11:07
1

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):

enter image description here

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.

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