On joining FireGiant

I’m beyond excited to announce that I’ve joined FireGiant. Rob, CEO and co-founder of FireGiant, has known me for more than 10 years—plenty of time to get to know my strengths, my motivations, and my amusing quirks (what others might call peculiarities).

So when he appeals to all three by offering me a job where wearing pants is optional, how could I refuse?

(Note 1: I don’t mean to imply that Rob opened by mentioning the no-pants thing. I mean, it would’ve been perfect if he had, but I want the record to be clear.)

(Note 2: It’s likely that pants are optional only because FireGiant is a distributed company—unannounced drop-ins are unlikely. And as long as I keep my webcam pointed in the right direction, nobody’s going to know anyway.)

I’ll be working on FireGiant’s service offerings like support and custom development. Other things are on tap and I look forward to talking about them when the time is right.

Changes to my work on WiX

On the one hand, there are none.

I’ll continue to act as the release manager for WiX v3.10 and any other future releases we do in the v3.x series. I’ll keep participating in the WiX online meetings, wix-users and wix-devs threads, and even StackOverflow.

I’ll also continue to contribute bug fixes and features to WiX, just like I’ve been doing for the past 10 years.

10 years.

Wow.

Where was I? Oh yeah…On the other hand, however, being part of FireGiant will have numerous benefits for my work on WiX.

Most of my best (in my humble opinion) contributions to WiX came from my day-to-day work using WiX and finding a need that was best solved inside the WiX toolset. For example, while working on Flight Simulator, I needed firewall exceptions and while working on App-V, I wanted to simplify major upgrade authoring.

Day-to-day exposure to those kinds of problems makes me a better WiX contributor and a better project leader. I’m looking forward to getting more of that exposure than I’ve gotten in my own consulting and freelancing since resigning from Microsoft four years ago. (Really? Four? Time flies and all that.)

One size fits all

I’m excited to join FireGiant not only because FireGiant is a great fit for me and not only because I’m a great fit for FireGiant—I mean, really, who wouldn’t want me to be on call as their own personal WiX expert?!—but also because I believe FireGiant is a great fit for WiX.

For 10 years, I’ve loved being part of a small team of volunteers working on WiX. And I recognize that for WiX to keep growing, to be viable in any organization regardless of spot or lack thereof on the Fortune 500, some people need to be able to rely on a guarantee of support. FireGiant provides that and I’m thrilled to support WiX in that way too.

WiX v3.10 version twist

After a brief hiatus for releasing WiX v3.9 R2, weekly builds for WiX v3.10 have resumed. WiX v3.10.0.1403 is now available — and you might have noticed an oddity in the version number.

When we started discussing the need to ship a maintenance release for WiX v3.9, we realized that we had no way to easily differentiate a maintenance release from the original “final” release — or any other pre-release build, for that matter.

Traditionally, WiX version numbers have been based on using three fields: major.minor.build. You likely know why: Because Windows Installer uses three version fields and ignores the fourth. Unfortunately, when you want to keep using major.minor versioning, that leaves only one field to identify a particular build.

So we decided to switch things around a bit. We’re now versioning the WiX bundle as major.minor.release.build. The release value is currently zero and will stay that way until/unless we ship a maintenance release. For example, WiX v3.10 RTM might be v3.10.0.2010 and a theoretical WiX v3.10 SP1 might be v3.10.1.2323.

The MSI packages in the WiX bundle continue to be versioned as major.minor.build.0, so that major upgrades keep working. The same is true of WiX executables. That means that, for example, Candle.exe from the aforementioned theoretical WiX v3.10 SP1 would have a version of v3.10.2323.0.

I’d rather all the versions — bundle, MSIs, and executables — have the same version number but tagging the bundle with release information is important enough to make this change.

Consequences

Unfortunately, the new versioning scheme means that new builds of WiX v3.10 are always seen as “less than” any of the already-released WiX v3.10 builds with the old numbering. That means that if you have v3.10.1124.0 installed, for example, v3.10.0.1403 will not be seen as an upgrade. The WiX BA blocks downgrades by hiding the big Install button:

WixNoDowngradeThe workaround is to uninstall any other build of WiX v3.10. Then v3.10.0.1403 will install normally.

WiX Toolset v3.9 R2 maintenance release is available

WiX Toolset v3.9 R2 is a maintenance release of WiX v3.9 that fixes several serious bugs:

  • Bug 4600 | VSExtension Help custom action binaries are corrupt.
  • Bug 4608 | Multiple prerequisites return failure, when 1st prerequisite is already installed and 2nd prerequisite is installed successfully.
  • Bug 4609 | Bug in BVariantCopy() in src/burn/engine/variant.cpp

Thanks to @rseanhall and @firegiantco for fixing these bugs.

WiX Toolset v3.9 R2 is v3.9.1208.0 and is available from Codeplex.

 

