2

I'm filtering through existing questions, but none that I see answer this definitively on this basic level. I'm building my WXS files in notepad, not from an IDE.

Me scenario is: I have multiple applications that use some of the same assemblies. These assemblies are installed to individual application folders with the exe, so they are not shared among each other. They may be different versions. Folders look like:

App1: main1.exe, 1.dll, 2.dll
App2: main2.exe, 1.dll
App3: main3.exe, 1.dll, 2.dll

I'm templating my WXS files, but before I get too far, I am trying to figure out if I can copy/paste Component elements across applications.

App1.wxs:

<Component Id='AudioLibrary' Guid='1111-1111111-1111111-11111' Win64='yes'>
    <File Id='AudioDLL' Source='1.dll' KeyPath='yes' />

App2.wxs

<Component Id='AudioLibrary' Guid='1111-1111111-1111111-11111' Win64='yes'>
    <File Id='AudioDLL' Source='1.dll' KeyPath='yes' />

Will these two entries interfere with each other in upgrade/uninstall actions across the different applications?

Usually, database structures allow this type of duplication, because the parent would be the unique product guid. But I see a lot of complaints that MSI must have been written in the '70's when everyone was high on acid. So before I waste days building everything out, checking to see if I'm setting myself up for failure.

edit: I also want to include apply this to SQL script Components; can I copy/paste a snippet into any wxs file without having to generate a new GUID for it as well?

DaveA
  • 33
  • 5

1 Answers1

0

Component GUIDs & Absolute Paths: Please read this old answer: When to change component GUIDS. Essentially there is a 1:1 relation between an absolute path and a component GUID. If you change the file name, or install to a different folder, you must make a new component GUID. Hence if you install to the same folder for all products, you should use the same component GUID for what you install. If you install to a new folder per product they should have different component GUIDs.

Merge Modules: Shared components are generally to be installed via merge modules. Personally I like WiX include files better than merge modules as a concept.

WiX Include Files: The premise for WiX include files is that you can declare a group of components once in its own source and include in any number of setups - like a C++ header file. If you let the component GUIDs be auto-generated you should be able to include the same WiX include file in different MSI files and the logic will take care of generating new GUIDs for the components or use the same one depending on what locations on disk they target. I have not tested this. Here is Rob Mensching himself on the auto-GUID concept.

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Unfortunately, this is in reference to changing the Component itself within the wxs file. It does not speak to the re-use of Component elements across separate, unrelated wxs installs. The Components themselves will never change, as these are my standard libraries I use in all my applications. – DaveA Apr 11 '21 at 13:58
  • If the files go to different folders they should have different component GUIDs. If you leave out the GUID and use auto-GUIDs whenever you can this should take care of the GUID-logic for you. [Do you deliver several applications with one MSI](https://stackoverflow.com/a/1546916/129130)? – Stein Åsmul Apr 11 '21 at 14:50