Major upgrades now easier than ever

I’m a fan of major upgrades, which I’ve written about before. For 10 lines of XML, you get free and easy upgrades without having to deal with the costs of patching and minor upgrades:

<!– Major upgrade –>
<Upgrade Id="$(var.UpgradeCode)">
    <UpgradeVersion Minimum="$(var.ProductVersion)" OnlyDetect="yes" Property="NEWERVERSIONDETECTED" />
    <UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED" />
</Upgrade>

<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallValidate" />
</InstallExecuteSequence>

<Condition Message="!(loc.NewerVersionDetected)">
    NOT NEWERVERSIONDETECTED
</Condition>

Easy enough to cut and paste but it isn’t exactly what I would call expressive—the intent behind the code isn’t obvious, though it can be deduced fairly easily.

WiX can do better.

So, like the last time I tweaked the WiX language, it’s time for a new feature: The MajorUpgrade element encapsulates the most common options for major upgrades and creates the appropriate rows in the Upgrade and LaunchCondition tables and provides a simpler way of specifying the scheduling of the RemoveExistingProducts action. For example, here’s the simplest use:

<MajorUpgrade DowngradeErrorMessage="Can’t downgrade." />

Downgrades are blocked by default, which requires you to specify a message for the launch condition message.

MajorUpgrade is a child of the Product element and automatically picks up the UpgradeCode attribute from its parent. That avoids the common duplication of the upgrade code in the Upgrade element.

MajorUpgrade has the following attributes:

AllowDowngrades Downgrades are blocked by default.
DowngradeErrorMessage The launch condition message displayed when a downgrade is detected.
IgnoreRemoveFailure Uninstall failures are upgrade failures by default.
MigrateFeatures Manual control over the features installed in the newer product.
RemoveFeatures Manual control over the features removed from the older product.
Schedule When to schedule the RemoveExistingProducts action.

For details, see the MajorUpgrade element documentation. The feature ships in WiX v3.5.1315.0 and later.

Simplifying WiX component authoring

In the latest in the ongoing series of simplifying the WiX language, I recently added two new defaults to the WiX compiler:

  • The Component/@Guid attribute value defaults to “*” so that if you don’t specify it, WiX generates a stable component GUID at link time. Generated component GUIDs are available as long as your component:
    • Does not contain an ODBCDataSource element. (ODBwhat?)
    • Has only one file.
    • Has only registry values.
  • The Component/@Id attribute value defaults to the id of the keypath resource. The component itself cannot be the keypath for this to work (obviously, there’s no id for it to default to).

These changes will appear in the first weekly release of WiX v3.5 in 2010.

Combine the two features and a single-file component can now be as simple as:

<Component>
  <File Source=”foo.exe” />
</Component>

In this case, the component’s id will be “foo.exe” because the File element’s default for its Id is the filename portion of the Source attribute. Call it hygenic double-dip defaulting.

A multi-file component isn’t suitable for generated GUIDs, so it requires an explicit GUID but can still take advantage of default component ids:

<Component Guid=”{A5B56773-5E26-4C5F-AC51-C2470C3658AF}”>
  <File Source=”foo.dll” />
  <File Source=”bar.dll” />
  <File Source=”bob.exe” KeyPath=”yes” />
</Component>

In this case, the component’s id will be “bob.exe” from the keypath File element’s default Id. Note that unless you use the generated GUID default and live within its rules, you must specify an explicit KeyPath attribute value of “yes” on the resource whose id you want to be the component id.

We can’t eliminate the dread component rules but we can make it simpler to live within them.

WiX v3.5 supports Visual Studio 2010 beta 2

So that the WiX Working Group can enjoy Hallowe’en on Saturday, WiX v3.5.1030.0 with support for Visual Studio 2010 beta 2 was released today. You can get the bits at http://wix.sourceforge.net/releases/3.5.1030.0/. This isn’t a full beta release – Burn is still in active development and isn’t ready for prime-time use yet – but we want to support everyone using the beta 2 release of Visual Studio 2010, which shipped last week.

Candy, Visual Studio program manager and WiX Working Group babysitter/cat-herder, had this to say about the features in this release:

Visual Studio 2010 Beta shipped on 10/21. With the team’s hard work and agility, we were able to release the WiX support on VS2010 Beta 2 today! Here are some highlights for this release:

  • Extension Manager Integration – Now you can download and install WiX directly from within the VS IDE by launching Extension Manager
  • Major performance improvement during project building – No more IDE freezing during build
  • Automatic upgrade from VS2008 to VS2010 – no more manual editing of wixproj files to change the tools version
  • Improved IDE experience including drag/drop of nodes, copy/paste of items, and project references
  • Added Visual Studio 2010 Express products detection in the WiX VS Extension – New in Beta
  • Over 40 + bug fixes

I’m pleased we were able to get a release supporting beta 2 out so quickly and I’m very excited about the “no more IDE freezing during build” improvement. There are several other smaller enhancements that will make WiX v3.5 a no-brainer upgrade when it ships next year.

In the meantime, if you’re using Visual Studio 2010, please grab this build and be on the lookout for future weekly releases. Problems, questions? Send mail to wix-users, file bug reports, or submit feature requests.

Thrilling tales of deployment

One of my requirements when researching places to live when I moved to Boston was nearby public transit. If you’ve ever driven in Boston, you know the traffic can be dense and intense and WTF?! THERE ARE 80 CARS BEHIND YOU AND IT’S ILLEGAL TO TURN LEFT THERE DURING RUSH HOUR!!

