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
Posted in
WiX at August 30th, 2008.
7 Comments.
Rick Brewster of the Paint.NET team blogged about the pain of getting Paint.NET installed on a system without the .NET Framework. It’s fair to say that for a system running Windows XP without optional updates, installing the latest and greatest Framework is an annoying exercise. Part of the problem (blame) falls on the shoulders of the Framework folks: The Framework installer should install MSI 3.1 for users; asking them to go spelunking on the Microsoft Download Center for the MSI 3.1 redistributable, then run it and reboot, is rude at best.
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.
Posted in
Burn,
WiX at August 25th, 2008.
8 Comments.
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
[Updated with actual features -v- bug fixes.]
Posted in
WiX at August 23rd, 2008.
No Comments.
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
Posted in
WiX at August 16th, 2008.
8 Comments.
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
Posted in
WiX at August 3rd, 2008.
No Comments.
WiX v3.0.4325.0 was released on Friday, 25-July-08. You can download it from http://wix.sourceforge.net/releases/3.0.4325.0/.
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
Posted in
WiX at July 26th, 2008.
No Comments.
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
Posted in
WiX at July 21st, 2008.
2 Comments.
Loc variables — using !(loc.id) syntax to refer to strings defined in a .wxl file — let you use a single set of source files to build multiple localized installers. Common uses include obvious localizable strings like the product name and error messages. Slightly less common, but just as important to the localization process, are strings that aren’t visible to the user, like product-code GUIDs. They work great but there’s a risk: Loc strings aren’t subject to the same validation and correction code that “normal” strings go through. GUIDs are a perfect example. Normal strings in a .wxs source file are validated and normalized by the compiler, adding {braces} and uppercasing them as necessary to fit the Windows Installer rules for GUIDs.
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.
Posted in
WiX at July 17th, 2008.
No Comments.
WiX v3.0.4311.0 was released on Friday, 11-July-08. You can download it from http://wix.sourceforge.net/releases/3.0.4311.0/.
New features
- Neil Enns, late of the MSBuild team and now working on secret stuff, contributed a new section of how-to topics for WiX.chm. (This was actually new in v3.0.4220, but I didn’t catch it. Mea culpa!)
- Neil also added support for multiple .wxl (loc-string collection) files in .wixproj projects.
- The SecureObj custom actions, triggered by the use of the PermissionEx element in WixUtilExtension, now support 64-bit systems, including both x64 and IA64.
- Jason added support for MSI 4.5 multi-package transactions to DTF.
- I added new file-i/o functions (FileReadPartial and FileWrite) and error reporting for XML parsing errors to the dutil library.
- Aaron added new documentation in addition to fixing WixUI bugs.
- Votive now has fancy new high-res/high-color icons on Windows Vista.
Bug fixes
Posted in
WiX at July 12th, 2008.
6 Comments.
Burn is the name of the new WiX chainer. (Burn is brought to you by the letter B, which stands for bootstrapper.) Though we’re working to ship WiX v3 without Burn, work on Burn continues — it turns out that several members of the WiX virtual team need a chainer for their day jobs. As I’m one of them, I thought I’d blog about the work I’m doing. To start that, this post covers the layers in Burn and how they fit together:
- Core: The Burn core is where the actual chaining and installation code lives. This is, not surprisingly, the biggest chunk of code in Burn, with several thousand lines of code. The core supports installing .msi and .exe packages, with .msp patch package support planned. The core is a static library.
- UX: UX, which stands for User eXperience, handles user interface. Burn includes StdUx, which provides a basic UI. StdUx can be replaced by any DLL that adheres to the Burn UX interface.
- Stub: The Burn stub is an .exe that handles standard command-line processing and startup. It loads the manifest, UX DLL, and packages — any of which might be embedded in the .exe — and lets the UX take over.
- BurnExe: BurnExe is the manifest compiler and bundle builder. The package manifest is an XML file that specifies the list of packages to be installed; BurnExe resolves references to packages and extracts metadata like the product code and product version. BurnExe also optionally builds a bundle — a copy of a stub with embedded data. For example, right now, BurnExe supports embedding the resolved manifest so setup.exe can be signed to help ensure the manifest hasn’t been tampered with. The plan is to also support embedding the UX DLL and packages to provide a single setup.exe download.
Any layer of Burn can be replaced. For example, I expect someone on my team to create a custom UX for Train Simulator 2. The Burn design focuses customizability in the UX so the other layers can be used as-is.
There’s plenty more work to do, so that’s it for today. More to come as more of Burn matures!
Posted in
Burn,
WiX at June 21st, 2008.
No Comments.