Goodbye and hello again

This week was my last at Microsoft. After six and a half years, I decided it was time to resign from the collective and seek out new opportunities.

What opportunities? Well, I have a few things in the works but for now here’s a vague Q&A using an icosahedral decision-making device:

Q Are you resigning from the WiX community as well?
A My sources say no.

Q Are you going to work for a Microsoft competitor?
A Don’t count on it.

Q Will you be available for consulting?
A You may rely on it.

Q Are you going to write a WiX book?
A Signs point to yes.

Q More than one WiX book?
A Outlook good.

Q Will you develop additional tools, custom actions, or extensions for WiX?
A Most likely.

Q Will you contribute them to the WiX project?
A Concentrate and ask again.

Q Will they all be available as open-source?
A Ask again later.

Stay tuned for details.

In closing, I’d like to thank Rob for creating WiX, doing the work to make it Microsoft’s first open-source project, and giving me an opportunity to contribute these past six-plus years. It’s safe to say it kept me moderately sane on more than one occasion. I got to know the original batch of core WiX developers and help the “next generation” come in. Along the way, I learned a lot, mostly (but not exclusively) about development, WiX, and MSI.

WiX was first released publicly a few months before I joined Microsoft and I was immediately intrigued. Then I joined Microsoft and helped ship WiX v2.0, v3.0, and v3.5. Now I’ve come back full circle, on the outside eagerly awaiting v3.6 and the opportunities it brings.

Tactical directory nukes

Though I’ve commented before about unnecessarily “nuking” whole registry keys, sometimes it’s what’s needed. The same applies to the file system: Sometimes apps create files and directories that weren’t part of the original installation. MSI makes it easy to remove files, including via wildcard. Individual directories can also be removed, but MSI doesn’t have support for wildcard directories or recursive directory trees. It’s easy to delete trees via custom action but tougher to do so while also handling rollback.

Thanks to Rob’s work on wixcontrib, the code to handling directory nuking was available. I took it with some improvements into WixUtilExtension in WiX v3.6 and it’s available with today’s build: 3.6.1321.0.

Use the RemoveFolderEx element as a child of a Component:

<Component …>
<util:RemoveFolderEx On=”uninstall” Property=”MyDirtyDirectory” />
</Component>

There is one annoying restriction: RemoveFolderEx cannot be used directly on a directory defined in your installer. It’s an annoying chicken/egg problem. As adding directories and files to be deleted affects MSI’s file costing, RemoveFolderEx has to do its thing before costing. Unfortunately, MSI doesn’t set up properties for target directories until after costing is complete.

According to a poll both unscientific and informal, the most common use case is that the directory path is already written to a registry value anyway, for use by the installed application. See Rob’s blog post The WiX toolset’s “Remember Property” pattern for an example. As the AppSearch standard action sets the property well before costing begins, RemoveFolderEx works.

Quick implementation note: RemoveFolderEx works by recursing from the specified directory, adding temporary rows to the RemoveFile table for each subdirectory, one for the directory and one for the files in each directory. This is the pattern I described as “semi-custom actions” way back in 2007.

WiX v3.5 escrow build released, redux

A couple of important but low-risk bugs cropped up since the original WiX v3.5 escrow build was released. So, one last escrow build of WiX v3.5 in 2010: v3.5.2430.0. A quirk of publishing the build omitted the changes since the prior build in the RSS feed:

  • RobMen: SFBUG:3139522 – add MakeSfxCA.exe.config to binaries.zip file.
  • BobArnso: SFFeature:3130590 – Update DifxApp DLLs in DifxApp .wixlibs to version shipped in DDK 7600.16385.1.
  • EricStJ: SFBUG:3147256 Votive 2005/2008 corrupts binary files in templates

Download, install, and let us know how if it’s ready to ship!

WiX v3.5 escrow build released

An escrow build is one that’s final until proven otherwise. In this case, we think WiX v3.5 is ready to go. You can help prove otherwise: Download it, try it out, and file bugs if you find problems. As Rob points out, not all bugs are created equal; a bug has to be severe enough to justify resetting escrow–a four-to-six week delay in the final v3.5 release. WiX v3.6 is still in active development, so bugs that don’t get fixed in v3.5 could still get fixed there.

Personally, I hope v3.5.2325.0 is the final release: 2325 is the number of one of the vital RFCs that make the Internet work.