Friday, May 26, 2006

WiX: Changing entry name in ProgramMenuFolder in the runtime

Recently I was developing installation package using WiX toolset. And encountered interesting problem.


Installation package after installing application, also installs shortcuts into “Start” program menu, ( in WiX constant for it is “ProgramMenuFolder“ ).

The task was to set the name of Programs sub-entry with specific ( dynamic name ). This name is generated during installation time.

So, how to resolve?

It appears that if you write

<Directory Id="ProgramMenuFolder" Name="PMenu" LongName="Programs">
<Directory Id="ProgramMenuDir" Name='Comp' LongName="Full Company Name">
</Directory>
</Directory>

you expose “ProgramMenuDir” as public property, which you can change.

Okay, the question arises how and when this property should be changed, so that installer used new value for creating the Programs menu sub-entry?

To set property value we can use custom action

<CustomAction Id="DIRCA_SETPROGRAMFOLDER" Return="check" Property="ProgramMenuDir"

Value="[ProgramMenuFolder]Company Title - [PUBLIC_PROPERTY]"></CustomAction>

Values in square brackets correspond to names of properties defined during installation. Square bracket notation means

[PROPERTY1] – take value of property with name “PROPERTY1”.

Good, we have custom action, that changes the property. When should it execute is another question?

Properties that are used as directory names are finally set during CostFinalize process, so to change the values of these properties we have

to launch our custom action before CostFinalize. Piece of cake!

<InstallUISequence>

<Custom Action="DIRCA_SETPROGRAMFOLDER" Before="CostFinalize"></Custom>

</InstallUISequence>

<InstallExecuteSequence>

<Custom Action="DIRCA_SETPROGRAMFOLDER" Before="CostFinalize"></Custom>

</InstallExecuteSequence>

Now, after installer successfully finished we have nice and custom entry in ProgramMenuFolder.

Saturday, May 13, 2006

Blog template changes

I've made some changes to the template of this blog. On the right side there is RSS link with standard image, like this

Friday, May 05, 2006

public vs private properties in MSI

Intro

Sooner or later every developer after development stage faces deployment stage. This stage turns out in developing another application, namely installer.

There are a lot of installers out there. Here I will enumerate some NSIS - Nullsoft scriptable install system, InstallShield, WISE, WiX and a lot of others. The latter use Microsoft Installer technology. All of them, except Nullsoft installer, produce .msi and other MS Installer files.

Properties in MSI

Since MSI file is a collection of tables, properties are placed in special table called, I think you will guess - "Property" :8-).So, what’s so special about these properties?

Custom Actions and Properties

Every installer developer should be aware that there are 2 types of properties in MSI. Values from Properties table are used by an installer as global variable during install process.

Information about types of properties is of special value for "custom actions" (CA) developers. CAs are special programs (.exe) or modules (.dll) that are called during installation process to perform special actions.

Now, let’s get back to properties...

Docs say:
- Private properties: The installer uses private properties internally and
their values must be authored into the installation database or set to values determined by the operating environment.
- Public properties: Public properties can be authored into the database and changed by a user or system administrator on the command line, by applying a transform, or by interacting with an authored user interface.

You will ask, how Installer determines which are private and which are public?
It is very simple public properties must be uppercase, and that’s it.

So, if your custom action stopped working and the problem is that it cannot read property from msi, then the first thing you should check is if this property is public.