WiX v3.10 begins and is already mostly done

The first interim build of WiX v3.10 has been released: WiX v3.10.1124.0 from wixtoolset.org. It includes support for integrating Votive into Visual Studio 2015 Preview and native and managed libraries for VS2015.

And that’s most of what we intend to accomplish with WiX v3.10. We will — of course! — fix bugs and add some small features in WiX v3.10 but the focus is on supporting Visual Studio 2015 and, if necessary, Windows 10. Rather than filling the available schedule with work, the goal is to finish the planned work quickly and be ready to ship WiX v3.10 as soon as possible after Visual Studio 2015 ships.

To do that, WiX v3.10 won’t include any large new features, to reduce the risk of long bug tails. We’ll release milestone builds around new milestone builds of VS2015 to make sure changes in VS2015 are reflected in WiX v3.10. Bug fixes and small features are welcome and a few are already queued up in pull requests on GitHub. More are welcome! Let’s talk on wix-devs.

WiX v3.9 released

Update: WiX v3.9 R2 has been released.

WiX v3.9 was officially released on Hallowe’en 2014. The release build is the same as RC4: v3.9.1006.0. Download the release here.

For Rob’s take, see his blog post.

The following people contributed to WiX v3.9 over the 11 months since WiX v3.8 was released:

It’s great to see the list of contributors growing release after release!

The major features of WiX v3.9 are:

  • @rseanhall lets you run a post-install configuration tool that requires elevated priveleges after a bundle is installed. WIP / Bug  / Pull request
  • @jchoover added update detection to the Burn engine. Bug / Pull request
  • @rseanhall added support for multiple managed-BA pre-requisite packages. WIP / Bug / Pull request
  • @rseanhall added support for secure string variables in Burn. WIP / Bug / Pull request

Minor features include:

  • @jchoover updated the WiX installer to use the new update feature. Pull request
  • @heaths added the Windows “Threshold” compatibility GUID to Burn. Pull request
  • @FernandoNunes contributed localizations for Portuguese for WixSqlExtension. Pull request
  • @robmen updated the WiX release feed for the update functionality in the WiX installer. Bug / Pull request
  • @barnson changed the WiX installer to install the native-code WiX SDK for Visual Studio Express editions. Pull request
  • @robmen marked deprecated command-line switches that are removed from WiX v4.0. Bug / Pull request / Pull request
  • @barnson added a verbose message that reveals how much time was spent running ICE validation. Pull request
  • @barnson made a few updates that made the WiX build faster on many-core machines. Pull request / Pull request
  • @heaths added support for temporary object columns in DTF. Pull request
  • @flcdrg added support in DTF custom action builds to include COM interop reference assemblies. Pull request
  • @heaths added support for Visual Studio “Dev14″ in WixVSExtension detection properties. Pull request
  • @heaths added support for user creation in WixUtilExtension to be non-vital (i.e., fail without causing rolling back). Bug / Pull request
  • @rseanhall added a blocker to prevent .NET 4.5.2 from being used as a pre-req package on Windows 7 RTM because .NET 4.5.2 requires Windows 7 SP1. Bug / Pull request
  • @heaths added policy support to move the Burn package cache to a non-default folder. Bug / Pull request
  • @rseanhall added the WixBundleExecutePackageCacheFolder bundle variable. Bug / Pull request
  • @robmen defaulted Burn to using hashes to verify payloads rather than digital signature. Bug / Pull request
  • @barnson added the ProcessorArchitecture, WixBundleOriginalSourceFolder, and WixBundleFileVersion bundle variables. Bug / Bug / Pull request / Pull request / Pull request / Pull request
  • @gordonmcshane added .NET 4.5.2 package groups to WixNetFxExtension. Pull request
  • @johnbuuck added support for MSBuild v12.0 in project harvesting. Bug / Pull request
  • @rseanhall added the @Cache=”always” value to force a bundle’s package to be cached even if the package won’t be installed. Bug / Bug / Pull request
  • @heaths added a number of features and fixes to better support ref-counting and patching in Burn. Bug / Bug / Pull request / Pull request
  • @mavxg added User/@LogonAsBatchJob to WixUtilExtension. Pull request
  • @barnson added the -sextract switch to Melt.exe to not extract MSI package payloads but still update the .wixpdb. / BugPull request

