Tips & Tricks: Repackaging With Wise

Using SetupCapture Wisely

SetupCapture is the "guts" of the repackaging process, and as such it's messy and gooey and nobody really wants to touch it. But you've got to, so here are a few suggestions to make the best of the experience.

• Build an Exclusion List. The initial SetupCapture Configuration helps you to automatically generate a list of files and registry keys which are likely to be changed during your capture time but should not be included in the package. This includes the operating system stuff that gets recorded during and shutdown and restart, and much more-if these were written to your target installation machines, they could cause some serious problems there. To build the list, just follow the directions: run Notepad, WordPad and Internet Explorer; reboot and login again (don't close SetupCapture before you restart-it will close itself and automatically open again when you login after the reset). The program will capture all the changes and ignore those items when you do SetupCaptures in the future.
• SetupCapture (especially if SmartMonitor is enabled) will find every file and directory that changed during the capture time, including temp files and such. You may think temp files aren't included, but if you look at your resulting package you'll often find that the directories will be created even if they're not populated with any files. One easy way to avoid some of this is to start the "unpacking" part of the original setup program before you run the initial snapshot portion of SetupCatpure; that is: don't start SetupCapture until the setup is just at the point where it's about to make changes to the system (i.e. dropping the files and registry entries), let it do the snapshot then hit the "Next" button on the setup for the work to begin.
• Reboot the PC before you have SetupCapture do the final snapshot and comparison: even programs that don't "need" a reboot might have put some RunOnce registry entries in for the next reboot, and you want these to be completed in your captured package. (Think about this: on machines which have your package installed, the next user to boot or logon might not be an Administrator, and s/he might not have the privileges to run the command that the RunOnce key wants.)
• After SetupCapture has compared the snapshots and gives you the results with the drop-down selections for Files, Registry Keys, INI Files and Shortcuts, take the time to look at these results now before you have it complete the package. There are several advantages to looking at this now rather than manually removing unnecessary items from the MSI later. One is that if the found files/keys are excluded now it will not create them in the MSI at all, but if you delete them from the MSI then you'll have to track down and remove the empty directories and components there, too. Also, now is your change to use the "Exclude Globally" button, which allows you to add the selected items to the Exclusion List you built earlier so they never bother you again. For example, if the registry entries under HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed appear in your SetupCapture, you should have them excluded so that future captures don't find this unnecessary item.
• Don't neglect the Excluded Items dialog either! It is certainly possible that your Exclusion List excluded items you do want to keep, such as new printers. This is your last chance to add them in easily; if you wait, you'll have to do it all manually from WfWI later, and you'll probably have to sort through the Changes Report to find the right items, too.

Wise Package Studio's SetupCapture application has a number of configuration options which can affect the quality of the resultant package. I will discuss them here by the option description:

• "Include files deleted during capture" and "Include registry keys deleted during capture": Unless you are trying to capture an upgrade/patch, you probably don't want to use these options
• "Capture changes in hardware registry entries": In reality, this means most of the data in the HKEY_LOCAL_MACHINE\SYSTEM key (which includes services and other non-hardware-related stuff) will be ignored unless you select it. Also keep in mind that adding or changing printers is also a "hardware" entry, and thus you'd want this checked.
• "Allow root to be watched during capture": This may cause you more confusion than it's worth, and it's highly unlikely to be needed.
• "Capture non-Microsoft ODBC information": You will probably want to leave this checked all the time, just in case the target app does use an ODBC connection (it's possible even for local data files). The rare exception to this rule is when SetupCapture mangles the resultant ODBC connection (for example, in capturing Oracle drivers WPS does not work well): in this case, directly add the related Registry entries from HKLM\SOFTWARE\ODBC\ODBC.INI as they are into the package and it should work fine.
• "Enable ordering of self-registration" and "Create installation sequence report": These options are only useful if you're using SmartMonitor (or SmartMonitor and snapshot comparisons, which is recommended). See the above comments on Capture Methodology for a few pointers.
• "Advertising Setting (Windows Installer)" drop-down selection: In nearly all cases you should choose "Convert registry entries into advertising info", with the only exception being when you are certain you do not want any advertising or self-healing in the application. (This selection is not just related to MSI advertising, but really it has to do with whether WfWI decides to add the registry information as-is to the Registry table or pick it apart into the respective pieces: file associations, services, etc.)
• "Installation Changes Report" drop-down selection: If you expect to need to munge the report with Excel (for particularly messy captures), you'll want to include a comma-separated-values (CSV) report. Otherwise, the web page (HTML) will do fine, but be sure that you do make some sort of report, because you never know when you'll need it.

Validate, validate, validate!

The Internal Consistency Evaluations can be your best friend in troubleshooting and preventing problems with your MSI package. At first, they look quite daunting and confusing, but once you understand Microsoft's MSI suggestions such as the component rules, it will begin to make sense. Get used to it-you're going to have to use it.

I recommend running the Package Validation program before you begin any testing on the MSI, or after you make any changes during the testing-and-fixing and deconflicting phases. Always address the errors in the WSI immediately if you can. If you don't understand the output (after all, the log entries are rather terse), look up the ICE rule number on this page and read up on it.

Of course, there are a few common errors that you can probably safely ignore. Here are a couple examples:

• ICE09, "Component XXXXX is a non-permanent system component." This happens when the system expects that a certain file type (say, a Control Panel .CPL, for example) should be installed permanently (i.e. never uninstalled) in the System folder, and it is not configured as such in your MSI. If your app has these files in its own directory and you know its alright to deinstall them, then this error is really negligible.
• ICE33, "Reg key XXXXX is used in an unsupported way. YYYYY should be registered via the YYYYY table." There are times when you actually want to drop in the registry entries directly instead of have the MSI Class, TypeLib, ODBC, or other methods set them.
• ICE38, "Component XXXXX installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file." This message will show up even for shortcuts installed in the All Users profile, and in that case you want to leave it as-is. Unprivileged users may not have the right to write to the All User's profile, so any MSI advertisement or self-healing could fail. The initial install from an admin-level account will populate the All Users Start Menu just fine.
• ICE64, "The directory XXXXX is in the user profile but is not listed in the RemoveFile table." This warning will show even for the directories in the All Users' Start Menu, and they will nonetheless still be properly removed without any changes to the RemoveFile table.

Keep in mind that the above are just a few suggestions, and there may be situations in which you'd need to address those warnings/errors as well-for example, if you're deconflicting apps with similar DLL's by the isolation method.

Resolving & Causing Problems with ConflictManager

Wise Package Studio's ConflictManager program is handy, but far from perfect. Its most useful function is the database comparison of file versions and registry entries; its least useful function is the "automatic" conflict resolution.

I would recommend that before you ConflictManager at all, you should print out and carefully read the WPS documentation on Resolving Conflicts (under "Wise Package Studio\Help," ConflictManager.chm or ConflictManager.pdf) and the MSI SDK documentation on Isolated Components. It's likely to take a couple readings until it starts to sink in.

With that said, then I'd recommend that when you set up to resolve conflicts, you let the program try it on its own using the "Resolve with Rules…" wizard. I'd even recommend the "Aggressive" setting for the newer operating systems like Win2k and XP. You will likely still be left with some warnings and conflicts to resolve on your own, such as registry and INI file values.

Once ConflictManager has figured out how to resolve the items it found, don't forget to Export and Recompile (from the Packages menu) before you close the program. (You might also want to have a backup of your WSI & MSI before doing this, for reasons which I'll explain momentarily.) Then, before you try anything else with the package, you must re-run the Internal Consistency validation suite and act on the findings by editing the WSI yet again. This is because ConflictManager, as I mentioned above, is far from perfect. Its attempts to isolate the components and such are valiant, but it may make a mess of your package, too, breaking the component rules by moving files all around and so on. That's why you have to know what you're doing so you can fix it up by hand.