Rob Mensching Openly Uninstalled

Every once in a while I make a mistake where I know I did something wrong but cannot pinpoint the exact problem. These are the worse kind of mistakes because I don't know what I need to learn to avoid repeating the mistake. As a result I often back away from the problem even though leaving the issue un-addressed may be yet another mistake.

I made one of these mistakes on this blog back in December of 2006. Sinan Karaca from InstallAware Software Corporation asked me to blog about their new WiXAware product. At the time, I had a very negative impression of the company based on my conversations with other people. While I was impressed with Sinan's presentation and believed that WiXAware showed great promise, I allowed my negative impression to color our discussion and, later, my two blog posts.

After realizing that something had gone wrong I backed away from the whole issue and left it unresolved.

A few weeks ago, Sinan reopened the discussion and we traded emails until it became crystal clear to me what mistake I had made 18 months ago. The fundamental mistake I made was that I never gave InstallAware the opportunity to address the issues I had based my negative impression on. In the recent email discussion, Sinan explained his side of the story and I came to realize how the misunderstandings began then spiraled out of control.

I apologized to Sinan and he forwarded my apology on to the WiXAware team. If I could undo my mistake, I would. Fortunately, Sinan was good enough to reopen the dialog when he saw an opportunity and help me see clearly what I did wrong and allow me to learn from it. I immediately offered to make my apology public in an effort to bring the issue to close and Sinan accepted.

Sinan Karaca and InstallAware Software Corporation, I apologize for the attitude I had in our first meeting and follow up posting. I fully admit that I should have given you the opportunity to explain up front and address any grievances I might have had. I'm sorry.

From here I hope that InstallAware and Sinan and I can start again. I also encourage you to develop you own impression of InstallAware Software Corporation. Finally, for those of you that haven't already made this mistake, please learn from mine.

I forgot to mention last week that my blog was going to be down over the weekend. I'm on a free ISP so I don't complain when they say, "We're going to go down over the weekend to upgrade the electrical system in our building. Your email will be cached and sent when we come back up Monday."

Besides, no one reads my blog on the weekend.

A couple weeks ago I posted a blog entry that I had mentally labeled "the lead balloon experiment" even before I finished. In that entry, I asked the question, "Should consistent inflammatory remarks be ignored or is it important to address the remarks to present the other side of the issue and attempt to debate the underlying issues?" I got some great feedback and wanted to roll it up here.

First, the blog entry was a social experiment of sorts. There were several questions that I had before writing it and was curious what other people thought. Of course, my hope was to get a different perspective. As noted above, I knew the experiment might "go over like a lead balloon" since the word "troll" is highly subjective and inflammatory itself. Trust me the hypocrisy built into that blog entry was not lost on me. But I decided the risk was worth it and I'm glad I did because I learned some interesting things.

