Rob Mensching Openly Uninstalled

WiX v3 toolset end of the Beta imminent.

Rob Mensching — Sat, 29 Nov 2008 23:52:42 GMT

Last week Bob pushed the latest WiX v3 release to SourceForge. The original intention was to declare that drop as the final Beta build for WiX v3. However, I changed my mind for two reasons.

First, I know a lot people don't pick up weekly releases, only SourceForge drops. Sad but true. Since it had been a while since the last SourceForge drop and I wanted to make the drop then watch to see if anything new came up. Nothing has.

Second, we were very close to zero bugs on the core toolset and had a couple extension bugs that could be considered blockers. With an extra two weeks I was pretty certain that we could knock out a few more of those. Bob and I have made good progress through those this week (holidays can be good for the volunteer hours).

That means it is very likely that next week's release will be pushed as the "official WiX v3 Beta release".

You might wonder what it means for a project already called "beta" to have an official Beta release. In this case the Beta release marks the turning point where all of the major features for this release are finished and the bug flow such is under control and on a solid downward trend.

The goal is to provide a build and encourage all WiX v3 users to upgrade. That way we focus our efforts on finding all of the remaining bugs and figure out what bugs get fixed in WiX v3 and what gets moved to WiX v4. If you've found a bug in the WiX toolset get it filed soon.

Bob Arnson is actually the architect of this plan for finishing WiX v3 in 2009 so look for more details on Bob's blog over the next nine months.

tags: rob, mensching, wix, beta, build, soon

MSI SDK

Rob Mensching — Fri, 07 Nov 2008 09:02:25 GMT

The MSI SDK (also known as the Windows Installer SDK) is here http://msdn.microsoft.com/en-us/library/cc185688.aspx. For some reason the major search engines don't rank it highly.

You can also download the MSI SDK (which gets you the documentation in .CHM format plus several useful tools such as Orca).

tags: rob, mensching, msi, sdk, windows, installer

Geek humor: I am a duplicated bot.

Rob Mensching — Thu, 06 Nov 2008 18:52:39 GMT

Every once in a while something amusing happens on the wix-users mailing list that makes me chuckle. Sometimes, when they are short, I post them to my Twitter account. This morning I came across a new email to the mailing that started with "Hi Rob" which seemed a bit odd since there are hundreds of people on the list. Sébastien Mouren apparently found it interesting too since he made an amusing response:

Hi, it's not Rob here.
I'm Sébastien, a duplicated bot that has inherited a limited part of Wix Rob's knowledge. I am not a fully featured Wix bot since I'm not able to develop for the Wix toolkit.
But has your question has reached the "read documentation" level technical support, I'm able to understand it and hopefully to answer it.

I've lost count of the number of times I've said I wish I had a clone to get everything done. Little did I know it had already happened! In this case, even with the limited inheritance, more bots out there answering WiX questions well (or, at least, amusingly) is much appreciated.

And Sébastien thanks for the chuckle this morning. Keep answering the questions, you know I am.

tags: rob, mensching, wix, geek, humor, i, am, a, duplicated, bot

Anniversary at the end of the beginning.

Rob Mensching — Wed, 05 Nov 2008 07:51:16 GMT

A year ago I wrote about the quiet day of reflection on my first wedding anniversary. Today was a weekday, a work day and my job rarely allows the time to sit back and think about where I've been and what I've done personally. So I bailed early and ran a few errands gathering components for the small gift I gave Jenny tonight when we celebrated.

While running errands and after watching the historic events of the evening, I reflected on the last year. Easily the most dramatic event of the last year has been the process of selling "my" house and buying "our" house. We don't get to move in until this weekend but I had the vague notion that some "next phase of life" was around the corner when I "my" house was sold and completely empty a couple weeks ago.

At this point, my friends probably think (and my parents probably hope) that I mean "kids" but I don't. Not yet anyway. I think it's something simpler than that. Something like the end of the beginning.

Normally when I think of "the end of the beginning" "the beginning of the end" immediately comes to mind. But not this time. Instead I'm thinking "comfortable". Not the type of comfortable where you stop doing and stop growing. More the type of comfortable that serves as a solid foundation for reaching further and doing bigger things, new things.

Now, I don't know what those things are right now, I haven't turned that corner yet, but one thing is certain to me. I am officially declaring November 4th a personal holiday. From now on I will be taking that day off every year. After that, I don't know. For now... I'll just keep coding. <smile/>

