When I should not change my component GUID in WIX?
A:
Have a look at the WiX Tutorial, Lesson 1.2, for a detailed explanation on component rules. Basically, it says you never change the GUID of a component, since that means orphaning the old component and creating a new component.
OregonGhost
2009-09-10 12:55:26
+1
A:
You never change the Component/@Guid. You also never change the set of Resources (File, RegistryKey, Shortcut, TypeLib, etc.) in the Component. When you have a new Resource, you must create a new Component with a new @Guid. The really tricky part is that new Component can have no overlap (think file path, or registry key path, or typelib, etc.) with the old Component.
These are basically the Component Rules, check out: http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101.
Rob Mensching
2009-09-10 14:29:05
Do the location of component install as any effect?
Rohit
2009-09-10 15:02:47
Yes and no. :) If you change the Component/@Directory then you do not *have* to change the Component/@Guid but you may if you want... as long as there are no other Resources in the Component (like Registry keys). If there are other Resources in the Component and you change it's Guid then all the Resources need a new name or path. The new location will take care of the files, of course.No, Component Rules are not simple.
Rob Mensching
2009-09-11 10:49:28
+2
A:
The overall concept of MSI is that there is a 1:1 mapping between a component GUID (unique identifier) and an absolute path (install location / key path).
I use some simple rules to deal with the overly complex and nonsensical component rules:
- Always use a separate component per file (even for non-binaries). This avoids all kinds of problems.
- Remember that once you have allocated a GUID for a component, it's set in stone for that component's key path (absolute path). If you move the file to a new location or rename the file, give it a new component GUID (since the absolute path is different it's effectively a new identity).
- In summary component GUIDs are tied to an absolute installation location, and not to a specific file. The GUID doesn't follow the file around if it moves.
Some samples:
- You rename the file C:\Program Files\MyCompany\MyApp\MyFile.exe to C:\Program Files\MyCompany\MyApp\MyFile_NEW.exe. What does this mean for component creation? This is a new absolute installation path, so you generate a new GUID for the hosting component, OR you add a new component and delete the old one (which has the same effect).
- Your updated MSI delivers a new version of MyFile.exe. The location is the same as before, this means the component GUID should not change.
Glytzhkof
2009-09-14 15:02:32
The part about "absolute path" is not exactly true. You can install the same Component (same GUID) to different directories and the reference counting works correctly. Directories put a wrinkle in the simplicity of the statements above.
Rob Mensching
2009-09-26 06:57:04
After file costing and resolution of the directory table with its directory properties and after the user has (maybe) selected an installation directory, the component GUIDs will point to absolute key paths? I think the simplest way to look at this is to focus on your source folder - if you move a file in your source folder you change the GUID. The actual install location is a "moving target" up until the point where are directories are resolved, but you always end up with an absolute path as key path for every installed component as far as I know?
Glytzhkof
2009-09-26 18:28:23