Here are few points which would prove handy while re-packaging an application for Vista / Windows 7.
1. If you must make a change on the system via a custom action, ensure that the custom action is deferred and the msidbCustomActionTypeNoImpersonate bit is set. This will ensure that the custom action inherits elevated privileges from the installed
2. Place all your custom actions in the Execute Sequence to ensure that they are invoked during silent mode and use appropriate conditions on the custom actions to only run when intended
3. Test your application for a locked down user. If necessary, give the user permissions to access folders and registry keys that the application tries to write to via the Locked Permissions table. Do not open higher level folders such as C:\Program Files, C:\Windows or C:\Windows\System32 for locked down users. Instead, set permissions on the exact sub-directory that the application needs access to:
4. AdminUser property commonly used to check for admin rights will not work in UAC. Microsoft has decided to set this to TRUE by default for Application Compatibility reasons. Use MSIUSEREALADMINDETECTION property instead.
5. Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.
6. Turn off Virtualization feature. This will ensure that, duplicate files and registries are not created. This mainly happens to the applications which need a launch. The keys which are virtualized can be removed from the package as well.
7. Add support for Vista-specific features 🙁 This can be found in the “Windows Installer Options” dialog of Installation expert in WPS 7.0)
a. Disable the User Account Control (UAC) prompting for standard user installations.
b. Set options for Restart Manager.
8. Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.
9. Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application’s primary functionality.
10. Remove all WRP components from the MSI package. If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:
a. Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.
b. Isolate the protected file so it is installed to a different location.
11. Fix installation-related errors that you find while performing installation and functionality tests.
12. Make other changes that are not related to Vista but are required as Customers standards.
13. Resolve CA’s which involved Nested Installation. This will throw an error while deployment.
14. Impersonation should not be used when running setups on Windows Vista. Edit the custom action and change its In-Script Options property to Deferred Execution – System Context. Test to verify that the custom action runs in this context.
15. Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions
16. Any property beginning with MSI cannot be used. Hence avoid using the same.
17. Components cannot have a dummy GUID; it’s a best practice to generate one.