when setup isn't just xcopy

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

Rob Mensching — Tue, 05 Dec 2006 10:12:21 GMT

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

Rob Mensching — Sat, 04 Nov 2006 18:12:10 GMT

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.

Rob Mensching — Fri, 27 Oct 2006 07:41:07 GMT

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

Rob Mensching — Mon, 23 Oct 2006 18:00:53 GMT

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.

Rob Mensching — Tue, 17 Oct 2006 20:54:57 GMT

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)

Rob Mensching — Tue, 17 Oct 2006 20:27:03 GMT

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)

Rob Mensching — Thu, 12 Oct 2006 18:05:00 GMT

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?

Rob Mensching — Tue, 10 Oct 2006 18:55:01 GMT

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.

Rob Mensching — Sun, 08 Oct 2006 07:18:18 GMT

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.

Rob Mensching — Fri, 06 Oct 2006 09:33:00 GMT

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.

Rob Mensching — Thu, 05 Oct 2006 18:00:00 GMT

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

Rob Mensching — Tue, 03 Oct 2006 09:32:25 GMT

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.

Rob Mensching — Sat, 30 Sep 2006 20:14:28 GMT

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.

Rob Mensching — Fri, 22 Sep 2006 06:10:03 GMT

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

Rob Mensching — Tue, 19 Sep 2006 05:40:17 GMT

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.

Bittersweet change, Derek Cicerone leaves WiX.

Rob Mensching — Sat, 16 Sep 2006 08:13:02 GMT

As I noted in my previous blog entry, there is a lot of change in my life right now. Today Derek Cicerone announced that he is retiring from the WiX community. What Derek left out is that today was also his last day at Microsoft after four years. He leaves this weekend for a startup in Silicon Valley.

I've known about Derek's plans for about two weeks but it still hasn't sunk in yet. You see, what most people don't realize is that Derek was instrumental in making the WiX toolset so successful. WiX v2 core toolset would not be nearly as stable as it is now. More importantly, WiX v3 would not exist without Derek's efforts. For example, let's say there are about ten to fifteen major improvements in the v3 core toolset over v2. I only wrote one of them.

I want to tell the story of how Derek came to be so important to the WiX toolset but before I do there is one thing I want you to keep in mind. Prior to his decision to leave, I actually considered passing on leadership of the WiX toolset to Derek.