So, what did I learn (note: I'll only quote the publicly posted comments):

1. "I think it is good that you are engaging the community to find out whether more people feel that way; this is the beauty of blogging." - A very large part of the experiment was to see if I was alone in thinking the majority of the blog entries were inflammatory. Not one of the comments I received argued that I was misinterpreting the tone and should reset my expectations for civil conversation. Had the comments gone the other way, I would have posted a public apology and spent a lot of time reapplying the Teflon.

2. "My suggestion is to stick with objective facts and quit the discussion once it has deviated from that." - A number of people suggested addressing the core issue while ignoring the inflammatory remarks. This is definitely the "high road" and very possibly the right thing to do. The major issue with this tactic is that you are now, at least at some level, condoning the inflammatory remarks. Personally, I have a hard time rewarding such behavior at any level.

3. "If you blog more 'constructive content', then the trolls won't survive very long because the community will know what they say is '****hit'." - The suggestion that I just "blog more" in attempt to get my actual beliefs out there is great. Of course, that suggestion also noted that more time spent fixing bugs in WiX would be great too. <grin/> While I really do like this suggestion the balance of coding vs. blogging vs. living will continue to be challenge.

4. "FanBoy's aren't much better." - I hadn't thought about this since don't think we have any "fanboys" for the WiX toolset (seriously, does anyone love installation technologies that much?). However, I would agree with the sentiment. Don't feed the fanboys. <smile/>

5. "Remember back in the old days you'd go out on the playground and beat each other up and then become best friends?" - The more I thought about it the playground analogy seemed amazingly fitting. For everyone not involved, I can understand this whole public admonishment to be rather immature. However, I learned a very long time ago that sometimes you have to stand up for yourself. Everyone is entitled to their own opinion but that doesn't mean they are entitled to attack you or your friends personally, especially in public.

Conclusion.

I am ignoring trolls in an all out passive aggressive fashion. <smile/> I long ago stopped reading blogs from them but I have now updated my Inbox rules to better filter out email from them and I am investigating ways to not have them show up in my search queries (unfortunately, not sure Technorati completely supports this). That does mean I will run the risk of not addressing incorrect information being spread by them. So, if you ever want my perspective on a particular topic or have a question about my actual beliefs just drop me a comment or note here. I'll try to address them directly.

This stance might seem extreme to some or immature to others. I'll leave that decision up to you but let me leave you with two things:

1. In college I took a class where the only thing the professor said on most days was, "Remember, you can never take power. You can only give it away. Now discuss how power affects you in the here and now." It was a fascinating class and an incredible experience. One of the things it taught me was that you control how much "energy" you give another person. In this case, I've decided to no longer give any more energy (usually in the form of personal frustration) to individuals that exhibit, for lack of better term, troll-like behavior.

2. When the most important person in your life suggests that maybe it just isn't worth it, you listen. In this case, my wife has watched me struggle with how to interact with troll-like behavior for years. My desire to address the underlying issues without feeding the personal attacks routinely leaves me frustrated. With this latest individual, Jenny firmly suggested that it just isn't worth it. This time, I'm listening. <smile/>

Finally, I want to point out that my Inbox rules will not filter out email sent directly and only To: me. I definitely want to leave a channel open to discuss and/or reconcile previous injuries (on both sides) if the individuals want to talk. My opinions do change and I will happily admit when I am wrong when challenged with objective data and no personal attacks.

Like almost all Thursday nights, I was out with the guys writing code for the WiX toolset. Also, like almost all Thursday nights, Jenny called me before she headed off to bed. Sadly, tonight she informed me that her Zune had frozen on her walk to work this morning.

Well, I just got home after getting the last set of build system changes in and posted. I decided to take a peek and see if I could fix the ailing music player. It was definitely frozen with its screen dimmed showing one of the menus but not responding to input.

After pressing and holding a few buttons, I decided it was time to hit the Internet. In the first page, I came across this blog entry that did just the trick. Press and hold the Back button and the up on the pad for a few seconds and the Zune will reset. This fixed Jenny's Zune and it seems quite happy, connected and charging.

Reading through the comments here are a few other key combinations that you can use on your Zune:

• On - press and hold the Play button.
• Sleep - press and hold the Play button.
• Off - press and hold the Back button plus down on the pad.
• Reset - press and hold Back button plus up on the pad.
• Erase - press and hold the Back button plus up on the pad then press then hold Back button plus right on the pad plus Play button. From KB926917.
• Format - press and hold the Back button plus up on the pad then press then hold Back button plus left on the pad plus Play button. Formatting will require you to connect your Zune back to a computer for the Zune to be useable again.  From KB927001.

Someone asked recently how to use an ampersand (&) in the Product Name for their .wxs file.  Probably something like:

<Product Name="Stuff & Stuff Demo" ...

The error message itself is pretty brutal but does pinpoint (to the exact character) the problem:

stuff.wxs(3) : error CNDL0104 : Not a valid source file; detail: An error
occurred while parsing EntityName. Line 3, position 27.

The error message is coming from the XML parser (we currently don't try to trap those and print out friendlier error messages, not sure that is even possible) telling you that the the "entity" (things that start with an ampersand) name is invalid. The trick is to realize that ampersands are special characters in XML. Fortunately, this fact is pretty well documented all over the Internet. So the fix is easy:

<Product Name="Stuff &amp; Stuff Demo" ...

The follow up question was how to get an ampersand to show up in the UI. The issue is that if you have something like:

<Control Text="&amp;Print" ...

The control's text is going to look like "Print". For as long as I can remember, Windows dialogs have used used an ampersand to mark the accelerator key (or is it accessibility key?) . So hopefully it is no surprise that the Windows Installer chose to follow the same convention for their dialogs. Anyway, if you really wanted "&Print" to be the text of the control then you'd need to escape the ampersand like:

<Control Text="&amp;&amp;Print" ...

This is one of those cases where the special characters in one language (XML) also used represent special characters another language (MSI UI) end up complicating the escaping across the board. Fortunately, this doesn't happen too often (and isn't nearly as ugly as the escaping of XSL in Formatted text fields).

I just couldn't focus tonight so I went surfing for recent blog entries and web pages talking about the WiX toolset. Usually, I can search for wix and find some interesting things that either need to be fixed or documented better or sometimes a success story. Unfortunately, tonight I tripped across a troll post.

Now the conventional wisdom is that the only way to deal with a troll is to ignore it. "Do not feed the trolls" and all that. However, I've been thinking about this issue for a while and I thought I would float the question out there to see what all of you think.

First a little background then the question. The blog entry at the top of the search list tonight went something just like this:

The other day I was reading a blog where Rob Mensching was very proud that WiX installs tend to be Red instead of Blue:

"Blam! Right out of the gate I knew I was looking at a package built by WiX. How? Look at the red. All the other installation vendors out there like blue."

Well, I suppose that's better then the way I used to know that a package was built using WiX. You know..... No Dialogs At All!

Before I start let me note that the issues I raise below are minor and completely dismissible by themselves. The question to ask yourself is if these sorts issues are relatively constant do you simply ignore them all or do you look through the mild (or not so mild) inflammatory remarks and debate the underlying issue?

With that context in mind, let me enumerate the issues that I find misleading, inflammatory and interesting (yes, interesting) from the snippet of the blog above:

1. If you read my original blog entry, nowhere in it will you see that I state that I am proud that installation packages built by the WiX toolset are often red. In fact, I'm not particularly proud about the graphics in the WiX toolset. I think the graphics provided in the default WixUI are actually pretty ugly. I have asked a few times if someone with more artistic skill than me was interested in donating better graphics to the project (I personally hacked out that red bitmap from the blue one that was part of the Orca install almost 9 years ago). I picked red (9 years ago!) for the exact reason I stated in my blog entry "All the other installation vendors out there like blue." Red provided a quick indicator that you were probably looking at a WiX built package.
   
   So my first issue is that the snippet above completely misrepresents what I believe.
   
   A little bit of me wonders whether someone reading that blog entry would begin to believe that I think the default WixUI somehow sets the standard for what a beautiful looking install package should aspire to.
   
2. The second part is a backhanded criticism of the WiX toolset that links to an old blog post which suggests WiX is incorrect and inferior for allowing installation packages to be built without a UI. The blog author is entitled to his opinion that all installation packages should have a UI. However, the author chooses to use divisive language to attack the WiX toolset (i.e. "WiX is too primitive of a toolset to possibly assist the developer in authoring a decent UI experience" [ed. emphasis mine]) and me (i.e. "I suppose if you only go by one persons definition of bad"). Unfortunately, that word choice naturally puts people that are associated with the WiX toolset on the defensive (particularly, those of us that volunteer on the toolset).
   
   So my second issue is that ignoring an individual due to "troll-like" behaviors means that is not possible to rebuke incorrect statements made by that individual.
   
   In this case, the invalid statements were that the WiX toolset does nothing to assist developers with UI, there are actually a few defaults to choose from but they are all red. <smile/>
   
   Ironically, if you read through the comments in that old blog post you'll see the exact point when I realized I came to believe I was dealing with a troll and completely quit responding. You can also see how I started a bit defensive in my first comment and tried to regain my composure in the subsequent comment.
   
3. Now the part that I find interesting is that underneath all of this is what could be a very fascinating debate about the role of UI in an installation package. There are things the WiX toolset does poorly (for example, the default graphics are pretty ugly and creating custom UI by hand is tedious) but there are a couple things in WiX that might be interesting (such as the "advanced" WixUI structure). Plus the simple discussion about whether every single installation package requires UI or not could be interesting.
   
   So, finally, I am wondering if I should just ignore the inflammatory remarks and always discuss/debate on the salient points (if any).
   

The above is a dissection of a very specific and small set of events around my work on the WiX toolset in an attempt to appropriately frame the general question, "Is it better to tend to the trolls or should we just ignore them?"

I welcome your comments. I'd be especially interested in other's interactions with what you believed to be troll-like behavior, how you handled it and how that worked out.

Today I finally worked out the final issues blocking the latest release of the WiX toolset. There were several small bugs in the release batch files that just took time to run down. There is a fair bit of remaining clean up work for me to do but I am pretty sure that the worst has passed and weekly releases will be back on track.

A few people have asked me why it took five weeks to get everything working. There were two major issues that took a lot of time. Before I list those, just to remind everyone, the biggest change is that build process now builds 64-bit (both amd64 and ia64) versions of the Custom Actions. Since the beginning we we have avoided building anything 64-bit (32-bit Custom Actions on WOW can do quite a bit) but a few bugs came up that were impossible to fix without real 64-bit code. Again, Mike Carlson did the majority of the work.

The first issue that slowed the process down is that I require that at least the x86 version of WiX toolset to be built from freely available tools and SDKs from Microsoft. When the WiX toolset was first released, a number of people tried to argue that WiX was just a ploy to get developers to fork over cash for expensive versions of Visual Studio. That argument was quickly put down when it became clear that with the Windows SDK, .NET Framework SDK and free version of the VC tools you could build the WiX toolset.

Since then the WiX toolset has become more complicated. Most of the issues now come from Votive and the horribly designed VSIP SDK required to build Votive. There are actually tasks in the Votive build process that write registry keys so that a required VSIP build task operates correctly. The 64-bit builds have introduced new complications because you need both VS C++ and the Windows SDK installed to get all of the necessary tools and headers/libraries to successfully build. It took Mike a fair bit of time and a number of different machine configurations to track that one down.

The second issue came down to time, my time. Once 64-bit builds were checked in, it was my task to work through the release implications. Unfortunately, I was buried by day job pressures and then got sick. I finally had time to focus for a few hours last Thursday night and another couple hours this morning to fix the last few problems I hadn't flushed out.

And now I have time with less pressure. So I am focusing on reducing the release process with the hope that improvements there will reduce the bottleneck on me. Releasing WiX v2 and WiX v3 with their now disjoint and thus doubly-expansive set of dependencies hasn't been something I've kept up well. Unsurprisingly not maintaining the dependencies came back to bite me these last few weeks.

Again I apologize for the delay and thank you for your patience. If you see any problems, please do open bugs on SourceForge.

I couldn't sleep tonight so I thought I'd just poke around online for a while. It turned out to be impossible to miss the fact that the Google App Engine was released tonight. We knew about this a little while ago but now we know it's name.

The SDK itself is pretty cool. They've done a nice job bundling up all their services in nice little downloadable package except they left out the Python runtime (and are afflicted by the Windows Installer's lack of hyperlink control in their launch condition). In any case, it has been a quite a while since a new technology announcement really got me to kick back and think about how I personally could use it. I was starting to dig into Ruby a bit but maybe I will switch over to Python now. ASP.NET is beginning to drive me bonkers and The Django Book seems like a really nice read.