tags: rob, mensching, jenny, second, cotton, anniversary

How to determine if you are installing on Windows Client vs. Windows Server.

Rob Mensching — Mon, 03 Nov 2008 22:26:18 GMT

This question just floated by and I had a similar question recently so I thought I'd capture it here to point search engines in the right direction.

Q: How do I determine if my MSI is being installed on Windows Client or Windows Server?

A: The Windows Installer provides the MsiNTProductType Property that is set to "1" for Workstations (aka: Client) and "2" for Domain Controllers (a Server albeit a rare Server) and "3" for Server (aka: uh, Server).

Here are a couple independent (and hopefully) self-explanatory examples using WiX syntax:

<Condition Message="[ProductName] is a consumer application and is not
supported on Windows Server.">Installed OR 1=MsiNTProductType</Condition>

<Condition Message="[ProductName] modifies the Active Directory and therefore
should only be installed on your Domain Controller.">Installed OR
2=MsiNTProductType OR OVERRIDE_DC_RECOMMENDATION</Condition>

<Condition Message="Windows Server is required by [ProductName].">Installed OR
1&lt;MsiNTProductType</Condition>

Remember the Installed Property is in all of those Conditions to ensure that the MSI can always be uninstalled. It may take some imagination to bypass each Condition (like an OS upgrade) but better safe than sorry.

WiX Working Group Wrap-up, October 23rd 2008

Rob Mensching — Fri, 24 Oct 2008 12:00:10 GMT

This wrap up is mostly content free but maybe the context is interesting.

If it hasn't been clear from Bob's weekly highlights, we're all about fixing bugs in the WiX toolset right now. Not much to report this week but next week should have more interesting details... and I'll hopefully have my hair cut.

"Its more about context than content."

Rob Mensching — Fri, 24 Oct 2008 11:47:46 GMT

Qik is working on my phone again so I thought I'd try getting back on the video horse. I conned Bob into holding the phone for me. But, I was still nervous about starting. So, we were talking a little bit and I realized that I was starting to address a comment left on my blog a long time ago. The comment went something like, "I prefer when you write blog entries instead of embedding video content because I can digest the text better than the images."

To loosen up a bit, I told Bob to record and I'd take a shot at answering the comment:

So to summarize, these videos aren't really intended to deliver technical content. Instead they are attempts to provide more context about the people that are doing the technical things. There is a lot more to the people that write the letters that appear on your screen and I'm experimenting with ways of expressing that.

I'm obviously still experimenting with the new technology here so your feedback is very interesting to me.

tags: rob, mensching, why, video, expression

Promoting from within.

Rob Mensching — Fri, 24 Oct 2008 11:00:03 GMT

For most people this isn't going to be a surprise and many may even ask what took so long. To be truthful the keys were granted a few weeks ago, I'm just finally getting around to blogging about it.

Over the last couple years, Bob Arnson has become a vital member of the WiX toolset going far beyond the call of duty. His first core role was taking ownership of the WiX UI providing some key functionality to the WiX community. Bob also became the regular "answerer of questions" on the wix-users mailing list taking a huge load off my shoulders. In the last year, Bob has contributed to all facets of the toolset and participates in or leads all major decision making for the WiX toolset.

Needless to say, Bob has become a vital member of the WiX community and I appreciate his efforts whole heartedly. I rely on Bob's contributions so much that three weeks ago I promoted him to co-administrator of the WiX toolset on SourceForge

Like all good promotions, nothing really changes (well, there is a 100% increase in pay). Bob has already been doing this job for a while now and we're really just improving our bus factor.

Seriously, though, this is recognition of Bob's outstanding work on the WiX toolset. If you haven't sent a happy thought to your friendly neighborhood WiX volunteer, send a happy-gram to Bob and thank him for his efforts.

tags: rob, mensching, bob, arnson, wix, promotion, co-administrator

WiX weekly builds back on track.

Rob Mensching — Fri, 17 Oct 2008 20:45:47 GMT

I just received notification that this week's weekly build of the WiX toolset has just been released. Since SourceForge moved their servers from California to Chicago we've been having issues getting builds posted regularly. The mistakes were all on our side (we missed the memo about some key configuration changes) and after a few goofed builds we appear to be back on track.

Sorry for any trouble these issues might have caused. Now back to the coding.

