MSI Factory
This article addresses the Certified for Windows Vista Test Cases on a one-by-one basis and tells you how to make sure that the installer that you create with MSI Factory will pass all tests. We will address test cases 11-29 as they are the ones that pertain to "Install/Uninstall."
This document is based on version 1.3.001 (March 6, 2007) of the "Certified for Windows Vista Test Cases" document. You can obtain the document here:
MSI Factory generates pure .msi files which will pass this requirement. If using the bootstrapper feature to wrap your MSI file in an executable, it will also pass this test because it ultimately does call msiexec.exe (Windows Installer) to perform the installation.
The application's MSI package must not receive any errors in the Internal Consistency Evaluators (ICE) 1-2, 4-7, 9-15, 17-24, 27-31, 33-36, 38, 40-57, 59, 61-63, 65, 67-71, 74-78, 81-84, 86-87, 89-94, 96-99 when validated in order to pass this test case.
During the build process, ICE validation is performed on your installer database automatically. Any ICE errors that occur are displayed. Normally you should not encounter ICE errors in your installers created with MSI Factory. However, if you do they should be remedied before you submit your application for Vista certification testing.
This does not apply if you are distributing your installer as an MSI file. If you are using the bootstrapper feature, it will pass this test because it does contain an embedded Vista manifest.
This test only applies if you are running your application at the end of the install. Compliance is up to you and does not have anything directly to do with MSI Factory.
It is up to you as the setup author to ensure that you pass this test. By default, MSI Factory sets up new installer projects so that files are installed to a sub-directory of ProgramFilesFolder which will pass this test case.
Not applicable to installs created with MSI Factory.
Not applicable to installs created with MSI Factory.
This test case is really two-part when you get into it. As for the first part, MSI Factory installer packages do have all of the required properties defined.
The second part is somewhat debatable. It implies that the installer must contain an Upgrade table and then goes on to give specific instructions about the values in the Upgrade table. Installers created by MSI Factory normally do not have an Upgrade table defined unless you explicitly define Upgrade codes for your installer. Upgrade codes are defined by selecting Project > Settings from the menu and then selecting the Product tab. Normally upgrade codes are only defined when producing a major upgrade. However, the implication in this test case seems to relate to preemptively specifying an upgrade code/custom action pairs that will prevent the install from working on a system that has a newer, major upgrade installed. This process is described in this MSDN article:
Preventing an Old Package from Installing Over a Newer Version
One of the only discussions that we found on the Web pertaining to this issue is here:
Test Case 18, ProductVersion constraint
In light of the discussion above, you can create similar Upgrade table entries in MSI Factory by doing the following:
- Select Project > Settings, Product Tab.
- Click Add to open the Related Program dialog.
- Enter the Upgrade code from back on the Product tab of the Project Settings dialog into the "Upgrade code" field.
- Click Add to open the Upgrade Version dialog and set the following values:
- Property: NEWERVERSION
- Minimum version: Enter the "next" version of your product. So if the version you are making the installer for is "1.1.0", make it something like "1.1.1". Check the "Inclusive" checkbox beside the field.
- Maximum version: Leave empty. Leave "Inclusive" unchecked.
- Languages: Leave empty. Leave "Exclude these languages" unchecked.
- Features to remove: Leave empty.
- Ignore remove failure: Unchecked
- Migrate features from upgraded products: Unchecked
- Only detect: Checked
- Click OK to accept the Upgrade Version and then click Add again to open the Upgrade Version dialog and set the following values:
- Property: OLDERVERSION
- Minimum version: Leave empty. Check the "Inclusive" checkbox beside the field.
- Maximum version: Enter the current version of the software. It should match the "Product version" field on the Product tab of the Project Settings dialog. Leave "Inclusive" unchecked.
- Languages: Leave empty. Leave "Exclude these languages" unchecked.
- Features to remove: Leave empty.
- Ignore remove failure: Unchecked
- Migrate features from upgraded products: Unchecked
- Only detect: Unhecked
- Click OK to accept the Upgrade Version.
- Click OK to accept the Upgrade Code.
The above is unverified but our research indicates that this will ensure that your installed passes TEST CASE 18.
MSI Factory installer packages make all uninstall entries listed in step 5 except for 5.b "InstallLocation". The InstallLocation entry should contain the main installation folder of the application. It is set by assigning a value to the MSI ARPINSTALLLOCATION property using a custom action at runtime. To set this value in MSI Factory, do the following:
- Select Actions > Custom Actions from the menu.
- Click the Add button and choose "Set Property" from the context menu.
- On the Set Property dialog, enter the following values:
- Settings tab:
- Property: ARPINSTALLLOCATION
- Value: [INSTALLDIR]
- Attributes tab:
- ID: WRITEINSTALLDIRTOARP
- Scheduling: Immediate
- Return: Check
- Suppress modularization: Unchecked
- Timing: (click Add to open Custom Action Timing dialog)
- Sequence: InstallExecuteSequence
- Condition: Leave empty
- Execute: After
- Relative action: InstallFiles
The custom action above will cause the installer to correctly write out the InstallLocation value to the Registry.
It is up to you to ensure that you do not install files or Registry keys that are protected by Windows Resource Protection.
MSI Factory does not allow you to define or use the custom actions listed in this test case so it will not be an issue.
MSI Factory (and WiX) are compliant in this regard.
MSI Factory installation packages are compliant with this requirement by default. The only exception would be if you are using your own custom actions that affect the system. In that case you should make sure that you have the appropriate rollback custom actions in place to undo the changes during rollback.
MSI Factory installation packages do not schedule a forced reboot by default.
Projects created with MSI Factory has the MsiRMFilesInUse dialog in their user interfaces. If you created a project with a version of Setup Factory for Windows Installer before 1.1.1007, you can add this screen to your project using the following steps:
- Select Project > Dialogs from the menu.
- Select "Advanced" as the Edit mode.
- Select the "Support Dialogs" item in the tree control.
- Click the Add button below the tree control.
- Select the "MsiRMFilesInUse" dialog.
- Click OK to add the screen to your project.
The standard Windows Installer packages created by MSI Factory support those command line switches.
All components are given valid component IDs in MSI Factory. Your installer will pass this test.
MSI Factory is compliant with this case when you create shortcuts through the Shortcuts tab on the File Properties dialog. Shortcuts that are created through the Shortcuts dialog (Actions > Shortcuts) are also compliant with this test by default, although the rules can be broken if you explicitly change the component that the shortcut action belongs to.