If the MSM is backwards compatibile, then the GUID need not change and you can simply update the version. If it's not backward compatible you must change the GUID in the ModuleSignature table.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
When should the merge module GUID be changed?
Started by
Stefan Krueger
, Jan 26 2005 10:03
4 replies to this topic
Posted 26 January 2005 - 10:03
Stefan Krüger
InstallSite.org twitter facebook
Posted 18 June 2005 - 13:19
Would this affect the installed locaton of the merge module files?
Regards
-Stein Åsmul
-Stein Åsmul
Posted 28 June 2005 - 16:41
In Windows Installer's ideal world (and regardless of backwards compatibility) if the Keypath remains the same, dispite the version changing then the ComponentID has to stay the same does it not?
Posted 02 August 2005 - 14:41
If the keypath is the same then the componentID has to remain the same as this would break self-repair and reference counting. Changing the GUID does not affect the location on installed files.
The only times you might want to consider changing merge module GUIDs is when you have a vendor supplied MSI who have their own merge modules inside it. For example MS Office applications or Crystal Reports. Best thing to do normally for common controls and COM .dll files is to match their GUIDs with the Microsoft ones because Office applications are most often deployed first.
Crystal Reports is another matter completely. I would advise creating own merge modules for Crystal Reports because their merge modules break Microsoft best practises(although some MS merge modules break them too...). It happens often that Crystal changes the location of installed files between versions eg. from CommonFilesFolder/Seagate Software to SystemFolder. Also if a COM .dll had a name FOO.dll sometimes Crystal changes the filename to FOO2.dll but the COM information remains the same!
What I normally do is create merge modules from old version of the application eg. Crystal 8.0 and match the new merge modules GUIDs (8.5...9.0...etc) with the old ones.
Problem is that if you change GUID:s on vendor MSI's this will break upgrade functionality.
Tough question to answer.
The only times you might want to consider changing merge module GUIDs is when you have a vendor supplied MSI who have their own merge modules inside it. For example MS Office applications or Crystal Reports. Best thing to do normally for common controls and COM .dll files is to match their GUIDs with the Microsoft ones because Office applications are most often deployed first.
Crystal Reports is another matter completely. I would advise creating own merge modules for Crystal Reports because their merge modules break Microsoft best practises(although some MS merge modules break them too...). It happens often that Crystal changes the location of installed files between versions eg. from CommonFilesFolder/Seagate Software to SystemFolder. Also if a COM .dll had a name FOO.dll sometimes Crystal changes the filename to FOO2.dll but the COM information remains the same!
What I normally do is create merge modules from old version of the application eg. Crystal 8.0 and match the new merge modules GUIDs (8.5...9.0...etc) with the old ones.
Problem is that if you change GUID:s on vendor MSI's this will break upgrade functionality.
Tough question to answer.
Posted 10 September 2005 - 10:02
My experience while doing application repackaging is that 98% of vendors have no respect for the component rules, and that most upgrade simply do not work. Crystal reports is indeed a world of pain - remarkable that such a big company can't get basic business tools to work right.
Regards
-Stein Åsmul
-Stein Åsmul