I toyed with the idea with hosting my own private blog a while ago but got real serious about it when I finally picked up the vanity domain https://RobMensching.com.  I was keeping tabs on the Subtext project because of my work on the Internal blogs at Microsoft but when Subtext finally supported medium trust I figured it was ready to host my own blog.  Finally, in November I pushed the huge reset button on life by changing jobs and getting married all at the same time.  I figured I might as well reset my presence in the blogosphere.

You will now find my blog at https://RobMensching.com/blog.

I have not decided what I'm going to do with this blog.   Jascha and Didi have also been encouraging me to start posting on the Windows Marketplace blog.  Maybe I'll cross-post Marketplace topics from my new blog to there.  Honestly, though I think we first need to move the Windows Marketplace blog off MSDN and onto Windows Marketplace itself.  Maybe we could put it up at https://www.windowsmarketplace.com/blog.

Cross-posting there makes me consider cross-posting setup topics from my new blog to here, making this blog purely about setup things.  Along those lines I've brought back the MSDN skin and the old blog title "when setup isn't just xcopy".  However, don't be surprised if this blog just halts like Dare's MSDN blog and Alex's MSDN blog.

Anyway, "Goodbye, MSDN!"  It's been a fun few years but I'm moving out on my own.  Please come visit me at my new home at https://RobMensching.com/blog.

...I find it worrisome that even when using such a powerful tool as WiX, one still has to memorize such oddities. I mean, if my app has a prereq it sounds obvious I don't want to require it to uninstall the app. Why can't WiX implement this for me ?

Do you think it is a fair analogy to say that if Orca is like an hex editor then WiX would be MASM ? I.e. powerful for experts but every bit as dangerous ?

I'm going to address those in the opposite order.  First, I often introduce the WiX toolset as the C/C++ compiler/linker for MSI files.  With C/C++ you can leak memory, deference NULL and all kinds of other things that the programmer probably didn't intend.  The WiX toolset will similarly allow developers to do things that might not be what they actually intended.

I think comparing the WiX toolset to MASM is cutting a bit too deep.  There are many things the WiX toolset handles that the developer never has to worry about.  Always lining up primary/foreign key references in the MSI database is an obvious one but there many others like the handling of the NULL property ([~]) in MULTI_SZ registry keys and the NT service groups and enabling distributed setup development through Fragments and linking.

So why doesn't the WiX toolset just handle everything for the developer?  The answer is quite simple: "Because a developer might actually need to do what you wanted protection from." 

In this particular case, I provided guidance that the Installed property should always be OR'd into your LaunchConditions.  Doing so ensures that you can uninstall the application even if the condition is wrong.  The WiX toolset could probably always automagically add "Installed OR" to LaunchConditions to make sure that this guidance is followed.

But what if you as a developer actually need to block the uninstall of your application for some very specific reason?  If the WiX toolset always adds "Installed OR" to the LaunchCondition the developer is now fundamentally screwed by the very tools that were supposed to be helping.  Being a developer, I know that stupid tools trying to be smart are one of the fastest ways to infuriate a developer.

Remember, one of the guiding principles of the WiX toolset is that if the Windows Installer supports the scenario then the WiX toolset does as well or it's a bug.

So the question now is how do we enable developers do what they need to do while helping them avoid known pitfalls?  I know of two methods, both of which are supported in the WiX toolset.

1.  Static code analysis.  Tools that understand the code and point out things that you probably did not intend are wickedly cool.  Visual Studio added static analysis features in VS2005.  The Windows Installer has actually had static analysis since the late 1990s.  It's called "validation" and msival2.exe and Orca both support it.  In WiX v3, light.exe now runs the same static code analysis after every build and there is a tool called smoke.exe that you can use to analyze MSI files without building.

That said, today there is no rule that checks for the Installed property in LaunchConditions but it seems like a great thing to open as a Feature Request, Jonathan.

2.  Higher level languages.  I am obviously biased but I don't believe you will find a better low-level language for creating Windows Installer databases than WiX.  You can edit the .wxs files directly, use a GUI that converts the WiX elements into graphical concepts, or build another language that generates .wxs files and build your MSI files that way.  Higher level languages can be more simplistic because they target a specific need.

For example, I haven't talked about ClickThrough much lately but if you look at the language required to describe an Isolated Application in ClickThrough, I think you'll agree it's much higher level.

<IsolatedApp xmlns="https://wix.sourceforge.net/schemas/clickthrough/isolatedapp/2006">
   <Package>
      <Feed>https://localhost/ct/dc/DrizzleCast.feed</Feed>
      <UpdateRate>1</UpdateRate>
   </Package>
   <Application>
      <EntryPoint>DrizzleCast.exe</EntryPoint>
      <Source>C:\build\dc</Source>
   </Application>
</IsolatedApp>

For more information check out this blog entry about "domain specific languages".