OK, so driving was not in the picture for my daily commute to the Fortress of NERDitude. Currently, my daily commute takes about half an hour of waiting for a bus or a train and sitting/standing while someone else does the driving. Doing nothing is much more relaxing than driving in Cambridge traffic, of course, but even with good music, doing nothing gets boring pretty quickly.

I could just bring along my trusty Nintendo DS but I figured that would get boring eventually too. Plus, I figured I could be a bit more mature than that and do something, I dunno, productive like read mail or blogs…

I considered just browsing the Web on my phone, but rejected that idea:

  • Web latency over 3G networks is painful.
  • 3G networks aren’t terribly reliable underground.
  • Web UIs are painful on small screens.

A laptop or even UMPC is out, because I knew I’d frequently need to work one-handed, keeping the other handy for not falling over during the less-than-smooth parts of the Red Line.

No, I needed a small, handheld device that could sync mail and blogs and let me read them offline.

No, it’s not an iPhone

After some research, I bought an iPod touch. (Perhaps in a couple of weeks, my implant will kick in and I’ll do this all again on a Zune HD.) I also bought Phantom Fish’s Byline RSS reader, which syncs to Google Reader. Once I supplied my account name and password, reading blogs using Byline is easy:

  • Tap the sync button to download the latest blog posts.
  • Read posts and mark some for later follow-up once I’m back online.
  • Before heading home, sync to update Google Reader with the posts I read and to download the latest blog posts.
  • Once I’m back in range of my home WiFi, sync again.

Please, sir, may I have some more?

Buying apps from Apple’s App Store is simple; the hardest part is typing a strong password into the on-screen keyboard:

  • Start the App Store app.
  • Search or browse for an app.
  • Tap the price and it turns into a BUY NOW button.
  • Tap BUY NOW.
  • Enter your iTunes password.
  • The app is downloaded and installed.

Updates are handled in much the same way:

  • Start the App Store app.
  • Tap the Updates button.
  • If there are any updates, tap the Update All button to download and install the updates in the background.

Because I have an iPod touch instead of iPhone, all my interaction with the App Store happens over WiFi at respectable speeds. (Even better, it doesn’t require interaction with iTunes, which continues to amply demonstrate that Apple has yet to master setup development on Windows.)

I’ve purchased many apps since buying my iPod touch and “purchased” many more free apps. In all cases, downloading and installing those apps was painless.

Knew you’d get to installation eventually

Well, yeah. Here are my takeaways; yours might differ:

  • Mobile != connected. Even though 3G coverage is decent from the major carriers, there will always be dead zones, slow zones, and underground zones.
  • Rich clients + local processing power == goodness. Sure, Web 2.0 and HTML5 will finally kill the idea of running local apps. Bah. Latency, especially problematic with 3G networks, kills the user experience (see, for example, About Face and other UX books). Rich clients can largely avoid the problem.
  • Sync data that lives in the cloud. If your data lives in the cloud, rich clients can sync it, keeping multiple devices up to date. In my case, I prefer to use a laptop or desktop PC to read blogs and mail when I can because, not surprisingly, a big screen is better for reading (or scanning) lots of text.
  • Bulletproof installations rock. Would anyone disagree it’s better to have bullet-ridden installation?
  • Making it easy to buy apps makes it easy to make money. The App Store had “over 1 billion downloads in just nine months” and “1.5 billion in First Year.” Naturally, with so many free and almost-free apps in the App Store, it doesn’t necessarily follow that we’re talking about a lot of money, depending on your definition of “a lot,” as estimates put the revenue at $2.4 billion a year. But imagine extending the App Store experience to more expensive apps, say on your PC.
  • Making it easy to service apps makes it easy to keep customers happy. Servicing deliverables themselves aren’t too hard to get right but making users aware of them and getting them to the user still is. It’s led to way too many auto-start local-system updater services one vulnerability away from total system p0wnage.

Best of both worlds

One of the big reasons Web apps became so popular, for both consumers and the enterprise, is that they don’t suffer from the reliability problems common to installing client apps. Naturally, these aren’t inherent problems with client app installation but are complexities that easily turn into problems—especially without engineering attention to setup.

Web apps avoid the problem by not installing on the client. (Note that I’m skipping the complexities of setting up Web servers and the pseudo-installation provided by Silverlight and Flash.)

iPhone/iPod touch apps avoid the problem by:

  • Working in a limited number of well-known environments. (Though the iPhone 3GS adds a second hardware base and there are many rumors about a so-called “Apple tablet.”)
  • Working in a locked-down environment.
  • Requiring a particular deployment model.
  • Supporting a simple update model.
  • Requiring review and approval before getting published.

These might seem pretty limiting to most Windows developers. But it’s hard to argue against the success the App Store has achieved because of—probably not in spite of—those limitations.

Security update for Visual Studio

Last Tuesday, Microsoft released atypical, out-of-band security updates for vulnerabilities in ATL. Michael Howard discusses them on the Security Development Lifecycle blog. The security update page contains links to patches and upgrades for affected Visual Studio components, going back to Visual Studio .NET 2003. If you’re using Visual Studio 2008 SP1, you’ll be interested in the following:

I’m downloading this once and sharing it on my network rather than downloading it from Microsoft Update n times.