Fixes include:

  • @robmen fixed a long-standing bug in WixStdBA that caused a hang when installing as local system on Windows Vista and Server 2008. Bug / Pull request
  • @robmen fixed a bug dating from WiX v2.0(!) that caused bad modularization when keywords like OR were part of property names. Bug / Pull request
  • @rseanhall fixed a nitty-gritty bug in DTF tools that created custom action DLLs that didn’t exactly follow an arcane spec. Bug / Pull request
  • @barnson fixed a bug in Burn that caused command lines to replicate like gray goo when a BA called Plan multiple times. Bug / Pull request
  • @rseanhall added a missing extension to the binaries .zip.
    Pull request
  • @rseanhall made sure that that a bundle’s bootstrapper application is the first payload in the UX container so Burn doesn’t try to execute an arbitrary file. Bug / Pull request
  • @jchoover tweaked the WiX installer to skip checking for updates when it doesn’t make sense. Bug / Bug / Pull request
  • @barnson fixed Burn so it resumes after rebooting. Bug / Pull request
  • @barnson fixed Burn so it didn’t ignore a rollback of a related bundle. Bug / Pull request
  • @jchoover fixed some memory leaks in Burn. Also fixed some memory leaks in Burn. Pull request
  • @barnson fixed DTF so that it doesn’t exclusively lock icons when reading them. Bug / Pull request
  • @barnson solved the case of the mysteriously missing native-code SDK files. Bug / Bug / Pull request / Pull request
  • @barnson fixed Wix.sln by removing an obsolete file. Bug / Pull request
  • @rseanhall made sure Burn cleans up a downloaded update when appropriate. Bug / Pull request
  • @barnson made sure the WiX installer doesn’t crash when you don’t have a browser installed that knows about .html files. Bug / Pull request
  • @barnson added a warning to the doc about a limitation with PerfCounterManifest. Bug / Pull request
  • @rseanhall ensured that you can use LaunchTarget without LaunchArguments. Bug / Pull request
  • @rseanhall changed DTF so it sets the working directory for a custom action. Bug / Pull request
  • @rseanhall decided that Burn should decrypt files coming from an encrypted folder. Bug / Pull request
  • @heaths converted, enhanced, and cleaned up some duplication in the WiX tests. Pull request / Pull request / Pull request / Pull request
  • @heaths let you have an unreal table with way too many columns. Bug / Pull request
  • @heaths optimized away the repair of dependent bundles of uninstalling a bundle is a no-op. Bug / Pull request
  • @heaths showed progress in Burn when waiting on BITS to download. Bug / Pull request
  • @heaths supported long command lines after rebooting in a bundle. Bug / Bug / Pull request
  • @heaths optimized some Burn patch detection. Bug / Bug / Pull request
  • @barnson validated MsiPackage product versions are legal for Burn (when using .msi packages built with something other than WiX, which apparently sometimes still happens). Bug / Pull request
  • @barnson fixed a problem with a particular CustomTable definition. Bug / Pull request
  • @champloo convinced tools to show an error rather than throw an exception when they can’t set file attributes. Bug / Pull request
  • @firegiantco made it possible to use any legal exit code in ExePackage/ExitCode/@Value. Bug / Pull request
  • @barnson updated the list of tables that prevent patch uninstall. Bug / Pull request
  • @sryze fixed the layout of a WixUI dialog when localized into Russian. Pull request
  • @rseanhall added verification to the VersionVariables for managed BAs. Bug / Pull request
  • @rseanhall prevented Burn from entering an endless loop with a malformed command line. Bug / Pull request
  • @robmen made sure error codes are reported during cache checking in Burn. Bug / Pull request
  • @robmen pointed to new documentation on wixtoolset.org for error 0217. Bug / Pull request
  • @barnson added a check of file size when determining whether a cabinet needs to be rebuilt in the linker. Bug / Pull request
  • @barnson fixed the layout of a WixUI dialog for Portuguese.  Bug / Pull request
  • @barnson fixed a crash in Dark.exe. Bug / Pull request
  • @barnson added some documentation about output type in Votive property pages. Bug / Pull request
  • @barnson plugged a memory leak in Burn and removed some dead code. Bug / Pull request
  • @rseanhall fixed Burn to ensure progress isn’t above 100 percent. Bug / Pull request
  • @barnson fixed compression level when set with MediaTemplate. Bug / Pull request
  • @barnson added some documentation to clarify the things that change “bitness” when using the -arch switch. Bug / Pull request
  • @barnson prevented infinite recursion of include files by enforcing a maximum depth. Bug / Pull request
  • @rseanhall wielded the red pencil and improved the documentation. Pull request / Pull request
  • @barnson restored MsuPackage’s ability to set RemotePayload. Bug / Pull request
  • @rseanhall supported DTF being installed into the GAC. Bug / Pull request
  • @barnson clarified an error message about quotes in filenames. Bug / Pull request
  • @ericschultz ensured that VsizPackage ids that contain spaces are quoted when passed to VsixInstaller. Bug / Pull request
  • @barnson fixed a crash in Heat. Bug / Pull request

Like WiX v3.8, v3.9 took about 11 months. We’d aimed for a shorter cycle but missed. I’m not going to lose any sleep over that; we did good work and v3.9 looks to be a great release.

Next up: We know WiX v3.10 is about Visual Studio “Dev14″ and Windows 10. What else? The conversation happens on the wix-devs mailing list.