Anyway, after watching the launch videos I noticed that Bob had sent around an email saying thus, "The Google App Engine SDK for Windows is delivered as an MSI built with WiX (v3.0.3907, even) and Heat." I hadn't downloaded the package at that point but bounced on over, downloaded and kicked off the install.

Blam! Right out of the gate I knew I was looking at a package built by WiX.  How?  Look at the red. All the other installation vendors out there like blue. As Bob noted, it looks like Google even used the latest weekly release for WiX v3.

Now, unlike Google's previous attempt at using the WiX toolset, this looks like a pretty clean package. There is only one ICE message, a warning: C:\Users\robmen\Downloads\GoogleAppEngine.msi : warning SMOK1076 : ICE47: Feature 'ProductFeature' has 940 components. This could cause problems on Win9X systems. You should try to have fewer than 817 components per feature.

Win9X probably isn't something I'd worry about either although it does point to one of the troubles with creating one Component per Resource. There are also only two non-standard CustomActions that open the README.txt and launch the default browser. Both completely reasonable things to do (bonus points for using the default browser).

In the end, as I noted in the beginning, it looks like they've done a nice job bundling up all their services. I'll leave you with one observation that I found kinda' funny. There are 938 rows in the MsiFileHash table.  There are an equal number of rows in the File table. That means there are no executable files in this package. Obsolete skills indeed.

