So this is a little test to see just how much interest there is out there in pure Windows Installer training, I got virtually no feedback previous so either nobody read this or there is simply not an interest or requirement in the community. I have decided to run some FREE training courses. Yeah you heard me FREE introductory training. What’s the catch you ask ?

Initially these classes will be held in Brisbane, however I am willing to travel to different states in the future should this produce enough level of interest. If you want to travel you can do so at your cost for travel / accommodation.

I’m guessing your sitting here saying watch the catch ? Ok well here it is.

  1. Training will need to be arranged by management from your company, applications will not be accepted from engineers.
  2. Training will be free for only 1 person per company.
  3. Training will not be supplied for application packaging companies.
  4. Training will not be supplied to persons whom have already attended one of my courses.
  5. A minimum of 8 people will be required before a course will commence.
  6. Course will be 3 days from 9am till 4pm.
  7. Schedules will be dictated based on interest level, if not enough people see benefit no courses will run.

Course Syllabus (Time permitting dependant on class skill levels)

    • Resilience
      • Features
      • Components
      • Keypaths
      • Entry points
      • Feature Level Healing
      • Component Level Healing
      • Installer caching
    • User Profile Fix up
      • HKCU / Profile related repair scenario’s
      • Active Setup
      • Offline healing
    • Installation Methods / Processes
      • Admin Installs
      • Advertised Installs
      • Standard Installs
      • Installation Tables (InstallExecuteSequence, InstallUISequence etc)
        • UISequence
        • Acquisition Phase
        • Immediate
        • Execution Phase
        • Deferred
        • Commit / Rollback
      • Client / Server Processes
      • User Impersonation
      • System Process
      • Session Object
    • Custom Actions
      • When to use specific custom actions
      • Custom action rules
      • Using the session object
      • Using the session during deferred
      • CustomActionData during deferred
    • Validation ICE errors
      • Common validation errors
      • How to interpret validation errors
      • How to fix validation errors
    • Installer Logging
      • How to enable windows installer logging
      • How to interpret Windows Installer logging
    • Component Rules / Reference Counting Scenarios
      • Understanding component rules
      • Conflict management principals
      • Transitive components
      • Companion files
      • Shared dll reference count
      • Component reference count

This is intended for advanced users and it won’t be light on technical information, it is intended to supply information on using Windows Installer and not targeted at selling a packaging product or even using a specific tool.

To register your interest drop me an email at john.mcfadyen@gmail.com use a subject of "FREE training". Hope to hear from you soon.


So I finally got Internet connected at a record speed of 8 weeks (go iiNet, nothing like a bit of free publicity from another happy customer). Now I’m doing this one due to the massive number of requests we get on this through the multiple forums I frequent.

Windows Installer supports application upgrades. An upgrade is essentially the removal of an older product which is replaced by a newer product. The upgrade solution has two different upgrade methods.

Method 1:

  • Initiate installation of new product
  • Detect and Complete removal of an older product
  • Completion of installation for new product

This method is considerably easier and requires less knowledge of Windows Installer to achieve a successful result. Most application repackager’s tend to use this method.

Method 2:

  • Initiate installation of new product
  • Check matching component codes, installation of new non matching component from new product.
  • Uninstallation of non matching components leaving matched components on the machine.

Method 2 is considered to be the better process as it improves installation speeds due as only small portions of an application need to be installed and uninstalled. This process is however considerably more complex to build into a package and requires in depth knowledge of Windows Installer to complete successfully. Its pretty common place for people to attempt method 2 first as this is generally how the default schemas for most packaging tools are setup.

This can easily be summarised in a quick table.

Description Pros Cons
Method 1
  • Simple to implement
  • Increased disk / network throughput required.
Method 2
  • Speed
  • Less intrusive to target platform as less is removed.
  • Potential to remove newly installed application during Uninstallation of older application.
  • Difficult to implement
  • Required conflict management / upgrade sync processes to be performed.

The different process types are controlled by two Windows Installer Standard actions. These are:

FindRelatedProducts

RemoveExistingProducts

The FindRelatedProducts uses upgrade codes and application versions to identify windows installer applications and then determines what should be done with the applications it finds. The action to be performed when a product is detected is determined by the value of the attribute column of the respective upgrade table row. In addition to this the FindRelatedProducts action adds the ProductCode of found application to the Property specified in the ActionProperty column of the upgrade table.

The RemoveExistingProducts action does the actual removal of products found by the FindRelatedProducts action. The list of features to be removed is determined from the Remove column of the upgrade table. An blank entry or a value of "ALL" deems the entire application feature set should be removed. The location of the FindRelatedProducts and RemoveExistingProducts actions in relation to each other viewed from the Installation sequences determines which of the above methods of upgrade are performed.

Method 1 action locations:

FindRelatedProducts

RemoveExistingProducts

All actions making up installation of new product

Method 2 action locations:

FindRelatedProducts

All actions making up installation of new product

RemoveExistingProducts

Note: Method 2 is considerably more complex and it is not recommended for inexperienced packagers. It requires an in depth knowledge of application sociability, conflict management, component rules, installation sequencing.

