RE: [WiX-devs] Re: [WiX-users] Extending Heat

[Derek Cicerone]

This is very promising, here’s some feedback which may or may not be correct (since I’ve never had to create a component catalog): -          Why would the MutatorExtension come last?  Wouldn’t you want it to set the guids and identifiers of Component and File elements prior to the UtilMutator (which will also set those values if they aren’t present)?  Then the UtilMutator and other mutators can do what they do best for any unknown components/files. -          Nothing should ever be removed from the database.  New components and files should only be added as they are shipped.  The database needs to remember anything which you’ve shipped to ensure there are no collisions. -          Components and files should be added to the database from the msi files just prior to being shipped.  This ensures that the guids and identifiers which you care about in terms of the component rules are the ones you are tracking. -          Just to be safe, there should also be a process which runs on msi files about to be shipped to verify that all the guids and identifiers match the expectations from the database (in case someone manually authors in a new component).   I’m planning for a new class in wix which can take an msi file and turn it into an output – this would probably help for the 3rd and 4th items above because then you can just work with the Output object instead of making queries directly against the database (which is slower).   You may seek additional advice from Rob on this one since I believe he has worked on this type of a problem before.   Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carter Sent: Friday, May 12, 2006 1:42 AM To: WiX-devs@lists.sourceforge.net Subject: [WiX-devs] Re: [WiX-users] Extending Heat   Okay, I follow you. Here's what I'm thinking: The component catalog extension should be implemented as a subclass of MutatorExtension. It's sequence should be set such that it executes after all other mutators. The class deriving from the HeatExtension class will look for an argument called "catalog" which will specify the location of an existing component catalog, or one to be created. This in turn will be passed to the mutator. Forgive my bastardization of all languages related to c/c++/c#/pseudo-code. :) if (component database exists) {   load component database   foreach (component in component database)   {     if (component id exists in new authoring)     {       foreach (file in component)       {         if (file exists in new authoring) // existing files         {           generate hash for existing file on disk                      if (old hash equals new hash)           {             keep database component guid             keep database hash           }           else           {             keep new component guid             keep new hash           }         }         else if (file not exist in new authoring) // old files         {           remove file from database                     keep new component guid         }         else if (file exists in new authoring and not in database) // new files           add file to component database        endif       }     }     else if (component id not exists in new authoring)     {           remove component from database           advise user to change product guid     }   } } else if (component database not exist) {   create a new database   foreach (component in new authoring)   {     add component to database     foreach (file in component)     {       generate file hash       add file to component in database     }   } } I thought using a fast hashing algorithm (SuperFastHash [http://www.azillionmonkeys.com/qed/hash.html] )  would allow you to know when a file has changed. It's 1:35AM, so I may have missed some details, but I wanted to get this posted. Thoughts are welcome. Adios, James