Consolidating multiple wxs files with the same file structure

[tristanlabelle]

I would like to consolidate multiple wxs files that have the same directory structure and components. This is for the Swift toolchain on Windows where we currently have nearly duplicated installer definitions for our three supported architectures: x86, amd64 and arm64 (see runtime-***.wxs files here). The reason we have multiple files is that we want to support installing multiple runtimes on the same machine (x86 and x64), and we believe this requires that our components have different GUIDs for each architecture (is that correct?), and there are a few other smaller changes like ProgramFilesFolder vs ProgramFiles64Folder.

We've thought of using a single file with guids that have an arch-component such as 6ef8eecb-780a-46a0-$(var.ArchGuidComponent)-79b9a7bb8316 so they would be unique on each platform and using similar $(var.ProgramFilesFolder) substitutions to account for other differences. Is this the way to go? (especially for guids)

[robmen]

As long as the MSIs install the different architectures into different folders (which I think is what you are saying with the ProgramFiles references, and presumably you do since they can all be installed on the same computer), WiX can auto-assign the GUIDs for you.

If you want a deep analysis of your project, we offer code reviews at FireGiant. But after a quick look at your code, in your next major upgrade (aka when you can change the GUIDs), I'd recommend a pattern more like:

<ComponentGroup Id='PickSomethingUseful' Directory='ReferenceTheRootDirectoryForTheFollowingComponents'>
  <Component>
     <File Source="path\to\file.ext" />
  </Component>
</ComponentGroup>

I bet on a deeper review there is a lot you could simplify with a few Fragments and maybe even share with a .wixlib.

My first impression is that you're typing a lot more .wxs code than is necessary.

[tristanlabelle]

Thanks for the GUID guidance in your reply below. I'll mark this as the answer and we'll try it out!

[barnson]

Also take a look at ProgramFiles6432Folder.

[compnerd]

I was under the impression that auto-generated GUIDs did not do upgrades very well (and is part of the problem with the use of heat). If that is not the case and you can use auto-generated GUIDs, that sounds really interesting.

[barnson]

Random GUIDs are bad. GUIDs that WiX computes for you follow the rules.

[robmen]

First, there are many issues with heat. Do NOT use heat to generate new GUIDs every execution of heat. If you use heat and see GUIDs, change the arguments to heat to stop that.

Second, remove the Guid attribute from your Component as soon as you can do your next major upgrade scheduled early (aka: when you can break the Component Rules). The WiX Toolset will take care of the GUID for you. If WiX cannot take care of the GUID for you, it will tell you in a nice big error message. Then, try to do what it says and let WiX take care of the GUID for you.

Stop filling your .wxs files with GUIDs. If you watch the Deployment Dojo (gosh, I never imagined the show would be so useful to reference here), you will see I create one GUID for many, many, many episodes: the UpgradeCode. It isn't until when we do a deep dive into non-Advertised Shortcuts that I have to create a Component GUID and (spoiler alert) I'm able to remove that GUID by the end of the episode.

Write less code. Let WiX do the right thing for you automatically. 😄