cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mikegillow
Level 5

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
Labels (1)
0 Kudos
(3) Replies
Christopher_Pai
Level 16

If you are basically refactoring merge module components into installer components you could just perform administrative installs of both packages and use cygwin diff to compare the directory structure. This will show you if the files are different or new/missing.

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
0 Kudos
mikegillow
Level 5

Thanks, Chris. Anyone have ideas on how to quickly check other things like registry entries, permissions, etc? (I have to confess that I'm not holding out much hope 🙂 )

Mike
0 Kudos
Christopher_Pai
Level 16

Nothing out of the box but ad-hoc techniques would involve one of two concepts:

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.
0 Kudos