RobMensching.com /Blog
when setup isn't just xcopy

WiX toolset bug count after January 29th, 2009.

We had quite a bug bounce this week. Most of the bugs were regressions from the last couple weeks of major work plus some triage by Bob and Candy through Votive bugs. Yet somehow we still managed to finish the night with a lower bug count than last week.

Again, kudos go to Mike for getting us back to 0 extension bugs. WiX v2 never had 0 extension bugs. Also, great effort on killing heat bugs tonight. I expect next week we’ll just have a couple left for Jason when he gets back from his vacation. <smile/>

Sadly we’ve had a couple bugs show up in candle (bugs in the core toolset always make me sad). However, one fix is underway and have a query out to the Windows Installer team about the second (AppSearch documentation is painful). We did get an answer back on the final light bug so we’ll be able to make progress there finally.

 

 

WiX toolset is out of beta not in it.

There was some confusion on December 5th when Bob provided highlights for the WiX toolset "beta exit" build. I saw a number of people declaring the WiX toolset finally "in beta". That's not quite right. The WiX toolset was in beta for all of last year as we worked through the feature set and quality bar. As 2008 came to a close it felt like WiX v3 was a solid improvement over WiX v2 and the quality markedly improved.

Now the WiX toolset is in "release candidate" mode. Release candidate is a term made up at Microsoft to describe software that is accepting fewer and fewer changes. I think it is easiest to define release candidate in contrast to beta. During the beta period you are looking for feedback on feature set and overall completeness of the software. During the release candidate period you are fixing bugs to finish the software project.

Finishing is an important and often difficult process in software. Each change you make has the ability to break already working functionality or expose even less desirable behavior. At some point in time you have to choose to fix bugs in the next release and declare this one done.

That's what we are starting to do with the WiX toolset now. Adding MSI 5.0 support to WiX was completed later than we would have liked but we were dependent on the release of the new MSI SDK. Similarly the Visual Studio team has promised support for Votive in the next version of Visual Studio and that functionality will be coming in late.

However, we are going to start punting bugs to the next version of the WiX toolset. Remember the WiX toolset is not in beta any more. We are on the glide path to shipping.

 

WiX toolset supports MSI 5.0.

Two weekends ago, Windows 7 beta builds were made available. That meant the new MSI SDK was available on MSDN with all the information about what's new in MSI 5.0. In turn, that meant we had some work to do to teach the WiX toolset some new tricks.

Bob and I split the work up last Wednesday. He took the "UI work" and I took the "server work". After a couple nights of coding (interrupted by all the other things we get interrupted by) we had all of the functionality designed, built, debugged and posted to SourceForge in the latest WiX toolset release. I'll talk about the features I implemented in detail later but Bob has a nice overview of the changes on his blog..

Staying current with the Windows Installer changes is important to those of us that work on the WiX toolset. That is why we work hard to get the changes in as quickly as possible. In addition to staying current, we also help flush out bugs for the Windows Installer team. I think Bob and I have reported six bugs (mostly documentation issues) so far. Those of you that pick up these builds will help further validate both the WiX toolset and Windows Installer 5.0.

So keep coding, you know I am.

 

First bug fixed in RobMensching.Blog.

I just fixed the first bug in my new RobMensching.Blog engine. When I finally got around to running the engine's new feed through the Feed Validator. I had tested subscribing to the feed with IE's built in feed rendering as well RSS Bandit and Live Writer. But, of course, the Feed Validator found two more issues.

1. feed/@uri - I had incorrectly named this attribute "url". Typical mistake. I wish "i" and "l" were more distinguishable (not that I would have noticed anyway <grin/>).
2. feed/entry/@id - turns out an ATOM entry id is supposed to be full URI. That makes sense for the case where an entry floats alone.

Unfortunately, this bug means that once again, those of you that subscribe to the feed are going to see a bunch of duplicates. I'm sorry. The only upside is that I think it won't happen again.