I will cover component rules in another post, for now to cut a rather long story short you need to match component GUID’s on application which are intended to be upgraded with method 2 (that is if you want it to work properly). For those of you using Wise Package Studio there is a tool named UpgradeSync which is designed to aid with configuration of this type of upgrade method. To throw a little more complexity in the mix (such an unusual thing for Windows Installer) the MigrateFeatureStates action can be used to determine whether features should or shouldn’t be removed, but wait there is more you didn’t seriously think it was over there did you. There is another property called PreSelected which toggles whether the MigrateFeatureStates action runs.

There are 3 types of upgrade which are Small, Minor and Major updates. All updates require changing of the Package Code.

A small update is typically a small number of files, a small update cannot rearrange the feature component structure.

A minor update can add files and features however cannot manipulate the current feature/component structure. A minor update also requires the ProductVersion property to be changed. Minor updates can be shipped as full product installers or MSP patch files.

A major update can add files / features and also manipulate the feature component tree. The major upgrade requires that new ProductCode, PackageCode, and ProductVersion’s are set.

The following table summarises the changes required for each update type.

Update Type Package Code ProductVersion ProductCode
Small x    
Minor x x  
Major x x x
       


 

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 !
 
 

fyi WI 4.5 is release.

 

 

I am pleased to announce that the final release of the Windows Installer 4.5 Redistributable and SDK are now available. There is also a KB Article published about the release.

 

New and improved features in Windows Installer 4.5

The following new and improved features have been implemented in Windows Installer 4.5.

 

Multiple package transaction

In a multiple package transaction, you can create a single transaction from multiple packages. In a multiple package transaction, a chainer is used to dynamically include packages in the transaction. If one or more of the packages do not install as expected, you can roll back the installation.

 

Embedded UI handler

You can embed a custom user interface (UI) handler in the Windows Installer package. This makes a custom UI easier to integrate. You can also invoke an embedded UI handler from the Add or Remove Programs item in Control Panel. Or, you can invoke an embedded UI handler during a Windows Installer repair process.

 

Embedded chainer

You can use the embedded chainer to add packages to a multiple package transaction. You can use an embedded chainer to enable installation events across multiple packages. For example, you can enable install-on-demand events, repair events, and uninstall events across multiple packages.

 

Update supersedence resiliency

This feature lets you correct for changes in the FeatureComponent table during supersedence.

 

Shared component patching resiliency during uninstall

This feature makes sure that the most recent version of a component is available to all products.

 

Custom action execution on update uninstall

This feature lets an update add or change a custom action so that the custom action is called when an update is uninstalled.

 

If you have any questions about the 4.5 release, please see our MSDN Documentation or other topics posted on this blog about 4.5. Additionally, we will be monitoring and responding to the comments on this post.

 

Thanks to everyone who helped us throughout the beta program of this release!

 

[Author: Tyler Robinson]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.


View article…

Introduction to WiX

June 5, 2008


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’&gt;
   . .
</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:

MSI Attribute (Property) Wix Attribute Description
ProductCode Id 32 bit hex GUID (or serial number for the product)
ProductName Name A descriptive name for the application
ProductVersion Version A version number
ProductLanguage Language A numeric language code i.e. 1033
Manufacturer Manufacturer A descriptive manufacturer name
UpgradeCode UpgradeCode 32 bit hex GUID for the family of related applications
  CodePage A 4 digit code page reference

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.

General update

June 2, 2008


hi all just a quick note to let you know about the silence.
 
I have written a bunch of new content, but currently in the middle of moving house so im stuck without internet (which is very painful)
 
I don’t feel right doing this at work so your going to have to bare with me for a bit. Should be online in a week or so. At which time I will be flooding the site with more info.
 
 

When people are beginning to use Windows Installer the first look at the logs is often so daunting they tend to never look at them again. I find that the most common reason people avoid the logs is they don’t understand the sequencing. Funnily enough the sequences and the logs tend to correspond with each other (I’m not sure why that is)

Anyway if you take Windows Installer and break it down you would know that the Installer basically consists of a service and a database that processes table’s then sequences and actions. The installer service records everything that happens in sequential logic. The end result is a transactional record of the actions that are run during the installation. The beauty of this is as its transactional its quite simple to apply the reverse logic to handle the uninstall.

Now the trusty old log files record this process in its entirety, basically what I am getting at here is if you take the time to actually read the logs you would also understand the sequencing logic as well because they are one in the same. Alternatively if you work out the sequences you also workout the logs.

So first things first with the logs. How do we enable Windows Installer logging ?

Before we enable logging there is a number of available logging options which you need to know, there are:

Logging Option Option Description
v Verbose output
o Out of disk space messages
i status messages
c Initial UI Parameters
e All error messages
w Non fatal warnings
a start up of actions
r action specific records
m Out of memory or fatal exit information
u user requests
p terminal properties
+ Append to existing file
! Flush each line to the log
x Extra logging (Version 3.0 up, Windows 2003 + OS’s)

Note: Each letter corresponds to a different setting. Adding a collection of all letters increases logging capabilities.

Logging via Registry

System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
Value Name: Logging
Data Type: REG_SZ (String Value)

