1. The Google Chrome download is a svelte 474K bootstrapper that downloads the setup bits. No offline installer is available (unless it’s well-hidden).
2. Google Chrome is a "composite" setup: The guts of the application are installed by a non-MSI self-extractor. However, Google Chrome includes Google Gears, the browser add-in/library that adds a bunch of functionality for making apps-in-the-browser more powerful. The Gears in Google Chrome is installed by an MSI package. And yes, it’s built with WiX.
3. The Google Updater is no longer a LocalSystem service; instead, it starts at logon from the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key.
4. Last and absolutely not least: Google Chrome is a per-user application. It even installs in the per-user LocalAppDataFolder. (The included Google Gears is marked as "UAC compliant.")

That Google Chrome is a per-user app is amazing. Even with UAC on Windows Vista and Windows Server 2008, it’s so easy to say that "everyone’s used to needing admin privileges to install." That Google took the extra effort to limit themselves to the capabilities of a per-user app says a lot about their desire to have:

• a low-impact setup
• and absolutely no barriers to entry.

I wonder if it’s the start of a trend…

WiX v3.0.4429.0 was released on Friday, 29-August-08. You can download it from http://wix.sourceforge.net/releases/3.0.4429.0/.

New features

• Aaron added properties to WixVSExtension to detect Visual Studio 2008 Service Pack 1.
• Aaron also added a new custom action, WixExitEarlyWithSuccess, which makes it easy to exit without error in a major upgrade when a later version is already installed.
• I updated make.bat and wix.build to pass desired verbosity from the NAnt side of the build to the MSBuild side.
• Candy Chiang, of the team integrating WiX into Visual Studio, contributed many updates to the WiX.chm documentation.

Bug fixes

• 1591591: scawebsvcext.cpp does not work in IIS 5
• 1741663: WebAppPool Fails on IIS < 6.0
• 1848752: NativeImage CA never runs
• 2010047: Cannot add wixlib to project
• 2041989: Candle exception when inculding an invalid wxi file
• 2077095: Firewall Extension fails
• Eric St. John fixed a bug in the CloseApplication custom action to correctly send close messages to all the top-level windows of the specified process, which should fix the problem noted on wix-users where CloseApplication didn’t work with VB6 apps.

Rick’s proposed solution for the next release of Paint.NET is OK, though it has the downside of showing several very different UI experiences:

• A "confirmation" dialog that tells users that prerequisites will be installed.
• The OS-component update dialog (for MSI 3.1) that most users no longer see, because it’s hidden behind Windows Update.
• The .NET Framework Client Profile bootstrapper UI, which is slightly different than the OS-component update dialog.
• The Paint.NET installer configuration UI, which is slightly different than the others.
• The Paint.NET installer UI itself, which uses MSI basic UI.
• If needed, a "reboot needed" dialog, which uses slightly different UI.

A key scenario for Burn is to enable this scenario (with the Client Profile or "normal" .NET Framework installation). Part of being successful with that scenario is to have an integrated experience, which means having a consistent user interface and one progress bar.

We’re not there yet, but know that we’re working hard to solve this problem.

WiX v3.0.4422.0 was released on Friday, 22-August-08. You can download it from http://wix.sourceforge.net/releases/3.0.4422.0/.

New features

• Aaron added documentation on properties used in the MSBuild tasks and targets.
• Dan Manson added a strong-name skip-verification entry so builds on x64 OSes work without registry hacks.
• Eric St. John added the ElevatedCloseMessage attribute to the WixUtilExtension CloseApplication element (and corresponding custom action implementation), to send a close message to the target process’s windows while running deferred.

Bug fixes

• 1708072: Access Violation with Large Cabinets
• 1827123: Can’t create sql database with name contains ‘-’
• 1881660: IIS Extension: Unable to install Certificate from MSM
• 1881856: IIS Extension: Unable uninstalling certificate under VISTA
• 1930640: PFXImportCertStore() fails to delete private key containers.
• 1984738: SchedXmlFile does not return ERROR_INSTALL_USEREXIT
• 2013549: Pyro is unnecessary slow
• 2023959: ConfigureEventManfiest returns ERROR_INSTALL_FAIL on cancel
• 2034934: Binder variable File IDs are not modularized
• 2041989: Candle exception when inculding an invalid wxi file
• Chris Araman cleaned up some warnings in native code.
• Mike Carlson fixed the preprocessor to handle variable names containing a dot in ifdef/ifndef checks.
• Mike also fixed the WixUtilExtension User custom action so that on uninstall, it removes the user from groups it was added to if the user isn’t deleted on uninstall.

[Updated with actual features -v- bug fixes.]

WiX v3.0.4415.0–code-named Heat-Wave-in-Seattle?!–was released on Friday, 15-August-08. You can download it from http://wix.sourceforge.net/releases/3.0.4415.0/.

New features

• Jason added to DTF support for MSI 4.5’s embedded UI, along with a sample that uses WPF for the UI.
• Eric St. John added support for standard command-line switches to the WiX v3 bootstrapper.

Bug fixes