What are .wixlibs and why would you use them?

Rob Mensching — Fri, 10 Oct 2008 10:11:16 GMT

One of the cool contributions Visual Studio is making to the WiX toolset is the attention of a technical writer, Martin. Improving the WiX documentation is a constant request so any help someone is willing to provide is much appreciated. Of course, when there is very little information about a particular feature then technical writers have nothing to work their word-smithing magic on. Martin pointed out one such area recently: .wixlibs.

What is a .wixlib?

At its most basic level a .wixlib is simply a collection of .wixobjs. That hopefully isn't surprising since the input to the tool that creates .wixlib files, lit.exe, is a bunch of .wixobj files. If you look into a normal .wixlib, you'll see that it is just a <wixLibrary/> element wrapping a bunch of <section/> elements which is exactly what the <wixObject/> element does.

The difference is that a .wixobj contains only the sections from a compiled .wxs file while a .wixlib contains the sections from all of the .wixobj combined together by lit.exe. Another difference is that lit.exe can create a "binary .wixlib" which also combines all of the files referenced by the .wixobj files into the .wixlib. The "binary .wixlib" is a feature that was added in WiX v3 and is not available in WiX v2.

Ultimately, .wixobj and .wixlib files are passed to the linker, light.exe, to be processed into an .MSI or .MSM file.

Why would you use a .wixlib?

Since .wixobj and .wixlib files can be used interchangeably, you might wonder why bother with .wixlibs. There are a few reasons to consider.

1. Fewer files to link. If you product is very large and has lots and lots of .wixobj files then the linker may spend more time reading the many small .wixobj files than it would reading fewer but larger .wixlib files. If your build system allowed you to build .wixlibs in parallel then you may get better overall build throughput.

2. Fewer files to share. If you need to share setup logic with people who are using the WiX toolset, you can combine several of your .wixobj files into a .wixlib file or two. One or two files are certainly easier to consume than a directory full of .wixobj files.

3. Abstracts the source file organization. Similar to #2 but a little different. Since you get one .wixobj per .wxs file any changes to the organization of your source code mean that downstream consumers must also change, even if it is just to add another .wixobj file name to the light.exe command-line. If you share .wixlibs then you abstract away the number of .wixobj flies from the consumers of the .wixlib, simplifying their life. And who doesn't want to make their customer's lives better?

4. Binary .wixlibs are a better Merge Module. If you are sharing setup logic with people who are using the WiX toolset then binary .wixlibs are far superior to Merge Modules. The linker can introspect into binary .wixlibs better than Merge Modules providing better linking and error reporting. The linker can also access the embedded files more efficiently than the files in Merge Modules. Finally, .wixlibs provide infinitely better information than Merge Modules for patching.

Why wouldn't you use a .wixlib?

If your build isn't huge and highly parallelized and you don't share any setup logic with other WiX users then .wixlibs are probably just overhead. Also, if you need to share your setup authoring with customers who are not using the WiX toolset then you'll need to use Merge Modules not .wixlib files.

How about a bit of history?

Sure, I love to talk about the history of features. As you might guess, the history of .wixlibs starts with Merge Modules. I wrote the Merge Module spec back in 1998 when I was an intern on the Windows Installer team. The goal was to create a mechanism for developers to share setup logic and the respective files.

When I later joined Microsoft full time in 1999 and started working on WiX v1 I had the idea that Merge Modules could be used as the building blocks to create large complicated setups. To make a long story short, that design was flawed because the Module Id appended to all of the primary keys made things difficult to integrate and Merge Modules did not provide quite the right granularity for all pieces of a product.

So, in WiX v2 I introduced the concept of symbols/references, sections and library files. Unfortunately, in WiX v2 there were no binary .wixlibs so you had to distribute any referenced files along with the .wixlib. That was a pain. Derek fixed that issue in WiX v3.

One of the first big changes to WiX v3 was to add the ability for lit.exe to create "binary .wixlib" files which contained the referenced files in a cabinet file prepended to the .wixlib's XML blob. This gave us the best features of both of .wixlib files and Merge Modules, as long as you are using the WiX v3 toolset everywhere.

These days I always recommend that if you are sharing setup logic and files with people also using WiX v3, skip Merge Modules and just use binary .wixlibs.

tags: rob, mensching, wix, toolset, wixlib, merge, module