Preserving Component GUIDs Question

[clayton]

When working with a Basic MSI Project to create a setup.exe, is it necessary to preserve the GUID’s created for each component or can they be different in future packages? For example, if I deleted a component and then readded it, which gives it a new unique GUID, what would be the ramifications of not preserving the original GUID?

I am in the process of automating the generation of the setup.exe as part of our build process using a mostly configured Basic MSI Project as a template and a vbs script. The process of adding components to the project is automated via the vbs script by reading a text file containing the list of files that need to be added as components. There is a concern that since I am generating the component list dynamically every build, each component in subsequent versions will have a unique GUID component from it's predecessor. I know I could carry a project file forward preserving the GUID’s each time this process runs however by not needing to do this it keeps the process fairly robust as then I don’t have to worry about synchronizing between the list and the project file.

One answer to this concern is that I have designed a routine that will generate a consistent, hopefully unique GUID component code based on the name of the file. This should ensure that in future versions of the install, the components of the same name will share the same GUID that they did in previous versions. The only problem I could see with this routine is since I am generating the GUID in a nonstandard way, I presume it’s possible I could end up matching another GUID “out there”. I also generate the upgrade code similarly to preserve links between major/minor versions of the application. What would happen if a component ended up matching an existing GUID on an end user’s machine of another software package?

Presently, our upgrade path is all upgrades are treated as major; we do not release patches at this time.

Thanks
Clayton

[#2]

I believe the MSDN article "Changing the Component Code" should answer your questions,
http://msdn2.microsoft.com/en-us/library/aa367849.aspx

[saybo2]

Interesting. I'll test with changing the component code to see if that fixes the issue. This article, & its related ones, don't explain why the file was still removed from Program Files, but I don't need to understand that, I just need the other things removed too.

Where are the components tracked by Windows? I don't see them in the registry. They must be listed without the Product Code to differentiate them.

[clayton]

Thanks for the link bryanwolf. Correct me if I'm wrong but reading that it appears that it is in my best interest to let it continue generating unique GUIDs everytime since I am always dealing with newer versions of the files and we haven't tested nor intend for versions to be compatible with previous versions.

Thanks
Clayton

[Stefan_Krueger]

If you change the ComponentId GUID you must either change all the file names, too, or install to a different folder. Don't install on top of the existing version.
And you won't be ablt to create Small or Minor updates, only Major Upgrades.

[clayton]

Thanks for the response.

Maybe I should spell out our upgrade process.

Currently, service packs are installed in the same folder of their Major/minor version (ie: SP2 for 4.2 will install into the 4.2 folder) using major upgrade, as in it completely uninstalls and then reinstalls into the same folder.

Different major or minor versions install into their own folders and are intended to operate independently from other major or minor versions (ie: 5.0, 4.1 and 4.2 can coexist on the same machine in their own folders).

So I should preserve component GUIDs for the same file names even though the version of the files are newer when destined for the same folder as it’s previous version? If the folder changes, I should change the GUID and preserve those new GUIDs for continued versions installed in that folder or can I just continue to preserve the existing GUIDs?

Thank you,
Clayton