This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Preserving Component GUIDs Question
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 19, 2007
04:48 PM
Preserving Component GUIDs Question
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
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
(5) Replies
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 20, 2007
11:37 AM
I believe the MSDN article "Changing the Component Code" should answer your questions,
http://msdn2.microsoft.com/en-us/library/aa367849.aspx
http://msdn2.microsoft.com/en-us/library/aa367849.aspx
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 20, 2007
12:28 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 20, 2007
12:51 PM
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
Thanks
Clayton
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 23, 2007
05:36 AM
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.
And you won't be ablt to create Small or Minor updates, only Major Upgrades.
Stefan Krueger
InstallSite.org
InstallSite.org
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 26, 2007
09:27 AM
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
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