Best Practices to follow while Packaging Applications

Hard-coding should be avoided

In an MSI, Hard coding should be avoided to the maximum and should be replaced by properties. For e.g. instead of “C:\Program Files\…”, property “ProgramFilesFolder should be used.

Least Use of custom actions involving 3rd party tools

Any changes which are being made to the system during an installation should possibly be made through an MSI involving least use of 3rd party tools. For e.g. If an UI Installation needs to created, it should be done through MSI Dialogues not through Visual Basic exe’s. If a file has to be installed conditionally, same should be done through MSI’s functionality not through VB Scripts.

Deletion and allocation of resources (files, registries) to proper components.

During Setup capture, Wise package Studio, captures lot of junk registries and usually you will find all these registries in a component by name “registryXX”.
This component needs to be carefully looked at since this component will have registries which otherwise should belong to other components. For e.g this component will have registries for e.g HKCR\CLSID\{GUIID} or HKCR\Interface\{GUIID}.If there is a dll in your application and registration of this dll has this GUID, then this registry should be moved from this component to the component having this dll else this registry is categorized as junk registry and needs to be removed.

 Ini Files should be retained as INIFile Table Entries not as Files, to the extent possible.

Ensure that any INI file changes are recorded in the INI file table, rather than just as files in the file table. This will ensure that INI files are edited if they exist already, rather than replaced with the version within the MSI Package.

Shortcuts should be made as “Advertised” shortcuts to the extent possible.

This is to ensure Self Healing.

DLL’s should be registered through Advertising Tables to the extent possible.

This is to ensure Self Healing and minimize registry conflicts.

As soon as you realize that the source installation is an MSI or installs an MSI embedded in it, it should be scripted as Vendor MSI.There should be no empty components in the MSI.

 Only COM Dll’s should be isolated.

If any custom actions are used, “In-Script” options and “Processing Options” need to be set correctly for them.

During Setup Capture

if it’s observed that lot of .INI Files have got captured, it’s better to exclude the INI files from the capture and then a second capture can be taken just with INI files or the INI files can be added as files, else the capture will take several hours and some times may not complete.

it’s possible that .INI Files, .INF Files, .HLP Files or .CHM Files do not get captured properly. To make sure all these files are present in MSI, it’s better to compare the size of the application folder in target machine (where application is installed) with captured folders after Setup Capture.

In some applications, it’s required to do the capture in some specific accounts and Wise can’t be installed in that account. In such cases it’s better to use the Wise as “run as” rather than going for some other capture techniques.  

Note: Run as account should be the account in which Wise is installed.


Lot of CHM files

 When there are lot of CHM files need to be added in the script which might have missed during capture, add it to the components directly rather than adding through Installation Expert. The reason for this is if you add through Installation expert, then the CHM files will be moved to the components, which is already having some CHM files, getting installed in some other folder.