Wix, Votive, and Semicolons...

If you are using the Wix in Visual Studio (known as 'Votive') and need to set one or more preprocessor variables, it is rather simple. If you right-click on the Wix project, select 'Properties', then the 'Build' tab, you simply populate the 'Define preprocessor variables:' text box like so:

Name1=Value1;Name2=Value2

If you are using MSBuild, or editing the .wixproj file itself, this translates to the contents of the 'DefineConstants' element, which is where Votive stores what you put in that text box.

Things, however, are not really clear (or documented) if you need to set Name1 in the example above equal to a semicolon delimited list - for example "one;two;three" - so lets try it this way:

Name1=one;two;three;Name2=Value2

Candle.exe is passed (which is obviously incorrect based on our intentions):

-dName1=one -dtwo -dthree -dName2=Value2

The solution is NOT to put quotes around the list (my first guess), but to replace the semicolons that break up the list (and only the ones in the list) with '%3b', like so:

Name1=one%3btwo%3bthree;Name2=Value2

Candle.exe is now correctly passed:

-dName1=one;two;three -dName2=Value2

I do not know if this is way you would handle this situation in anything newer than Wix 3.0 - I haven't updated to 3.5 yet.

Integrate the latest MSDN Library Help with VC++ 6

*See update at bottom of this entry*

There is an awesome article just published on Code Project that shows how to Integrate the latest MSDN Library Help with VC++ 6. Although you can simply download the demo project and follow the instructions after "How to set the default help collection?" at the end of the article, the article itself is a great primer on reverse engineering.

Of course, the newer-than-October-2001 MSDN libraries do not have the help files for the actual Visual C++ 6 development environment and/or compiler, if you are still using VC6, I would hope you don't need this documentation anymore.

I am curious why Microsoft did not include this integration ability (with the normal caveats) with the newer MSDN libraries, but I guess they sold a couple of extra copies of Studio .NET this way...

UPDATE: With this plugin enabled, I get a sharing violation on the .opt file if opening the project from explorer - a double-click or "Open With". Opening Visual Studio, then opening the workspace seems to not have this problem. Please let me know if you have similar problems.

Wrestling with the MSI setup editor in Visual Studio

Tim Anderson blogs about editing an MSI after it is built by Visual Studio .NET. There are various tips hidden in here about how to cope with duplicate assemblies being added to the MSI, marking a file so upgrades don't overwrite it, invoking the Custom Action editor, and MSI SQL.

For more detailed information related to editing an MSI after it is built, check my previous blog entry "MSI - Modifying the Installer Database at Runtime" and scroll down to Solution 1.

For more information as to how to launch a program after installation, see How do I use a custom action to launch an installed file at the end of the installation? from MSDN.

Tim also mentions as to why he stuck with using the Visual Studio MSI packager instead of a commercial editor. He gives 4 reasons, and I would add purity as a fifth. Regardless of the authoring tool he uses, his code will always work. Granted, pretty much any tool he uses will eliminate the need for his particular edits to the MSI, but the concept is still valid.