Today, four years ago the WiX toolset was released as the first Open Source project from Microsoft. Each year I like to take a moment and look around to see where we are. Just this week, I've found two random blog entries that make me believe we're being successful.

Over the years I've slowly distilled the vision of the WiX toolset into a single sentence.  "The WiX toolset enables all developers to create high quality Windows installation packages by providing tools that integrate seamlessly into the development process."

I described the philosophy underlying that vision about a month after the WiX toolset's public release. There are three parts. First, the developer that wrote the feature knows best what needs to be authored into setup. Second, setup authoring is a part of the development process. Third, text files should be the only inputs into the build process.

The first blog entry that I found at the beginning of the week aligns with the third part of the philosophy. The title of the blog entry is The Power of Text Files. Beyond the obvious agreement that "the best medium for code is a text file," I found the fact that the author had just recently tried the WiX toolset interesting for two reasons. First, it reminds me that there are a great many people that we haven't yet reached. Second, that the WiX toolset has generated enough interest that it is on developer's "to try out" list. Both of those observations mean we still have work to do on the WiX toolset.

The second blog entry was a discussion about a talk at VSLive! San Francisco, titled: Multiply your team's voltage by working in parallel. This blog entry speaks directly to the second part of the philosophy and touches on the first part when mentions: "Code holds code artifacts - C#, VB, SQL, WiX, etc.". Notice that the WiX code (.wxs files) is called out as a peer of the C# code, the VB code, the SQL code. It is incredibly encouraging to see the setup coding not be relegated to the "etc. bucket" and actually called out as a first class citizen in the development process.

