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

Posted by
Rob Mensching
Friday, April 25, 2008 4:05 AM

How to fix a frozen Zune and other interesting tips.

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:

Zunes at Microsoft Store
  • 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.

 

Update 2008-12-31: Microsoft announced that there are start up problems with any Zune 30s purchased in 2006. The Zune team has identified the problem as a bug in the Zune's clock not handling the leap year correctly. Your Zune will fix itself after noon tomorrow. All you need to do is let the battery run all the way down and wait until after noon January 1st, 2009.

Have a happy New Year (when the Zune 30 music will play again)!

 


Posted by
Rob Mensching
Monday, April 21, 2008 9:50 AM

How to escape the ampersand in WiX and MSI UI.

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

 


Posted by
Rob Mensching
Friday, April 18, 2008 2:56 AM

Tend to the Trolls or just ignore them?

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.

 


Posted by
Rob Mensching
Monday, April 14, 2008 7:00 PM

WiX v3 releases back on track.

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.

 


Before