• 1273447: Can’t put RegLocator inside DrLocator
• 1613071: Unable to save VS project
• 1832500: Preprocessor: nested include uses wrong directory
• 2051748: SqlDatabase table definition error
• I worked around a bug in MSI 4.5’s support for embedded UI. The FileName column purports to be of the Filename type, which requires both short (8.3) and long file names. It turns out only one file name, long or short, is supported.
• Aaron fixed bugs in the ShellExec custom action topic and the how-tos that referred to it.
• Jungwook Bae, of the Visual Studio team integrating WiX, fixed some bugs in Votive to make it behave more like C# projects.

WiX v3.0.4401.0 was released on Friday, 01-August-08. You can download it from http://wix.sourceforge.net/releases/3.0.4401.0/.

New features

• Neil Enns continues to add topics and fix bugs in the documentation.
• Mike Carlson made the Id/Name attribute default values (in the File element, from the @Source attribute) when used from a fragment.

Bug fixes

• 2011737: Deleting an Element with XmlConfig always results in Failure
• 2027482: Exception when AssemblyManifest does not exist
• 2031498: EmbeddedUIResource

New features

• Mike Carlson changed the preprocessor to stop evaluating expressions in a false <?if?> block. That lets you check for the presence of a preprocessor variable, for example, and use it in the block "knowing" that it’s defined.

Bug fixes

• Jason and Mike cleaned up FxCop warnings.
• Mike also added an error message when the cab-handling code couldn’t create temporary files.
• Aaron cleaned up some command-line handling code.
• 2010040: Bind files into the library file not working.
• 2013944: CAs always fail on Windows 2000 (or lower).
• 2016490: Votive doesn’t honour Visible item metadata
• 2020595: 3.0.4309.0 breaks msi filename compatibility 
  Note that this change places localized output into subdirectories named after the culture (e.g., en-us). The previous change embedded the culture id in the output name (e.g., foo.en-us.msi) which might have caused problems because MSI package names can’t change except by major upgrade. Thanks to blogless Neil for the MSBuild mojo.
• 2025134: Using ExtractFiles Method
• 2025411: Localized incremental builds are somewhat broken

WiX v3.0.4318.0 was released on Friday, 18-July-08. You can download it from http://wix.sourceforge.net/releases/3.0.4318.0/.

New features

• Neil Enns, still late of the MSBuild team and still working on secret stuff, added two new properties to the OsInfo custom actions that detect the presence of a WDDM driver and whether Desktop Window Manager (DWM) composition is enabled. See "OSInfo custom actions" in WiX.chm for details.
• Aaron added directory properties for .NET Framework root directories. See the "WixNetfxExtension" topic in WiX.chm for details.
• Mike Holcomb added better error messages in the setupexe "mini-chainer" when installation errors occur.
• I added support for Unicode filenames used as source files in cabinets.
• I added PathGetKnownFolder, PathIsAbsolute, and PathConcat to the DUtil library.

Bug fixes

• Neil fixed a bug in wix.targets that wasn’t passing culture information to Light when the project itself wasn’t localized.
• Mike Carlson from the Visual Studio team cleaned up warnings reported by PREfast.
• 1881462: Add support for "Trusted People" certificate store.
• 1942826: Build fails if Wixlib reference is an UNC path (take two)
• 1979210: Dark 3.0.4123.0 InvalidCastException on Windbg 6.9.3.113 MSI
• 2009171: Dark: Error on RadioButton table processing
• 2011818: Build output path is not saved
• 2016489: Votive adds empty Link metadata to renamed items
• 2017732: Dark 3.0.4227.0 InvalidCastException

There’s an open feature request to get some of the same validation done for loc strings. Maybe some weekend…

Executive summary

When you use GUIDs in loc strings, make sure they’re uppercase and in braces.

Why

Loc variables are one type of bind-time variable. Bind-time variables are resolved at, well, bind time, which is part of the linking/binding job that Light.exe does. Preprocessor variables, using $(var.id) syntax, are resolved by Candle.exe. (Technically, preprocessing, as the pre- prefix implies, happens even before compilation.) Since it’s the compiler in Candle.exe that does the deepest validation, bind-time variables miss out on it. For now, anyway.

• LOGMSG_TRACEONLY: Written to the log only in debug builds for debugging custom actions.
• LOGMSG_VERBOSE: Written to the log only when verbose logging is enabled.
• LOGMSG_STANDARD: Always written to the log.

WcaLog considers verbose logging enabled whenever any of the following is true:

• LOGVERBOSE property: There’s a property in your package named LOGVERBOSE, regardless of its value.
• MsiLogging property: There’s a property in your package named MsiLogging that contains a V character.
• Logging policy: The logging policy is set and contains a V character.

Otherwise, messages tagged with LOGMSG_VERBOSE will be ignored.

The second argument is a printf-style format string so there are a variable number of arguments (zero or more) after it which specify the values referred to in the format string. For example:

WcaLog(LOGMSG_VERBOSE, "App: %S found running, %d processes, setting ‘%S’ property.", wzApplication, cProcessIds, wzProperty);

Note that WcaLog uses ANSI strings for the format string and its arguments, so if you want to log a Unicode string, you need to use the %ls or %S field characters.