Another exciting development in the WiX toolset is the infusion of a lot of attention by Visual Studio developers. There have been other commercial development on top of the WiX toolset but Visual Studio is the first "company" (for lack of a better term) to actively fund development that improves the core toolset. What I find most impressive is that the Visual Studio team is taking on the "boring" and "dirty" work of integrating 64-bit builds, tackling FxCop issues, building testing infrastructure and just flat out fixing bugs. The WiX toolset (Votive, in particular) is much more solid thanks to their efforts and they aren't done yet. <smile/>

Finally, I want to recognize Bob Arnson and Peter Marcu for their dedication to the WiX toolset over the last year. Anyone that hangs out on the wix-users mailing lists knows who Bob is, he fields an incredible number of questions. But what you don't often see is how much I depend on both Bob and Peter as a reliable and educated sounding board for new ideas and large decisions. Peter did an incredible job integrating all of the knowledge about patching spread across Microsoft into the new patching tool in WiX v3 called pyro.

Over the last four years or so, Bob's and Peter's role in the WiX toolset has steadily increased and this last year they have really demonstrated solid leadership skills. With my April Fool's joke this year, some people asked the question about what would happen to the WiX toolset if I stopped working on it. With Bob and Peter available there is no doubt in my mind that everything would continue just fine.

It has been a fantastic year and I look forward to next year where I expect we will all be enjoying an incredibly stable and feature rich WiX v3. And don't worry, I've already started looking out at what's next. <grin/>

A head cold is totally wiping me out right now but I wanted to post a few quick notes about progress on the WiX toolset.

1.  64-bit builds. If you watch the weekly releases then you've noticed that there hasn't been a release in the last few weeks. The primary cause for the disruption is that Mike Carlson (a developer on the Visual Studio team) has been revamping our build system to build x86, x64 and ia64 builds of the WiX toolset. This ended up being a large undertaking because he needed to move the WiX toolset to the Visual Studio 2008 headers and libs.

2. Visual Studio 2008. Since the 64-bit builds will need VS 2008 headers and libs, Peter Marcu is updating the solution files to build with VS 2008. The hope is that this will simplify some of the requirements to build the WiX toolset. Additionally, VS 2008 seems to simply perform better than VS 2005 so maybe we'll get some development benefit there as well.

3. FxCop compliance. Jason Ginchereau and Muhammad Ghaznawi (two more Visual Studio developers) have been plowing through the backlog of FxCop issues in all of the WiX toolset. Along the way they've also been moving a number of strings to resource files so that every part of the WiX toolset (not just the standard UI dialogs) will be able to be localized.

These efforts have resulted in sweeping changes across the whole code base. As a result, we've just held off on the builds for a bit while Mike stabilized his build system changes. I expect that when we all get together again next Thursday that the final issues will be worked out and builds will be back on a regular weekly schedule.

Thanks for the patience.