Quote

Windows Installer Training

So at the moment I am trying to convince some of the big vendors that their is a market for Windows Installer training as opposed to just tool based training.

 

So I have had a look at training offered by the two main players and I have to say I think its a little inadequate personally. What i see is a recurring theme of use our product. Here is how you use our product.

 

I use this analogy to compare it.

 

If you had a race car and wanted to get it tuned would you take it to a race engineer or a backyard mechanic that has proven his worth with a spanner.

My bet is the person who is trained to understand race engines and knows how to use the tools is better than a person whom is only familiar with using a set of tools.

 

Windows Installer is much the same, you have an engine and a bunch of tools that can manipulate that engine.

 

So where I am heading with this is should we push the vendors to create some more training ? Failing that perhaps I will do it myself. I see a market for this opportunity the only person I am aware of doing this is Darwin Sanoy no offence intended to Darwin but he cant be all over the world at once.

 

So if you agree there is room for better training, actually understanding the engine as opposed to the tools drop me some comments so I can take it to the big players ! I don't care if they are good or bad will open my eyes if no one elses.

 

The more ammunition I get the better chance we have of making this happen !

 

 

Hi all,

I know a bunch of people are waiting to get into this topic, so lets see how I go with the explanations. I haven't previously trained anyone with this at all so putting it into blog form could be somewhat interesting or confusing. There is a bunch of pre-requisite windows installer knowledge I will assume as well, so if I start to fast or too slow let me know. (I will try to cover this along the way if your new to Windows Installer some of my earlier blogs have covered that already)

So as you are all likely aware the WiX toolset is basically an MSI to XML and XML to MSI compiler / decompiler for want of better words. For those of you who can string more code together than I can its probably a very very useful tool to get your head around. The WiX toolset is more suited to people in development roles or closely associated to software development in some way or another.

One of the main benefits is it allows a great repeatable way to generate MSI's. If your in a development cycle that needs quick releases of new product source code this is an excellent way to achieve that as a result. My current role is doing just that compiling source code which is written all over the country into an MSI quickly and automated. Everyday I pull around a 1,000,000 lines of code together and compile it into assemblies then MSI's and have it deployed to large distributed server clusters inclusive of application configuration for multiple environments in a little over an hour.

There is a number of different technologies at work to make all this happen and WiX is a fairly substantial part of that process. So I will attempt to explain how you can utilise WiX to do similar compilation of large projects in a series of articles.

So enough of the pre amble lets get into WiX.

To start of there is a number of tools included in the WiX toolset. In order to start off with basic WiX we are only going to need to of them. These are:

Candle.exe and Light.exe (for some reason Rob Mensching had a fascination with lights of some sort when designing WiX most of the tools are names resembling light related names or objects)

Anyway the candle tool allows a pre compilation step which converts a WiX based file into a formatted wixobj file.

Light is then used to compiled the pre compiled file into an MSI file combining it with the source code to create your completed MSI.

In order for the two compilers to run you need to compile a WiX source file. WiX files come in a number of different file types, however for the most part I will be discussing wxs files.

So the wxs file format is simply and XML representation of your MSI database structure.

So before I dig too much into the internal formatting of the file I will outline the rough concept of the process.

1. Create Source code
2. Store source code in source repository
3. Extract latest source code from repository to known area
4. Generate a template wxs file referencing source code from 1 & 2 now located at 3
5. Compile the wxs file using Candle.exe into a wixobj file
6. Compile the wixobj file into an msi using Light.exe
7. Collate compiled MSI and distribute to test servers

WXS File structure

All WiX files must start with this header as a bare minimum.

<?xml version='1.0' encoding='windows-1252'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi'>
   . .
</Wix>

Before we move onto the next step you need to be aware of the following Windows Installer terms.

• 32 bit hex GUID {00000000-0000-0000-0000-000000000000} or Globally Unique Identifier
• ProductCode a product code acts like a serial number for an MSI. The product code is written as a 32 bit hex GUID
• PackageCode is also a 32 bit hex GUID however its purposes is to identify Unique iterations of a specific product. Each new iteration should have a new package code.
• UpgradeCode is also a 32 big hex GUID however its purpose is to identify a family of common applications. For example multiple versions of Adobe Acrobat Reader should all have the same upgrade code for family identification purposes

Each Windows Installer application must have some specific Product based meta data stored within the <Product> Node, as such the corresponding WiX scripts should also have those same attributes. The minimum attribute set and their respective WiX attributes are:

Note: Specifying {????????-????-????-????-???????????} forces WiX to generate a new GUID each compilation, ALL GUID's should be in upper case.

Putting this all together you should have something like this.

<?xml version="1.0" encoding="UTF-8" ?>

- <Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">

<Product Id="{1BF1ACD8-7C1B-39BF-21E6-BB1C95FD2138}"

  Name="Minimal Windows Installer Sample"

  Version="1.0.0"

  Language="1033"

  Manufacturer="Installpac Pty Ltd"

  UpgradeCode="{B2F9543C-3C4D-12B3-A857-62E64F6FDEB0}"

  Codepage="1252">

</Product>

</Wix>

As with all Windows Installer packages you also need a package code. This is represented by the <Package> element. The package element also has a number of attributes which are required which are shown below.

         <Package

            Id="????????-????-????-????-????????????"

            InstallerVersion="200"

            Platforms="Intel"

            Languages="1033"

            Compressed="yes"

            SummaryCodepage="1252"

            Description="My Application"

            Comments="Hi there"

            Manufacturer="Installac Pty Ltd"

          />

Note: Using "????????-????-????-????-????????????" as the package code creates a new generated GUID each time the compiler runs. This ensures you are running with the rule of creating a new package code for each iteration of your package.

You need to insert the package element into the product element and then you are ready for your first compilation. Save the file as something like testproduct.wxs.

To test your compilation now you to run the first of the two compilers.

candle.exe <folder path to>testproduct.wxs

This will create a wixobj file which can then be used by the wix linker (light.exe)

light.exe <folder path to>testproduct.wxs

The result of this should be your first WiX msi.