As one might be able to tell from reading previous posts of mine, I’m strongly in favor of using WiX to author MSI’s. Perhaps it’s my background in UNIX that leads me to feel this way (where doing things by hand is commonplace), but I’d sooner believe that it has more to do with my well placed mis-trust in any sort of tool that generates code or binaries solely through a GUI.

It wouldn’t be such a big deal if it weren’t for the extremely high level of importance one must attribute to the correct operation of the installation media. Your application may crash once or twice in its lifetime, and while that’s something we’d never want to see, it isn’t the end of the world. Initial installations that fail, however, are serious, since they give the user a terrible first impression of the program, among other things.

In this very short article, I’m going to illustrate a fatal mistake an inexperienced developer can easily make when authoring an MSI with WiX. This mistake can result in files from the install scattered across multiple hard drives. Fixing this undesired behavior is not required to publish an MSI, and it can easily go unnoticed during testing, therefore it is noteworthy.

Of course, don’t ever think WiX is a magic bullet. In the end, we’re still dealing with Windows Installer. To the inexperienced, Windows Installer is something that demands a lot of knowledge and preparation dealing with issues that do not manifest themselves as basic requirements for the creation of the installer.

If you’ve decided to use WiX, well good for you, but be aware that there are some things that you must configure, things that other authoring tools would have done for you.

One important one is the ROOTDRIVE property. This property defines the default drive for the installation. Not setting this property can lead to frightening results when dealing with customers that have multiple hard drives, especially if you have multiple features whose destinations may vary from one another. To be more specific, you can get yourself into a situation where some files are on one drive, and some on the other; this can be a very bad thing, I hope I don’t need to explain why.

If you don’t define and set ROOTDRIVE in the property table of your installer database, then the tool installing the product has to set the property. How does it determine which drive to assign to ROOTDRIVE? It simply looks at all available hard drives, and chooses the one with the most free space.

In most cases, this is not good. Many times the system and program files are on one drive, with a larger second drive available for user documents and such. A lot of programs are going to break if they are not on the system drive, which is traditionally the C: drive.

But, we don’t want to hardcode the property to the C: drive, we don’t want to hardcode anything like that ever. Instead, we will want to assign the drive that holds the Windows system files. This is accomplished like so:

<Property Id="ROOTDRIVE" Value="$(env.SystemDrive)" />

It ain’t rocket science, but it’s something that can be easily missed by the inexperienced.

Matt Weber

I'm the founder of Bad Echo LLC, which offers consulting services to clients who need an expert in C#, WPF, Outlook, and other advanced .NET related areas. I enjoy well-designed code, independent thought, and the application of rationality in general. You can reach me at matt@badecho.com.

  One Response to “The Root of the Problem”

  1. Unless I am mistaken, $(env.SystemDrive) is evaluated at build time (so it gets hardcoded to C: most of the time) and it does not end with a backslace which is a requirement (see MSDN for more details)
    So depending on the machine that builds, it can be different. In the end, it seems worse than letting Windows choose the drive with the most free space….

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 
   
© 2012-2013 Matt Weber. All Rights Reserved. Terms of Use.