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.
Ini Files should be retained as INIFile Table Entries not as Files, to the extent possible.
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.
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.