mag1.5524947131612073E12 asked a question.
Retooling install - how to compare with predecessor?
Is there a tool to compare the results of running two different MSIs on the same base machine? I am retooling a set of install packages to eliminate a number of merge modules I had previously authored and am trying to avoid the time-consuming regression testing that will be necessary to make sure that the new install does exactly what the old one did. I tried MSIPackageDiff, but that just compares the tables and not the actual resulting changes. Since I am incorporating components from merge modules, the table comparisons generate a large amount of data to weed through and I am looking for the one or two needles in the haystack of things I overlooked in the move.
FYI: Why am I retooling to eliminate my Merge Modules? - as I undertsand it, one of the rules for triggering a Major Upgrade is a change to a component in a merge module. Every release that I build has a change to one or more of the components currently contained in one of my modules, so I have to author every build as a Major Upgrade. I have two product installers with a large number of components in common, so I went the route of merge modules to save duplication of effort when maintaining the projects. The minimal time savings I realized on the authoring end has been dwarfed by the time consumed by processing a Major Upgrade install every time the product is updated. By absorbing the merge module components back into the main install program, I expect to be able to roll out most builds as Minor Updates/patches.
Mike
msiexec /i foo_old.msi TARGETDIR=C:\diff\old
msiexec /i foo_new.msi TARGETDIR=C:\diff\new
del C:\diff\old\foo_old.msi
del c:\diff\new\foo_new.msi
diff -qr c:\diff\old c:\diff\new > differences.txt
notepad differences.txt
Mike
1) Database Evaluation : Write a Custom ICE that simulates costing and generates a dataset that represents what the install would do. Run the program twice and compare results. Rinse and Repeat.
2) Runtime Profiling : Use tools like InCtrl3, RegistryDiff and generate a report of changes made by the install. Filter out changes made my background processes. Run the program twice and compare results. Rinse and Repeat.
Sorry I don't have more advice..... I'm in a .NET shop now so everything we do is XML based and I've always avoided ACL changes because it's usually the wrong answer to the problem in the first place. Usually if I can diff the file tree, verify the shortcuts exist, check the service exists and the websites also, we are doing pretty well. In fact we wrote a test program that consumes all of ourwebservices and performs unit tests so I always have good feedback without jumping through hoops.