This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Retooling install - how to compare with predecessor?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2008
09:08 AM
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
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
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2008
09:12 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 28, 2008
08:55 AM
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
Mike
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 28, 2008
11:50 AM
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.
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.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)