Note: A common acronym of VOICEWARMUP is used as its a word that contains all available settings (prior to V3.0)

Debugging via Registry

System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
Value Name: Debug
Data Type: REG_DWORD

By enabling the debug key you can monitor the installation using debugview

Install script logging

System Key: [HKEY_CURRENT_USER\Software\InstallShield\ISWI\3.0\SetupExeLog]
Value Name: VerboseLogFileName
Data Type: REG_SZ

Group Policy Logging

To enable logging from active directory or GPO you can find the settings here.

Windows Installer 4.0 +

So then we got Windows Installer 4.0 from which came two new Windows Installer properties.

MSILogging property hosts the same values listed in the above table.

MSILogFileLocation property has the path to where the logs should be created.

Command Line Logging

So last but not least command line logging, probably the one you will most often use.

msiexec.exe /i <path to msi> /l*v <path to logfile>

msiexec.exe /i <path to msi> /l*vx <path to logfile> (version 3.0 on Windows 2003 + OS’s)

Reading the logs

Ok so now you have the logs how do we interpret the garbage that it generates. Well for those of you who always like to take the easy road. Get your hands on this little utility WILOGUTL.EXE it makes pretty it all a little more legible and takes the guess work out of things.

However for all of you hard core propeller heads here’s how to really understand the seemingly difficult mess that arrive after setting some of the above options to log.

As you are aware the Installer Service on WindowsNT based platforms offers a client and server based process. The first section depicted in the following log excerpt in blue identifies the process is running client or server side.

MSI (s) (DC:D8) [22:18:04:544]: MainEngineThread is returning 1603
MSI (c) (34:30) [22:18:05:544]: Back from server. Return value: 1603

MSI (S) is server side

MSI (C) is client side

MSI (N) is a nested action

The next items depicted above in the red text is the ProcessID:ThreadID that generated the entry. Only the last 2 (hexadecimal) digits of the process and thread IDs are given. If the process ID was 2DC and thread ID 2D8 the Hex item show in the log would be (DC:D8).

The green section following is the date time stamp the action occurred.

Product State

The ProductState property can be any one of these values

Value Description
-1 The product is neither advertised nor installed.
1 The product is advertised but not installed
2 The product is installed for a different user
5 The product is installed for the current user

Feature Component State

So every feature and component is checked for state prior to it being marked as something that needs to be installed. So selecting different features "usually" changes the feature state and subsequently all the components within that feature (of course there are exceptions to every rule, the condition table and feature / component conditions all have effect here also.).

The first item here, show the feature name as Complete and it is currently Absent. So the requested action is to install it Local. So the components follow the same pattern. This one is a little tricky so more detail here

 

Value Value:        Description
Installed Local        
Source     
Advertise  
Absent      
already installed to run local
already installed to run from source
already installed as advertised
not installed
Request Local
Source     
Advertise  
Reinstall   
Absent     
requests to install the item to run local
requests to install the item to run from source
requests to advertise the item
requests to reinstall the item
should not be installed
Action Local        
Source     
Reinstall   
Absent     
Null         
actually performs install to run local
actually performs install to run from source
actually reinstalls the item
actually removes the item
do nothing

MSI (s) (94:28) [20:46:12:390]: Feature: Complete; Absent: Local;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: Registry; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: VersionRegistry; Installed: Local;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: slupExecutable; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: CoreLibrary; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: CtrlLibrary; Installed: Absent;   Request: Local;   Action: Local

Reading Actions and return codes

Action start 1:18:02: INSTALL.
MSI (c) (A1:6A): UI Sequence table 'InstallUISequence' is 
present and populated.
MSI (c) (A1:6A): Running UISequence
MSI (c) (A1:6A): Skipping action: ResumeInstall (condition is false)
MSI (c) (A1:6A): Doing action: CheckOSandSPAction
Action start 1:18:02: CheckOSandSPAction.
MSI (c) (A1:6A): Creating MSIHANDLE (1) of type 790542 for thread 110
Action ended 1:18:02: CheckOSandSPAction. Return value 1.
The valid return codes are: 
Value Description
0

Action not invoked; most likely does not exist.

1

Completed actions successfully.

2

User terminated prematurely.

3

Unrecoverable error occurred.

4

Sequence suspended, to be resumed later.

Shell32 API calls

Where you see one of these there is a good chance a directory is being resolved for the current target platform.

MSI (s) (94:28) [20:46:11:843]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Templates

Old hands tips for log reading

1) Start at the bottom and work up

2) If your install fails with dialogs open. Leave dialogs on screen and goto log whilst error message is still visible

3) Use WiLogUtl.exe

4) Don’t forget the newest extended logging options /l*vx (most of you are still using /l*v)

5) Keep the sequences in mind when reading a logfile (strangely enough they coincide nicely)

6) Enable GPO logging or policy registry option if you need to log repairs

7) Now you have this information take a 30 minutes out of your day and read an entire log you’ll be surprised what you learn.

Now all that being said, I’m not getting a lot of feedback about these blogs so its hard to gauge if anyone is really reading or even interested in this stuff or not.

Post some comments if you want more info otherwise I may just find other things to do with my spare time.