when setup isn't just xcopy

Goodbye, MSDN. I'm moving to http://RobMensching.com/blog.

I started blogging three years ago when the MSDN blog site was still hosted on gotdotnet.  Back then there were fifty or so Microsoft bloggers and people giggled when you said the word "blog".  Now there are so many Microsoft blogs that nobody bothers to keep count any more.

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 http://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 http://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 http://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 http://RobMensching.com/blog.

It all begins in November...

As noted previously, there are some major changes going on in my life right now.  This is the third and final change.

There are a few people out there that read my blog to hear my thoughts on software installation topics.  There are others who read my blog looking for tidbits of information about how Open Source works at Microsoft.  There is a third group of people that read my blog to see if their name shows up in text anywhere.  This blog entry is all about one person in that third group, Jennifer Marshall.

A little more than three years ago, I met Jenny at the Century Ballroom.  I arrived early for the open dance that night and was waiting for the Swing class to finish up.  For those of you that have you've never been out social dancing, let me paint you a picture.

Imagine a gigantic square hard wood floor with a two story open air above it.  Imagine a stage up front and white covered tables around the other three edges of the dance floor.  Now, imagine two rings of about sixty people dancing.  On the outside ring, the leads (usually men, but this is Capitol Hill so you never can be sure <smile/>) face in and on the inside ring of people the follows (usually women) face out.  The instructors (one lead, one follow) are in the middle providing, er, instruction.  Finally, imagine the instructors calling out "Switch" every couple minutes and having the inner ring of follows move one lead to the left so everyone dances with everyone else.

I was sitting on the window sill across from the stage watching the beginner dance class.  I had been taking classes for a month or so by then and was able to tell which follows we following well.  One follow in particular caught my eye.

She was all the way across the dance floor.  I wish I could say it was her dancing that caught my eye but, honestly, I don't remember.  I do remember seeing her long hair, fitted button-up shirt and sleek black slacks.  But what caught my eye was how she moved from one lead to lead with confidence.  When class ended shortly after she caught my eye, I watched her practically glide off the dance floor.

Jenny loves to tell this part of the story but you'll have to do with my rendition for now.  I hopped up off the window sill and slid up in front of her.  By this point, Jenny will tell you I was smiling from ear to ear but all I remember was saying, "Hi, I'm Rob.  Are you staying for the dance tonight?"

Jenny didn't stay that night, she had a test to go study for.  However, the following week as the introduction to Swing dancing circle went around before open dance and she showed up before me.  I said, "Hi, Jenny." she said, "Hi, Rob." and we have been dancing together since then.

Today Jenny and I are making together forever official.  November 4th, 2006 at the Edgewater hotel Jenny and I will be married.

Everyone should be so lucky to have someone as caring, generous, happy, outgoing, and beautiful as Jenny in their life.  We have been through quite a few adventures in the last three years and I really look forward to what the next many, many years will bring us.

I said before, "It all begins in November."  For Jenny and I life really does.  For the rest of you, Jenny and I are taking a couple weeks off to go enjoy Kauai and Maui.  We'll be back in time for Thanksgiving and I'll get back to writing sometime around then.

Until then, keep coding.  I'll be on the beach drinking drinks with little umbrellas in them with my new wife.

Joining Marketplace.

As noted previously, there are some major changes going on in my life right now.  Derek leaving Microsoft and the affect that would have on the WiX toolset was the first one I made public.  This is the second.

It was two years ago this month that I moved from the System Definition Model team to the Windows Core Operating System Division (COSD).  It has been a challenging ride but we did manage to build the new servicing infrastructure for Windows Vista.  I learned a lot about the setup for the Windows operating system and refined some of my debugging skills.  I also learned that I want to be more connected to customers than my role in COSD allowed.

So, it is time to leave.  I've operated in the depths of the operating system for long enough.  I want to get back to improving the lives of customers directly.  I want to work on something that helps ISVs ship better software to customers faster.  I want to work on a small team with huge charter.

In a funny turn of events, as I was planning to walk out of Microsoft, Stephen Walli introduced me to my future boss.  At the end of November, I will be joining the Windows Marketplace development team.  Once there I will be focusing on the digital locker and the "software distribution" side of Electronic Software Distribution (ESD).

Never before have I been so excited to get started on a new project.  There are so many features in Windows Marketplace to enhance, improve and outright create that I'm sometimes not sure where I want to start.  But best of all there is no speed limit.  We have all been encouraged to go as fast as we can.

It all begins November.

Orca is to hex editor as WiX is to ...?

Jonathan Perret made the following interesting comment on a previous blog entry:

...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="http://wix.sourceforge.net/schemas/clickthrough/isolatedapp/2006">
   <Package>
      <Feed>http://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".

WiX v3 syntax for detecting the CLR.

Duane Johnson asked how to use WiX v3 to detect the CLR.  Extensions in WiX v3 are far more powerful than they were in WiX v2.  Unfortunately, to enable the new features a few things moved around. 

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.

Deciphering the MSI Directory table, part 7 (directories are properties)

In my last blog entry, I wrapped up saying that we'd talk about how to make your install directory configurable this time.  I'm sorry but I lied.  There is an important but confusing truth that you must understand before we continue.  Directories are Properties.

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...

Deciphering the MSI Directory table, part 6 (standard directories)

Before picking up this series of blog entries on the Directory table again, I went back and re-read all the previous entries to make sure I remembered the details told up to this point.  It was then that I realized the last entry on this series as posted over 11 months ago.  What disturbed me even more than the fact that I didn't realize I had dropped this series for so long (I thought I had posted in the last three months) was this quote:

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.

