Setup (WiX, MSI)

Changing an install directory dynamically in WiX 2.0

John Watson — Fri, 03 Nov 2006 17:13:00 GMT

Somehow this topic seems so common place and yet no where have I been able to find it spelled out clearly and simply. This reminds me of the joke about a helicopter pilot who's lost in the fog near Seattle, asks where he is and then is able to quickly navigate from there. When asked how he did that, he replied that the person in the window held up a sign saying "You're in a helicopter" which is such a typical engineer's response (accurate and truthful but not helpful or useful) so the pilot knew he was at the Microsoft campus and was able to navigate from there back to the airport.

If you need to set a directory "on the fly" either based upon a value from a dialog or some other means there are two things you need to do and one caveat:

Create a custom action that sets the directory value:
<CustomAction Id="AssignWebDir" Directory="WEBSITEDIR" Value="[WEBROOTDIR][SITE.NAME]"/>
Schedule the action during the InstallExecution phase (must be after the CostFinalize step):
<Custom Action="AssignWebDir" After="CostFinalize"><![CDATA[NOT Installed AND (&WebServer = 3) AND NOT (!WebServer = 3)]]></Custom>

The caveat is that at the time you've scheduled the custom action the directory name, which is also a property, has been resolved. In the above example, assume that the parent directory, named WEBROOTDIR, is the default "C:\Inetpub\wwwroot\". Under the parent directory is where you've specified WEBSITEDIR to be. Even though you may specify an initial directory name (e.g. "mysite") on the <Directory> tag in the .wxs file you must use the full path when changing the name - thus the new value in #1 above contains the parent directory name and the site name (which I prompt the user for).

To round out the notes for the above example - the <![CDATA[...]]> syntax around the conditions "preserves" the xml integrity because of the ampersand (&) character in front of the Feature name. The full condition is if the product is not installed (i.e. it's being installed) and if the Feature (in this case the "WebServer" feature) is being installed locally and it's not already installed locally. Finally the Directory= attribute causes WiX to create a Type 35 Custom Action whereas using Property= causes WiX to create a Type 51 Custom Action. I mention that because they're briefly mentioned buried in the .chm help although not the online docs and not in the tutorial (more on that in a moment). When you're searching and trying things it's easy to miss that bit of info.

My "beef" and the reason for the reminder of the joke is that you can find lots of bits and pieces of WiX and MSI info such as "You can use a Custom Action to set a directory location" but the person giving the answer stops short of mentioning the rest or giving an example. I'm not picking on that one person - this seems to be the style and culture of the mailing lists on SourceForge. That is, I can find dozens of responses on directories and properties with Nabble (which does a much better job of indexing, searching and providing results of the SourceForge mailing lists) but nobody bothered to offer a concise and complete answer.

Even the WiX Tutorial which I'm sure took a lot of effort and a long time to compile and update mentions the "facts" in bits and pieces: 3.2 shows both examples of dynamically setting a directory using either a Directory= or a Property= attribute but fails to mention the difference (Type 35 or 51) or impact. I say both because you'll find both suggestions mentioned repeatedly on the mailing list without a complete example or a clear indication of which to use and why. The same 3.2 section shows how to schedule the actions up above the examples but doesn't mention that directories have to be scheduled after CostFinalize and require a fully-replaced path be specified because it's been resolved. It's only through more searching elsewhere on the mailing list that you can dig up the fact about cost finalize and scheduling directory/file name changes afterwards. Although nobody spelled out the little tidbit about paths already being resolved at that point. Also, 5.6 mentions creating directories (this is where you'd expect to find the information for changing them) but neglects to mention they can be changed and that to do so, you use a custom action with links back to the relevant 3.2 section showing that. Going beyond this, if you want to put together a dialog to prompt and pass values, you'll have to spend a lot of time in Lessons 2 and 8 as well as the mailing lists. ;)

Finally, Rob teased us with his last entry on the directory table and Type 51 actions here but at the rate he's been able to post it'll be around the holidays before we get the answer. ;)

I'll end my rant with one more Microsoft observation - I searched Rob's blog for "msi directory". What's the very first thing displayed at the top of the list? Why the number of results AND THE NUMBER OF FREAKIN' MILLISECONDS IT TOOK TO FIND THEM! Yeah, that's what I'm most interested in - NOT! Then there's the random order to the results list - not by date or title or even number of comments - who knows!

This is the tired helicopter pilot signing off from the fog around Seattle :)

Generate WiX 2.0 Web Folder Fragment

John Watson — Fri, 27 Oct 2006 16:48:00 GMT

This little utility grew out of need. I'm offering it up for free because it's so rough around the edges - no documentation, brute force approach, hardcoding, assumptions, etc. - you get what you paid for! It consists of a command script, a VBScript and an Xsl file - you can download it here. To use it, you also need another little utility I built which will generate a nested Xml directory listing that you can find here.

It will take an Xml directory file (from this previous utility) and generate a WiX 2.0 compatible fragment with the following features:

DirectoryRef element so it can easily be referenced back to a Directory in a "controlling" WiX file.
Component element for the web virtual directory with WebVirtualDir and WebApplication child elements.
Component element representing the root of the web folder with a child elements for all Files found there, including both long and short names as needed.
Nested Directory elements representing each of the sub folders under the root web folder (recursive) with all files.
Ignores Visual SourceSafe (*.scc) files. ;)
ComponentGroup element to pull together all the pieces of the web site so it can be easily referenced from a Feature (via ComponentGroupRef) in a "controlling" WiX file.

Of course, there's been limited testing (very limited, ok...I've only tested it on one project) so you may find some bugs. There's also some hardcoding and assumptions. Pay special attention near the top of the Xsl file where it's building the web virtual stuff (e.g. AllowSessions, DefaultWebSite, etc.). I didn't bother to get fancy and code for parameters.

Because of lack of time it carries a big assumption about the various artifact names - it uses the root folder name that you're building from. For example, if your web folder source is located at [C:\Inetpub\wwwroot\mywebsite] then it'll pick up "mywebsite" as the internal WiX name for the vdir, webapp, alias, etc. Finally, it picks up the auto generated GUIDs from the directory Xml ("ah, that's why he stuck them in there" ;) ) to use for component IDs and GUIDs. Therefore, this probably only has limited use as a first time tool since changing the GUIDs on each release of an MSI is generally frowned upon.

To use it simply drop the three files into your WiX build directory and invoke it from a command line: bldWebWxs "path_to_root_of_webFolder_source" wxsFilename

Hopefully, this will save you some time and get you most of the way there.

Enjoy!

WiX3 doesn't yet support COM+ installations - Oct 17, 2006

John Watson — Wed, 18 Oct 2006 13:57:00 GMT

I found out while trying to make a COM+ installation that WiX3 doesn't yet support this. I was working on it originally with the latest WiX2 drop and ran into some difficulties (my own doing it turns out). While troubleshooting, I thought I'd give the latest 3.0 drop a try just in case some bugs had been fixed.

After backing up my *.wxs files and running them through the new wixcop using the -f switch to upgrade the schemas I received compile errors around the pubca extensions. Looking around, I found there wasn't any binaries for this in the drop. My next approach was to browse the CVS repositories thinking maybe they just weren't included in the packaging yet. Nope.

I jumped on the wix-devs mailing list and asked about the missing pubca stuff in Wix3. Kudos to Rob Mensching who responded within 30 mins. with the answer...the pubca custom action stuff has yet to be merged into the WiX3 codebase. So...if you're doing COM+ stuff you'll have to stick with WiX2 for now.