When should the merge module GUID be changed?
Posted 26 January 2005 - 10:03
Posted 18 June 2005 - 13:19
Posted 28 June 2005 - 16:41
Posted 02 August 2005 - 14:41
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