So, let's say you wanted to to ensure that the .NET Framework 2.0 is already installed.  All you have to do is add the following to your setup source code somewhere under the Product element:

<PropertyRef Id="NETFRAMEWORK20"/>
<Condition Message="The .NET Framework 2.0 must be installed">
   Installed OR NETFRAMEWORK20
</Condition>

To compile that snippet (and answer Duane's question) using the WiX v3 toolset, you'd do the following:

candle -ext WixNetFxExtension my.wxs
light -ext WixNetFxExtension my.wixobj

That should create "my.msi" that will only install if you have the .NET Framework 2.0 already installed.  We continue to grow the list of Properties that the WiX toolset handles for you automatically.  For example, we already have searches for many of the Microsoft Office SKUs and Visual Studio as well.  We're also always looking for more built-in searches so if you have them and would like to contribute them to the community, send email to wix-devs @ lists.sourceforge.net.

Finally, for the intrepid reader at home, do you know why I OR'd the "Installed" Property into the LaunchCondition example above?  When you think you know, check out this previous blog entry for the answer.

Some of you may have already caught on to this because the MSI SDK documentation for what I call standard directories is labeled "System Folder Properties".  Also, if you at the ProgramFilesFolder directory you'll see it's actually called the "ProgramFilesFolder Property".  I've avoided using the word "Property" to describe what we've known as "Directory identifier" until now to avoid confusion.

So what does it mean that Directories are really Properties?

Well, for one, it means that anywhere you can put a Property reference, you can put a Directory identifier instead.  When the Windows Installer resolves a Directory identifier as a Property it gets the full path for the directory.  For example you could put "[ProgramFilesFolder]" in the Value column of the Registry table and get the full path to the Program Files directory in the registry key. See the Formatted topic in the MSI SDK for more information.  Also, remember from our previous examples, that all Windows Installer paths end with a backslash.

The fact that Directories are Properties also means that Type 51 CustomActions can be used to change install locations.  But we'll talk more about that next time...

The first paragraph of part 1 surprised me because it reminded me how long I've been operating under frustration.

For some people this blog series will be deciphering the MSI Directory table.  For me this blog series will provide guide posts for a path I should never follow again.  But enough of that.  Let's get to the point and talk about standard directories in the Directory table.

As always I'm going to start with some example data.  If this stuff doesn't look familiar (that's okay, it's been almost a year) I suggest going back and (re)reading part 5.  Here's a Directory table modified from our part 5.

Directory           Directory_Parent      DefaultDirs
s72                 S72                   l255
Directory           Directory
TARGETDIR                                 SourceDir
ProgramFilesFolder  TARGETDIR             PFiles
FirstFolder         ProgramFilesFolder    One

Based on what we've learned thus far, you should expect that Directory table to create the following layouts:

Target layout
ProgramFilesFolder = TARGETDIR\PFiles\
FirstFolder        = TARGETDIR\PFiles\One\

Source layout
ProgramFilesFolder = SourceDir\PFiles\
FirstFolder        = SourceDir\PFiles\One\

You'd be half correct.  The source layout would look exactly like that.  However, the target layout would be quite different.  The magic is in the ProgramFilesFolder identifier.  That's because ProgramFilesFolder is what I call a standard directory.  The MSI SDK has the full list of standard directories.

So how does it work? 

Well, when the Windows Installer scans the Directory table, it converts the standard directory identifiers into the appropriate paths on the machine.  For example, ProgramFilesFolder turns into the value returned by ::SHGetFolderPath() for CSIDL_PROGRAM_FILES which is usually something like "C:\Program Files\".  The LocalAppDataFolder identifier is the value returned for CSIDL_LOCAL_APPDATA which is usually something like "C:\Documents and Settings\username\Local Settings\Application Data\".

That means that our target layout actually looks something like this:

Target layout
ProgramFilesFolder = ProgramFiles\
FirstFolder        = ProgramFiles\One\

Note: "ProgramFiles" is intended to represent wherever "C:\Program Files\" actually exists on the user's machine.  You should never expect ProgramFiles to be on the C: drive or even in "Program Files".  I say this because the "Program Files" string is localized, that'll getcha' for sure.

This means that the FirstFolder directory will always be under ProgramFilesFolder.  Next time we'll see how to allow the user to configure where your application gets installed.  In the meantime, I would encourage you to take a look at that list of standard directories the Windows Installer provides you.

My question to those of you who read my blog regularly is, "Do you think this policy is a good one and should I keep following it?"  Please, leave a comment below or send me a comment through the contact link.

What I've found amazing is that it actually feels good.  Normally, I'd be itching to make at least some progress on at least one of the many projects that I'm currently juggling.  But today I really did nothing.

So, I hope one of you out there is coding tonight because right now I'm obviously not holding up my end of the deal.  I blame it on last night's carbombs.  <smile/>

Charlie did want to talk a little about WiX but we discussed a myriad of other topics as well for the two+ hours we were there.  In fact, we shut the place down.  Only the cooks were left cleaning when we walked out.

The most interesting setup related topic was something Charlie thought I wouldn't be interested in.  NUnit is all managed code.  It supports all versions of the CLR as well as Mono.  Charlie told me he had written the detection logic for all the CLR versions and Mono.  I told him that the WiX toolset already had the detection logic for the CLR and he should just use that but I was very interested in getting the Mono detection logic into WiX.

Charlie was surprised by both answers.  He asked how to use the CLR detection in WiX v2 now.  I didn't have the answer off the top of my head, but now that I'm home here's how you do it.  Add any (or all) of following to one of your .wxs files:

<PropertyRef Id="NETFRAMEWORK10"/>
<PropertyRef Id="NETFRAMEWORK11"/>
<PropertyRef Id="NETFRAMEWORK20"/>
<PropertyRef Id="NETFRAMEWORK30"/>

Then you need to add the "netfx.wixlib" to your link line like so:

light my.wixobj netfx.wixlib -o my.msi

That will add the appropriate detection logic to your MSI for the CLR using the WiX v2 toolset (WiX v3 command line syntax is a bit different).  Hopefully Charlie send back the Mono detection logic in a "mono.wixlib".  Over time, I hope WiX will have all these sorts of things done for you in many prebuilt .wixlibs.

We also discussed Charlie's adventures in Europe learning and talking about Agile/XP methodologies, including what sounded like a fun trip with Ward Cunningham.  I also asked a number of questions about his consulting work.

Another interesting topic we came upon was talking about our different Open Source projects.  Charlie mentioned he had communicated with Miguel de Icaza when struggling with is project.  I think you can see a bit of that in his blog entry about the exaggerated death of NUnit.  We then discussed the relation of our Open Source projects with Microsoft.  Charlie asked why not make WiX the foundation of Visual Studio setup projects.  I told him I would love for that to work out.  Then I asked him about NUnit and VSTS.  Charlie pointed out that VSTS isn't structured properly to do true test driven development (TDD) but said he enjoyed the competition.

All in all, it was a great dinner and I look forward to crossing paths with Charlie Poole in the future. 

Well, as you can see in my previous blog entry, I actually tried using Windows Live Writer.  I must say, in the short time I've used it, I'm impressed.  The UI is very intuitive.  The HTML generated is very clean.  The ability to preview the post using the styles from my blog is sweet.  I love the way that "Recent Posts" and "Drafts" are tracked seamlessly.

That said, I have had some small issues with cut and paste not doing exactly what I expected (whitespace just disappeared).  Window Live Writer also doesn't provide an easy way for me to add code snippets to blog entries (awesome if it was supported just like blockquote).  But I can edit the HTML directly to add PRE elements and Writer seems to handle that pretty well.

But this blog entry isn't supposed to be about Windows Live Writer application.  Instead, I wanted to talk about the Windows Live Writer team. 

I met three of the developers on the Writer team a month or so ago: Bonnie, Joe and Spike.  We had a great discussion for almost two hours after work one Thursday.  One of the things I remember most is when we were discussing Beta feedback Joe commented sheepishly, "Probably the biggest mistake we made was not including the word 'blogging' in our dictionary.  Lots of people complained about that."  I chuckled when I posted my last blog entry because I did have to add "blogging" to the dictionary when the spell checker complained.

 But even more important than the interesting conversation I had with Bonnie, Joe, and Spike, I saw something I hadn't seen inside Microsoft for so long I had almost forgotten to look for it.  This team is hungry.

They aren't just building a simple blogging tool.  They are building a blogging tool that beginners can be comfortable with while meeting advanced users basic needs.  Then they released an update to their Beta based on user feedback.  Next they made their application a platform and opened up an untold number of new uses.  And most importantly they didn't blink when it was suggested Windows Live Writer wasn't necessary because Word 2007 would support blogging too (as Chris Corio might say, "The two apps are in completely different markets, yo!").

It wasn't until I was driving away that evening that the last piece of the puzzle clicked in my head.  Windows Live Writer was created by the same team that brought us Onfolio.  This team of hungry developers was acquired from the "outside".

That realization eventually crystallized into something that I have been feeling for a year or more.  It feels like many developers at Microsoft are "playing to not lose".  What I saw in the Windows Live Writer team was a small group of developers "playing to win".  I loved that.  It's past time for me to do the same.

SharpDevelop joins WiXEDIT and WiXTool as another freely available UI for editing .wxs files.  I'll stick to Votive (for Intelli-sense) and notepad2 (for quick edits with syntax highlighting) but those of you looking for a UI might find one of those three tools interesting.  At least until we convince Visual Studio to support the WiX toolset.  <smile/>