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.

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.