Tone's Notes

Adding additional dialog boxes to installer interface:

-         Give the properties uppercase names.

Adding custom actions:

-          Define a class that derives from System.Configuration.Install.Installer. Easiest way to do this is to use the “Installer Class” template when adding an new item.

-         Add the [RunInstaller(true)] attribute to the class.

-         Override Install():

            public override void Install(System.Collections.IDictionary stateSaver) {

                  base.Install(stateSaver);

                  string nonsense = Context.Parameters["nonsense"];

                  // File appears in c:\Windows\System32

                  StreamWriter sw = File.CreateText("myinstalltest.txt");

                  sw.WriteLine(nonsense);

                  sw.Close();

            }

-         Add a custom action to the installer:

o       Add the action to the root for all four phases, or just to the phase of interest (typically install).

o       Add CustomActionData entries for parameters to be passed to the Installer override:

/nonsense="[NONSENSETEXT]"

To run another msi as a custom action from within an msi look here. It isn’t directly supported by a .NET setup project.

The default Context.Parameters collection contains information like the following:

Parameters["nonsense"]="Default Nons4ense"

Parameters["logfile"]=""

Parameters["installtype"]="notransaction"

Parameters["action"]="install"

Parameters["assemblypath"]="c:\program files\jobquake\jobquake.exe"

The AfterInstall event doesn’t fire as part running “Install” from the IDE, and

the Commit override doesn’t get called.

Windows Installer Documentation

dotnetfx documentation Can download self extracting dotnetfxredist.exe from here.

InstMsiA.Exe – Windows Installer Installer

InstMsiW.Exe – Windows Installer Installer

Setup.exe – Bootstrap, verifies Windows Installer, then installs .msi.

Setup.msi – The actual application.

Msiexec.exe Installs .msi files. Takes command line options to modify installer’s behavior.

Public installer properties can be changed at the command line or “transformed” within the .msi file(?)

Required Public Properties:

The ProductCode property is a unique identifier for the particular product release, represented as a string GUID, for example "{12345678-1234-1234-1234-123456789012}". Letters used in this GUID must be uppercase. This ID must vary for different versions and languages.

A product upgrade that updates a product into an entirely new product must also change the product code. The 32-bit and 64-bit versions of an application's package must be assigned different product codes.

The ProductCode is advertised as a product property, and is the primary method of specifying the product. This property is REQUIRED.

The value of the ProductVersion property is the version of the product in string format. This property is REQUIRED.

The format of the string is as follows: major.minor.build

The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.

At least one of the three fields of ProductVersion must change for an upgrade using the Upgrade table. Any update that changes only the package code, but leaves ProductVersion and ProductCode unchanged is called a small update. The three versions fields are provided primarily for convenience. For example, if you want to change ProductVersion, but don't want to change either the major or minor versions, you can change the build version.

Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.