Conflicts of Interest?

Nicholas Carr has a great blog entry about conflicts of interest in blogging.  It got me thinking about a silent policy I've always had for myself when blogging here.  I don't blog about the many vendors in the MSI creation space except the ones that I am affiliated with.  Namely I write about the WiX toolset (because I lead that effort) and sometimes VisualStudio's Setup Projects (because I work for Microsoft and I'm often asked to relate it to WiX ).  I don't write about InstallShield or Wise or the many, many others.

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.

Nothing.

Thus far, today I have done absolutely nothing.  Sure, I cleaned off the kitchen table, put away some dishes and folded some clothes.  But I didn't really do anything.  I spent a few hours playing through a few demo disks DJ lent me for the new Xbox 360.  But that accomplished nothing.  Most recently I've been catching up on random blog entries posted by people I follow.  Like Dare, Raymond and Aaron. But nothing will come of that tonight.

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/>

Thursday Night "Deployment Dinner Discussion" with Charlie Poole.

Tonight I traveled to Anthony's Beach Cafe in Edmonds, WA to have dinner with Charlie Poole.  Charlie is the active maintainer of the NUnit project.  He contacted me (via my blog, IIRC) and we set up tonight's meeting.  I expected he wanted to meet because NUnit is now using the WiX toolset too.

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. 

The Windows Live Writer team rocks.

I installed Windows Live Writer 1.0 Beta a while ago to test a project I was working on.  I didn't actually boot the application or anything, just installed it.  I think this proves how much of a setup geek I am.  <smile/>

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 2.1 - the latest WiX UI Editor

I was cleaning out some old mail messages and came across this tidbit of information that several people sent me.  SharpDevelop 2.1 now supports the WiX toolset.  At the same time, I noticed that SharpDevelop 2.1 moved to WiX to build its setup packages.  I took a quick scan through their MSI and it looks like a very well authored WiX v2 package.  They even use the standard UI and NGEN CustomActions provided by the WiX toolset.  Very nicely done.

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/>

It isn't whether you win or lose, as long as you're growing.

Robert sent me a couple quotes from Ichiro in this morning’s Seattle Times. I thought they were quite appropriate to my “Here & Now” so I thought I’d just drop the quote in:

"I think it's true for any player that they don't want to be on a losing team," Ichiro said Friday, speaking through a translator. "But even a winning team can't just win and not gain anything in the process.

"So, the question is, whether you're a team that's winning or losing, are you gaining? Are you growing? And are you going forward with that?"

PS: This is also a test of Windows Live Writer's blogging ability.

Thursday Night "Deployment Dinner Discussions" with Carolyn Napier.

Tonight Jenny and I hosted our second Thursday Night "Deployment Dinner Discussion". Our guests were Carolyn Napier and Steve Lesser.

Actually, it isn't that simple. You see, I have been meaning to invite Carolyn over for to see my house for about 3 years now (as long as I've lived here). On top of that, Carolyn and Steve just got married so Carolyn's last name won't be Napier for much longer. Although, she'll probably always be Carolyn Napier to me.

You see, Carolyn and I were interns together on the Windows Installer team back in 1998. Carolyn was there when I came back with the most heinous sunburn after a June snowboarding trip to Whistler. Carolyn was there when Orca was created. And, as she very much likes to remind me, Carolyn was there when I sent email to Bill Gates suggesting that more investment was needed software installation.

Carolyn is now the lead of the Windows Installer team. If you start counting from her first internship, she has probably been on the Windows Installer for a decade. As you would expect, Carolyn is the absolute authority on why the Windows Installer works the way it does. When I get stuck, I go talk to Carolyn.

Carolyn and I are also friends, so sometimes I just go talk to Carolyn. Tonight we talked about today's Company Meeting (I'll share some thoughts later). We talked about Derek's leaving Microsoft, Carolyn was his lead. We talked about the current events in the Microsoft flag football league. We talked about Steve's and Carolyn's recent wedding and honeymoon. We even talked about an ESPN sportscaster (I forget his name) who was praising the efforts of Occupational Therapy after his aneurism (Jenny enjoyed that part). All of this over Jenny's super tasty burritos and, for dessert, pumpkin muffins.

All in all, a very enjoyable evening. I already have another Thursday Night "Deployment Dinner Discussion" lined up for October in Edmonds, WA. As always, if you're visiting the Redmond/Seattle area and would like to sit down to talk setup, drop me a comment via my blog.

Until then, keep coding. You know I am.

WiX in Visual Studio

In my previous blog entry, I mentioned that Visual Studio was adopting the WiX toolset. Despite the fact that Derek was leaving, that post generated a bit of excitement. I even had a couple people contact me directly about the prospect that Visual Studio would be shipping WiX v3.

Unfortunately, when I said "the Visual Studio team approached the core WiX development team about replacing their custom MSI build system with the WiX toolset" I meant that Visual Studio would be using WiX to create the MSI file for Visual Studio. As far as I know, there are currently no plans to replace the "Setup Projects" (.vdproj) in Orcas with the WiX toolset. If they are, Visual Studio certainly haven't told me about it.

However, since a few people found the idea of replacing the .vdproj with WiX v3 so enticing, I'd like to do an informal poll. Please, leave a comment below if you have an opinion on whether Visual Studio should replace the current "Setup Projects" (.vdproj) with WiX v3. I'll be sure to point the guys I know on the Visual Studio team to the results.