Setup Is Not a Testing Tool

Your setup program is not a test. Don't rely on it to determine if the files you build were built without any errors. You should have a specific build verification test (explained in detail in Chapter 12, "Build Verification Tests and Smoke Tests" ) that verifies that the files were built properly. Too many times, at Microsoft and at other companies, I see groups that use a setup tool as a test. For example, if the setup tool fails with an error, the build teams backtrack to see what failed in the build or what was added or removed. This is the wrong approach.

You should do the opposite. Each product team needs to come up with a list of files that are contained in each release. In the simplest example, you can use a spreadsheet application like Microsoft Excel to track this, but it would be better to use a database tool that allows richer queries and entries. Track the following information for each file:

• The name of the file

• The location of the sources for the file and a list of the source files

• The owners (development/test/program management) of the file

• The SKUs that the file ships with

After you create this master list, you can create the appropriate SKU. XML files for your product.

Here is an example of how the Windows group uses WiX to build some of their components, such as IIS or the DDK team, setup program. Figure 13.1 shows an overview of how the post-build process works. Starting from the top, the SKU.XML files or Setup Build XML files are checked into the source tree along with the WXS files that developers own and generate. In this example, we then binplace (copy) the files into a COMMONTEST/ Setup directory. After we copy the files, we use a script called SetupBuild. cmd to produce the MSI and CAB files. In most other build processes that use WiX, the .wxs files are compiled along with all of the source code in the project. This is one of the big gains of the WiX toolset and what makes it so useful. It is easier to push back the setup process to development if the files get compiled at the same time.

Figure 13.1. Setup structure.

In most build processes, the .wxs files are compiled along with all of the other source code. Again, this is one of the major benefits of WiX. It fits right in with all of the other tools in your build system.

Warning

Don't use SKU.XML for the filename. Name it something unique to the SKU or SKUs that it represents.

Figure 13.1 shows only two SKUs being created, but this architecture allows for more than two SKUs. The following configuration settings are definable in the SKU.XML file:

• Environment variables

• Candle.exe command line

• Light.exe command line

• Source directory that contains all .wxs files

• Destination directory where the resultant MSI and CABs will be placed

The following is a sample SKU.XML file that shows the previously mentioned settings that are passed to SetupBuild.cmd:

<?xml version="1.0" encoding="utf-8" ?><xs:schematargetNamespace="http://schemas.microsoft .com/ SetupBuild/2004/01/sb"             elementFormDefault="qualified"             xmlns="http://schemas.microsoft.com/SetupBuild/2004/01/sb"             xmlns:mstns="http://schemas.microsoft.com/SetupBuild/2004/01/sb"             xmlns:xs="http://www.w3.org/2001/XMLSchema">     <xs:element name="SetupBuild">            <xs:annotation><xs:documentation>This is thetop-level container element for  every SKU XML doc</xs:documentation></xs:annotation>         <xs:complexType>             <xs:sequence>                  <xs:element name="SKU"minOccurs="1" maxOccurs="unbounded">                      <xs:complexType>                          <xs:sequence>                              <xs:element ref="EnvironmentVar" minOccurs="0" maxOccurs="unbounded"/>                              <xs:element ref="Candle"maxOccurs="1"/>                              <xs:element ref="Light"maxOccurs="1"/>                           </xs:sequence>                           <xs:attribute name="SourceDir"type=" xs:string" />                           <xs:attribute name="DestinationDir"type=" xs:string" />                       </xs:complexType>                   </xs:element>               </xs:sequence>           </xs:complexType>       </xs:element>       <xs:element name="EnvironmentVar" >              <xs:annotation><xs:documentation>This will beused to set environment vars on  a per-SKU build basis</xs:documentation></xs:annotation>           <xs:complexType>               <xs:sequence />               <xs:attribute name="Name" type="xs:string" />               <xs:attribute name="Value" type="xs:string" />           </xs:complexType>       </xs:element>           <xs:element name="Candle" >                  <xs:annotation><xs:documentation>This is used tospecify the command line  for Candle.exe</xs:documentation></xs:annotation>               <xs:complexType>                   <xs:sequence />                   <xs:attribute name="CommandLine" type="xs:string"/>               </xs:complexType>           </xs:element>           <xs:element name="Light" >                  <xs:annotation><xs:documentation>This is used tospecify the command line  for Light.exe</xs:documentation></xs:annotation>               <xs:complexType>               <xs:sequence />               <xs:attribute name="CommandLine" type="xs:string"/>          </xs:complexType>      </xs:element> </xs:schema> 

Setupbuild.cmd is a script placed into the test post-build process that uses WiX V2 to create Windows Installer MSI packages and CAB files that go along with the MSI packages. It scans a given directory for SKU.XML files and builds these packages based on the information in them. Rather than have a master SKU.XML, it makes more sense to have a common directory that multiple uniquely named files can be binplaced to.

The following is a basic algorithm for the SetupBuild.cmd file:

• Process command-line arguments.

• (In our example) Check COMMONTEST\Setup directory for SKU. XML files.

• Validate XML doc.

• Set environment variables.

• Run Candle.exe command line on all files in the source directory.

• Run Light.exe command line on all resultant files from candle.exe.

• Check to see whether another SKU element exists. If it does, repeat the preceding steps.

The post-build process should meet the following requirements to make the process robust and scalable:

• A setup component owner should be able to add his component to an existing setup SKU by ensuring that his WXS file is binplaced to the proper directory during the build process.

• The process should allow you to add a new SKU without rewriting a post-build script. Use a settings file to instruct the post-build script which products to build.

• The post-build script should have parseable output that an automation scheme can interpret to determine if it is a success or failure.

One suggestion that you might want to consider is to augment or double-check this process by implementing a build verification test (BVT) that at the very least checks installation and uninstallation of the product when a build is done so that it can catch unforeseen errors before you release a build.