But let's go back to September, 2002. I remember the first time I met Derek Cicerone. I was in Reid Gustin's office and we were discussing some portion of Courier (the datacenter deployment system used by Office Online). The new hire that was to share the office with Reid (until Reid's internship ended and he went back to Stanford late September) showed up in the middle of our discussion.

The new developer and his lead were discussing the project he was going to be working on. Reid and I weren't trying to listen in but at some point the new hire asked, "So what is all this programmed in?" The lead responded, "Pretty much everything in Office is C/C++." The new hire said, "Oh, I don't like C++." There was a pause, while Reid and I looked at each trying not to snicker. Finally, the lead asked, "So what language do you like?" The new hire responded, "Oh, I like Java." I don't know if either Reid or I actually laughed out loud then but we both knew that the new developer was definitely not starting on the right foot. Derek Cicerone made quite the impression on his first day at Microsoft.

It was about a year later that Scott "K" Kurtzeborn called me up saying that Office was thinking seriously revamping their custom MSI build system. K wanted me to talk to the person in charge of the design process because K thought WiX might be a good replacement. I had just joined the SDM team at that time and was amused that I had to leave the Office team for Office to consider switching to the WiX toolset. You can imagine how much more amused I was when K showed up for lunch with none other than Derek Cicerone.

Over the next year, Derek would come into his own. First, he was instrumental in convincing his management in Office to take a risk on the newly rewritten WiX v2 code base. Succeeding at that, Derek dove into the space, finding bugs, then helping fix bugs, then actively participating in new feature design and development to grow the WiX toolset to meet the needs of Office. Finally, Derek became an active member of the community by answering questions and addressing bugs and feature requests.

Back in the early days of 2004, Reid (who had joined the SDM team out of Stanford), Derek, K, Robert Flaming and I met at my house every Tuesday night to work on the WiX toolset. We covered huge amounts of ground in those days. It was so much fun.

Derek became the champion for consistency in the code. He went through numerous sweeps through the WiX v2 code base cleaning up blocks of code, trying to simplify everything, and fixing bugs he found along the way. Derek also created the unit test infrastructure we use to test the WiX toolset. Finally, Derek became a co-collaborator on new designs and features for the WiX toolset.

The core WiX development team spent 2004 and most of 2005 simply fixing bugs in the WiX v2 code base, striving for stability in the core toolset. In the summer of 2005, Derek wanted to start development on some of the ideas we had tossed around over the last couple years but didn't want to add to WiX v2 for fear of destabilizing the code base. Finally, in October of 2005, we created WiX v3 and Derek simply took off. A year later, I am amazed at how much nicer WiX v3 is to use and how very powerful the new features make it.

Also in 2005, the Visual Studio team approached the core WiX development team about replacing their custom MSI build system with the WiX toolset. Derek was at every meeting with me. Together we answered their questions, discussed timelines and feature requests and ultimately convinced the Visual Studio team to bet on WiX v3 for their next release of Visual Studio. Without Derek's experiences integrating WiX into Office, I'm not sure we could have convinced Visual Studio to pick up the WiX toolset.

Then in 2006, Derek did even more of the work to get the SQL Server team moved to the WiX v3 toolset. Thanks to Derek's efforts, I expect by late 2007 the standard MSI creation technology at Microsoft will be the WiX v3 toolset. So, I hope you can see now why I considered handing over leadership responsibility of the WiX toolset to Derek Cicerone. He had certainly earned it, had he wanted it...

However, Derek and I never actually had that conversation because Derek decided it was time for him to move on to very different problems than what Microsoft and the WiX toolset solved. After spending these last three years getting to know Derek, I'm certain this change is a great move for him. In fact when he told me about the opportunity, I could only encourage him to go for it wholeheartedly.

This is a bittersweet day for me. The WiX community has lost a great contributor and leader in Derek. However, he has found something that aligns amazingly well with his interests. I wish him the best of luck in it all and look forward to seeing him again November 4^th, 2006.

When it changes it pours.

Rob Mensching — Wed, 13 Sep 2006 10:13:51 GMT

The weather is starting to turn here in Redmond. Fall is right around the corner. With the change in seasons comes several significant and personal changes in my life. Preparing for those changes has actually impinged on my blogging lately. Over the next few months, I'll be sharing each of these major changes here.

While poised at this precipice of change for a short period of time, I've had some time to reflect on a question that struck me in the past. "Why does it seem that changes get all bunched up together, instead of happening evenly over time?"

Friends I've talked to have asked similar questions and we've shared hypothesis. One idea that I cling to is that maybe we only remember or truly recognize the changes in our life when there are several stuck together to create a major event. Another thought is that one change can break free a lot of other changes and all of these variously sized changes create a major event.

In any case, I'll have more info at the end of the week. In the meantime, keep coding. You know I am.

Thursday Night "Deployment Dinner Discussions" with Rob Mensching.

Rob Mensching — Sat, 26 Aug 2006 05:30:39 GMT

Over the last couple months, I have been trying to come up with new ways to connect with the software installation community. A couple weeks ago, I presented my first idea to Jenny. The idea was to invite people over for dinner at our house to eat, sit, and talk. Jenny agreed and last night we the first of what I hope is many Thursday night "Deployment Dinner Discussion".

Our first guest was Stuart Schaefer and his wife Ann (spelling?). Stuart was CTO of Softricity and is now an architect at Microsoft, since Microsoft recently acquired Softricity. Stuart and Ann brought beer and dessert while I grilled the Korean Burgers and mixed up the salad. It was a fun night of sharing histories with a bit of geek talk mixed in. One of these days, I need to get around to sharing my thoughts on virtualization.

I would like to extend the same invitation out to others in the software installation/deployment field. If you're visiting Redmond and have a Thursday evening open in your schedule, drop me a line. It doesn't matter if you work for a big company or small company or just yourself. If you find any of the content on my blog interesting or useful, we probably have something in common. Just drop me a comment with your planned itinerary and we'll see if the timing works out with Jenny and my Thursday night schedules.

Creative Commons Add-in's Office XP PIA - Conditioning the Office XP PIAs - Part 1

Rob Mensching — Tue, 22 Aug 2006 16:19:00 GMT

Previously I described how the Office XP PIA install detected what parts of Office XP were installed. There are two places that the detection information is used and there are weaknesses in both places that we'll discuss. In this blog entry we'll take a look at the first place the detection logic is used.

The condition we'll cover here is hopefully self explanatory, not that I'm content to just leave it with that. <smile/> Imagine a line of WiX code that is a child of the Product element that looks much like this:

<Condition Message="Please install Microsoft Office XP before installing this product.">
ACTION~="ADVERTISE" OR ACTION~="ADMIN" OR OFFICE10INSTALLED OR REMOVE~="ALL"
</Condition>

That Condition element turns into an entry in the LaunchCondition table. The easiest way to read the condition is to look at the content in the element and say, "If the ACTION Property is equal to ADVERTISE or ADMIN (ignoring case) or the Property OFFICE10INSTALLED is defined or REMOVE Property is equal to ALL (ignoring case) then let the install continue. Otherwise, display the message that says you have to install Office XP."

Let's break the condition down once more.

1. The ACTION Property is a standard Windows Installer Property. It can only have three values and ADVERTISE and ADMIN are described here. Fundamentally, this part of the condition says, "If we're doing an advertisement or an administrative install just pass on through."

2. The OFFICE10INSTALLED Property is a custom Property that is set via a ComponentSearch element for (what I'll call) the "Core Office Component" GUID. If the Core Office Component is installed the OFFICE10INSTALLED Property will contain the path to the KeyPath. If the Core Office Component is not installed then OFFICE10INSTALLED will not defined and the condition will fail. Obviously, this is the key part of the condition.

3. The REMOVE Property is another standard Windows Installer Property. I highly encourage you to read through the MSI SDK documentation about the REMOVE Property. Done? Good. In this case, the REMOVE Property is used to ensure that the condition will never prevent the user from uninstalling the Office XP PIA package. Imagine how frustrating the user would be if she first uninstalled her copy of Microsoft Office then tried to uninstall the Office XP package and found that she could not because the PIA package required Microsoft Office installed.

Now that we understand the condition, let me show you the various weaknesses in this little bit of logic. None of these are fatal, but each of them could be improved.

1. There isn't anything inherently wrong in allowing advertisements and administrative images to be created even though the other parts of the condition may later fail. However, in the Office XP PIA install there are two other conditions that basically make this part of our condition irrelevant. Curious what those conditions might be? Here's the WiX code for those two conditions:

<Condition Message="[ProductName] can not be installed with the ADVERTISE action.">
ACTION~&lt;&gt;"ADVERTISE"
</Condition>
<Condition Message="Creating an admin install for [ProductName] is not supported.">
ACTION~&lt;&gt;"ADMIN"
</Condition>

2. The weakness with the second part of the condition is a bit more subtle. The Office XP PIAs only provide value if you have Word, Excel, PowerPoint, Access, Outlook, FrontPage, Publisher, Visio, or OWC installed. However, it turns out that the "Core Office Component" ends up shipped in quite a few Microsoft products. That means that there are cases where the Office XP PIA install package can be installed even though you don't actually have any applications that could use the PIAs on your machine. As we'll see next time, there are no adverse affects of allowing the install through but it certainly isn't optimal.

3. The final weakness actually demonstrates a change in what I used consider best practices and what I believe are "better practices" now. As noted in the scenario above, it was very important to add the REMOVE Property to the condition so the Office XP PIAs could always be uninstalled. In the past that seemed sufficient. However, now it seems better to use "Installed OR" in LaunchConditions. The Installed Property is standard Windows Installer Property like REMOVE but Installed is always set after the package is installed. Using "Installed OR" means that LaunchConditions will never block the user from repairing, patching, or uninstalling the package once it is installed.

Next time we'll dig into how we condition the Office XP PIA install to only install the right PIAs.

This then this then this. What am I still doing here?

Rob Mensching — Wed, 09 Aug 2006 11:50:07 GMT

First, I see this. Then I'm skimming my RSS backlog and see this that points at this.

This isn't the first time but it is the most recent occasion to pause me a moment and wonder, "What am I still doing here?"

Blogging from the outside.

Rob Mensching — Mon, 07 Aug 2006 03:40:00 GMT

Jenny talked me into going shopping for patio furniture today. I was skeptical. There isn't a lot of space on our deck upstairs. I wasn't sure how well a table, four chairs and an umbrella would fit. That and I was thinking it would be more cost effective to go shopping at the end of the summer when stores were more likely to be unloading their outdoor furniture.

It turns out that August pretty much is the end of the patio furniture season. There was very little selection and what was available was seriously marked down. Fortunately, Jenny and I found what we were looking for at Target for 30% off (my Mom would be so proud).

Once home we enjoyed margaritas then hamburgers and most recently strawberry shortcake outside with our new patio furniture. Now I am just chilling out, writing this blog entry in between long glances towards the sun behind the trees.

Sometimes I forget how nice it is to shift into neutral and just coast along for a while.

Creative Commons Add-in's Office XP PIA - Detecting Office XP Parts

Rob Mensching — Fri, 28 Jul 2006 08:12:00 GMT

There was a lot more interest in the Office XP PIA install that Bob created than I expected. I'm currently in the process of trying to get the Office team to take the work we did back and post that instead of the loose collection of files available today. I believe this is the most useful path for everyone involved. If that effort isn't successful then I guess I'll have to host the .wxs file to build the Office XP PIAs somewhere so everyone can build their own Office XP PIA installer (a far less enticing idea).

In the meantime, let's talk about one of the tricky parts of the Office XP PIA install. While doing research into PIAs, and the Office PIAs in particular, I came across Art Leonard's post about PIA registration issues. I remembered Art from my days on the Office deployment team. He was doing work on the PIAs back before any of us even understood what they were for. I wish I knew what I know now back then. <smile/>

Anyway, the gist of his blog entry (if you didn't read through it all) is that you should only install PIAs that match the installed Office applications. In other words, if you only have Word 2002 installed then only the Word PIAs should be installed. If you have Excel 2002 and Outlook 2002 installed then only the Excel and Outlook PIAs should be installed.

Great, as if I wasn't perturbed about the whole missing Office XP PIA MSI install to being with. Now they had to go off and make it one step harder. Well, according to Art's blog post, what we're really need to be looking for is the TypeLibs that get installed for each application. Fine, I can do that with a RegLocator table entry or a RegistrySearch element in WiX.

The WiX source code to search for the Excel 2002 TypeLib looks like this.

  <Property Id="EXCELTYPELIBREGISTERED10">
    <RegistrySearch Id="FindExcelTypeLib10" Root="HKCR" 
                    Key="TypeLib\{00020813-0000-0000-C000-000000000046}\1.4" Type="raw" />
  </Property>

The Word 2002 TypeLib RegistrySearch looks like this:

  <Property Id="WORDTYPELIBREGISTERED10">
    <RegistrySearch Id="FindWordTypeLib10" Root="HKCR" 
                    Key="TypeLib\{00020905-0000-0000-C000-000000000046}\8.2" Type="raw" />
  </Property>

How did I get those TypeLib Ids? I used Orca to peek into the Office XP MSI and cross referenced the data I found there with what was in the registry after install. Pretty easy, in the end.

Next time I'll show what we do with the search results such that we follow Art's advice.

Wow, Microsoft Acquires Wininternals.

Rob Mensching — Tue, 18 Jul 2006 16:46:47 GMT

PressPass just released the news that Microsoft has acquired Winternals. This is amazing. I've seen Mark Russinovich speak and he presented the data extremely eloquently. However, what impressed me even more was the tools provided at Sysinternals were always really "tight". I mean that in every sense of the word. They were small, they were targeted, and they were flippin' cool. Tight.

May Mark and Bryce Cogswell (who I know nothing about) continue to stay "tight" inside the firewall.

Creative Commons Add-in for Microsoft Office: Behind the Office PIAs.

Rob Mensching — Thu, 13 Jul 2006 04:28:52 GMT

Tonight, we'll continue with the story of the development of the Creative Commons Add-in for Microsoft Office. As I mentioned in the introduction one of the first problems that we tackled was the Office PIAs. Rather than provide you second hand information about the development of the PIA packages, I've invited Bob Arnson to be a guest writer and tell you the story himself. So, without further ado, I present the "Rolling Your Own Redist" by Bob Arnson.

When a few members of the WiX team took on the side project of building the setup for the Creative Common Add-in, we had a set of requirements like most any software project. One of the requirements was that the add-in must support both Office XP and Office 2003.

As Rob mentioned, to support both versions of Office meant dealing with both sets of primary interop assemblies (PIAs). For Office 2003, that's fairly straightforward. Though Office Setup doesn't install the PIAs by default, Microsoft provided the Office 2003 PIAs as a redistributable MSI package.

For Office XP, the situation was a little less pleasant. The Office XP PIAs came as a set of DLLs, .reg files, and a batch file that calls Gacutil to install the assemblies into the .NET global assembly cache (GAC) and Regedit to write registry entries from the .reg files. Gacutil is a development tool, though it shipped in the .NET 1.1 Framework runtime. (In .NET 2.0, it's only in the SDK.) The Gacutil documentation even warns against its use as an installation tool:

Be aware that using the /i and /u options alone does not support reference counting. These options are appropriate for use during product development but not for actual product installations.

In fact, the batch file contains the following comment:

Note: This utility must be run from the Visual Studio .NET Command Prompt. It will not function properly otherwise.

And a batch file that calls Regedit? Well, you can read Rob's opinion on script custom actions and imagine how that might translate to using batch files during a real product setup.

So I signed up to create a good setup package for the Office XP PIAs. The batch file told me what I needed to do -- install the assemblies into the GAC and write some registry entries. Windows Installer natively supports both actions.

So one Tuesday night, instead of working on WiX, I put together a "first draft" of the Office XP PIA installer. Installing assemblies into the GAC is easy: Just add Assembly=".net" to the assembly's File element. For example:

<File 
  Id="MoiFrontPage.dll" 
 Name="Microsoft.Office.Interop.FrontPage.dll" 
  KeyPath="yes" 
  Assembly=".net" 
  DiskId="1" 
  Source="Microsoft.Office.Interop.FrontPage.dll" />

Converting the .reg files to WiX source code was also easy thanks to the WiX Tallow tool. I took the fragments Tallow created and pasted each one into the same component that held the assembly.

A few tests later, I was confident we had a decent installer for the Office XP PIAs. The job wasn't quite done -- Rob later added ComponentSearch, RegistrySearch, and FileSearch elements to prevent the PIAs from being reinstalled if they're already present. But none of it required any secret information from inside the Microsoft firewall. Best of all, there are no custom actions or batch files.

7 lbs. of M&Ms means only one thing.

Rob Mensching — Wed, 28 Jun 2006 16:48:32 GMT

If you follow Microsoft culture then you've undoubtedly heard about the distribution of M&Ms on employee anniversaries. Specifically, it is tradition to put one pound of M&Ms for each year you've worked at Microsoft in a bowl outside your office. Today there is a bowl with seven pounds of M&Ms outside my door. If you're in the Redmond area, I encourage you to stop by my office and have some. If you're off campus, drop me a note via the contact and I'll let the building receptionist know to expect you.

Year 1 (June 1999 - June 2000): worked on Office deployment team (to ship Office XP)

Year 2 (June 2000 - June 2001): worked on Office deployment team (shipped Office XP)

Year 3 (June 2001 - June 2002): worked on Office deployment team (to ship Office 2003)

Year 4 (June 2002 - June 2003): worked on Office deployment team (to ship Office 2003)

Year 5 (June 2003 - June 2004): transitioned to System Definition Model team (shipped in VSTA)

Year 6 (June 2004 - June 2005): transitioned to Windows deployment team (to ship Vista)

Year 7 (June 2005 - June 2006): worked on Windows deployment team (to ship Vista)

Year 1 - Year 7: worked on Windows Installer XML toolset