<String Id="ProductLongName">$(var.ProductShortName)(R) $(var.ProductMarketingVersion)</String>

Then you discover that your product is now named “$(var.ProductShortName)(R) $(var.ProductMarketingVersion).” The reason for that is simple, if not obvious: $(var) references are handled by the WiX preprocessor, which happens before compilation, as part of Candle.exe. Localization strings are handled at bind time by Light.exe. The compiler and preprocessor are nowhere to be found.

One solution is to simply repeat yourself. It makes for straightforward localization strings but it means that some changes have to be reflected in multiple localization strings. For example, version numbers frequently show up in multiple strings.

Luckily, it doesn’t have to come to that. Though not explicitly documented (quelle surprise!), localization strings can contain references to other localization strings. For example, the following strings are legal:

<String Id="ProductShortName">BobStudio</String>
<String Id="ProductMarketingVersion">2013 Update 2</String>
<String Id="ProductLongName">!(loc.ProductShortName)(R) !(loc.ProductMarketingVersion)</String>

When used in authoring:

<Product Name="!(loc.ProductLongName)" ...

the resulting ProductName property is, exactly as you’d expect:

BobStudio(R) 2013 Update 2

The code in WiX responsible for this behavior is WixVariableResolver. As the name implies, it’s not limited to just localization variables, but also works for other bind-time variables. For example, you can also use the special !(bind) variables:

<String Id="ProductLongName">!(loc.ProductShortName)(R) !(loc.ProductMarketingVersion) [!(bind.fileVersion.App.exe)]</String>

yields

BobStudio(R) 2013 Update 2 [3.7.1224.0]

The Codeplex download page has the release notes I wrote to summarize the changes since WiX v3.5. I’ve blogged about some of the other changes as they developed but even I was surprised at the number of changes and additions other than Burn. (Thanks to Beyond Compare for helping weed out insignificant diffs.)

According to the good ol’ SourceForge bug tracker, 688 bugs were opened and targeted for WiX v3.6; of those, 493 were fixed. Though a few were postponed, WiX v3.7 has only 25 bugs at the moment.

I, for one, will take the rest of Labor Day off. Then tomorrow it’s back to WiX v3.7!

• Localizable strings are specified in the appropriate attributes in your WiX authoring using !(loc.stringid) syntax.
• Strings are specified by id in per-language WixLocalization (.wxl) files.
• Light, the WiX linker, takes a list of cultures to use when resolving !(loc.stringid) in the authoring.

As you can see, localization is all about the strings. However, strings can vary dramatically in length among languages. In the WixUI dialog library, controls were sized to handle string lengths for all the languages WixUI supported. Unfortunately, that resulted in some controls being far wider than necessary. The Install button, for example, is wider than the other buttons on the same dialogs. We hadn’t had to resize any controls in WixUI for a while—and then a bug said otherwise.

Rather than yet again resizing a control, WiX v3.6 gets a new feature so we never have to do that again. In WiX v3.6, the WixLocalization schema has been extended with a UI child element that lets the localization for a particular culture change the attributes of an individual control or an entire dialog. For example, a later bug indicated the need for another big button in WixUI_Advanced. The fix in the ru-RU localization file was easy:

<UI Dialog="AdvancedWelcomeEulaDlg" Control="Print" X="50" />
<UI Dialog="AdvancedWelcomeEulaDlg" Control="Advanced" X="124" Width="85" />

The first line moves the Print button to the left, to make room for a bigger Advanced button, which the second button supplies. The dialog and control attributes identify a particular control.

The WixLocalization UI element (unrelated to the UI element in the WiX namespace) lets you:

• Resize a control using the Height and Width attributes.
• Move a control using the X and Y attributes.
• Change the control’s localization-related attributes: LeftScroll, RightAligned, and RightToLeft.
• Change the control’s text using the inner text of the UI element.

You can also use the UI element on dialogs by omitting a Control attribute:

• Resize a dialog using the Height and Width attributes.
• Change the dialog’s centering values using the X and Y attributes.
• Change the dialog’s title using the inner text of the UI element.

Don’t forget native code

Though localization files are most often used inside MSI packages using WixUI dialog sets, they’re also used extensively in the WixStandardBootstrapperApplication for Burn. And even if you use a managed bootstrapper application, you’re still using WixStandardBootstrapperApplication when the managed host needs to install .NET.

Still, it’s better than nothing — the Windows Store is likely to have a lot of window shoppers looking to buy apps.

However, a hurdle to get an app listing page is that the app must pass “certification.” In the past, this was known as the Windows Logo program and had many pages of technical requirements. In Windows 8, the list is much smaller and less prescriptive. For example, the Logo program for previous versions required the use of MSI, then required MSI or ClickOnce; for Windows 8, there are no technology restrictions.

Some requirements that struck me as interesting:

1.2 Your app must not take a dependency on the VB6 runtime

VB6, IE6 — anything v6 must go away.

5.1 Your app must properly implement a clean, reversible installation

If the installation fails, the app should be able to roll it back and restore the machine to its previous state.

If Windows 8 certification is anything like previous versions’, it will involve automated test suites that will highlight rollback that’s less than perfect.

5.4 Your app must never block silent install/uninstall

So don’t throw UI from custom actions and don’t rely on being able to prompt the user (i.e., also don’t break requirement #5.1).

6.1 All executable files (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) must be signed with an Authenticode certificate

MSI packages aren’t mentioned. But if you ship a Burn bundle or other bootstrapper .exe, that’s going to require signing.

10.1 Your app must be installed in the Program Files folder by default

There’s nothing mentioned that would exempt per-user apps in general from this requirement, though you can always request exceptions. Given the emphasis Metro places on per-user, restricted apps, perhaps this requirement will be extended/relaxed for per-user desktop apps too.

10.6 Your app must write user data at first run and not during the installation in “per-machine” installations

Long-time readers of wix-users will recognize this as advice given again and again. Good to see Windows catching on.

10.7 Exceptions and Waivers

A waiver is required for apps that write to the global assembly cache (GAC) .NET apps should keep assembly dependencies private, and store it in the app directory unless sharing an assembly is explicitly required.

I suspect it’s a response to the GAC getting used too often when it’s not needed or very useful. (See also Rico Mariani’s blog post on using NGen, which falls into the same boat.) Still, I’m mildly surprised to see it a requirement.

12.5 App running under the WoW64 emulator should not attempt to subvert or bypass Wow64 virtualization mechanisms

This one’s interesting, depending how struct “subvert” turns out to be. For example, several WiX custom actions make fairly trivial “subversions” of WoW64 to avoid the need for both 32-bit and 64-bit custom actions just to write to the right version of Program Files.

All in all, there’s nothing terribly surprising in this set of requirements. A lot of them just codify what’s already known as best practice for Windows apps in the age of UAC. Of course, this is just the first version of the certification requirements and Windows 8 isn’t yet shipping; there’s plenty of time for Microsoft to add, drop, or change requirements. In the end, you get to decide whether the effort of certification is worth having a presence in the Windows Store. Remember the Metro-style app folks, who have no choice in the matter: The Windows Store is the only way they can ship.

Now that there’s a spot for weekly builds again, the hiatus that began with the release of WiX v3.6 beta in October is done. WiX v3.6.2520.0 is available and contains almost three months of features and fixes. One of the nicest new features is a much-improved bootstrapper application for the WiX bundle installer.

Take a look, install, try it out, and report bugs!

There are three primary buckets applications fall into in the brave new Windows 8 world:

1. Metro-style
2. Windows 8 non-Metro-style
3. “Retro-style” (aka legacy, anything created before 2011)

Metro-style apps get all the goodies Windows 8 offers, including AppX packaging I’ll blog about. As Rob describes, deployment is a first-class citizen in Windows 8. Apps in the other two buckets have the exact same options they have in Windows 7. And by exact, I mean “really, almost exactly 100 percent.”

No soup for you

As is its wont, rather than fixing the weaknesses of its existing platform, Microsoft replaced it with an all-new platform with a different set of weaknesses. Naturally, Windows 8 still includes Windows Installer. But if you were hoping for some of the same deployment love for your non-Metro-style apps that the Windows team showered on Metro-style apps, I’m sorry to disappoint: For better or worse, Windows 8′s MSI is functionally identical to Windows 7′s MSI v5.0.

A quick spelunking in the Windows 8 SDK available to MSDN subscribers reveals mostly structual changes to the MSI header files. For example, the _WIN32_MSI macro is defined as “500″ for both Windows 7 and Windows 8:

#if (_WIN32_WINNT >= 0x0601 || (defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN8))
 #define _WIN32_MSI   500
#elif (_WIN32_WINNT >= 0x0601 || (defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN7))
 #define _WIN32_MSI   500

The only addition is a new MSIARCHITECTUREFLAGS value in Msi.h:

typedef enum tagMSIARCHITECTUREFLAGS
{
 MSIARCHITECTUREFLAGS_X86   = 0x00000001L, // set if creating the script for i386 platform
 MSIARCHITECTUREFLAGS_IA64  = 0x00000002L, // set if creating the script for IA64 platform
 MSIARCHITECTUREFLAGS_AMD64 = 0x00000004L, // set if creating the script for AMD64 platform
 MSIARCHITECTUREFLAGS_ARM   = 0x00000008L //set if creating the script for ARM platform
}MSIARCHITECTUREFLAGS;

and a new property name in MsiDefs.h:

#define IPROPNAME_ARM              TEXT("Arm")

As we’ve known for a while that Windows 8 will support the ARM architecture, its presence isn’t too surprising.

There are no other new enumeration values. There are no new MSI API functions. While it’s possible there are, for example, new standard actions that wouldn’t have visible impact in the header files, I don’t find it too likely.

That yields two tiny bits of good news:

1. Lack of visible interface changes probably means a lack of visible behavior changes. That likely means that your Retro-style installers will probably work without change, or at least as well as the classic Windows 8 desktop supports Retro-style apps.
2. WiX and Burn won’t need to do anything to support Windows 8. OK, that’s something only a few of us need to worry about…

Coming up: More about Metro-style deployment.

Media templates

There are advantages to having multiple cabinets for your MSI packages, from build-time performance to more reliable downloading. Unfortunately, up to WiX v3.5, WiX required you to explicitly identify a set of files to go into a second (or third or fourth or…) cabinet using the DiskId attribute on the Component, File, Directory, or DirectoryRef elements.

WiX v3.6′s MediaTemplate element automatically creates cabinets up to an optionally-specified size. Files are assigned to “fill” each cabinet.

Note: MediaTemplate replaces the Media element; having both in your authoring results in a link-time error. You can still manually author DiskId attributes but they’re ignored in favor of MediaTemplate’s automatic cabinet making.

The simplest use of MediaTemplate is an empty element that takes all the defaults:

<MediaTemplate />

MediaTemplate will generate as many cabinets as necessary for all the files in your package, up to a maximum of 999 cabinets. (If you have more than that, good luck!) Each cabinet will:

• Be named Prod###.cab
• Be external to the package (not embedded)
• Store up to 200MB of files before compression

MediaTemplate shares some of Media’s attributes, to cover the same functionality:

• CompressionLevel specifies the compression level to use in each cabinet.
• DiskPrompt specifies the disk name and VolumeLabel the volume label, if you’re dealing with multi-disk installs.
• EmbedCab lets you embed the cabinets in the .msi package. The default is to keep the cabinets external.

Attributes specific to MediaTemplate control how the cabinets are generated and filled:

• CabinetTemplate names each cabinet. The default is “Prod{0}.cab” which yields cabinet names of Prod1.cab, Prod2.cab, and so forth. The “{0}” is replaced with cabinet numbers, from 1 to 999. MSI says that cabinets have to follow the rules for 8.3 short filenames, so you can have up to five whole characters to distinguish your cabinet names.
• MaximumUncompressedMediaSize, as its impressively-long name indicates, specifies the maximum size of the files in each cabinet, in megabytes. The default size is 200MB.MediaTemplate counts actual file sizes—without compression—as it adds files to cabinets. Doing so is more predictable than trying to add files to cabinets as part of the cabinet-creation process; WiX can’t accurately predict how much a particular file will take up once it’s compressed so adding a file to a cabinet might make it larger than the maximum size. Using the uncompressed file size means that compressed cabinets will generally be smaller than the maximum size. On the flip side, any individual files that are larger than the maximum size go into a single-file cabinet, so it’s possible that such cabinets will be larger than the maximum size.

You can override MaximumUncompressedMediaSize by specifying the size in megabytes in the WIX_MUMS environment variable. You wouldn’t typically do so but using an environment variable makes it easy to tweak the cabinet size on a developer box, say to create more, smaller cabinets to take advantage of WiX’s multithreaded cabinet creation to speed up builds on a developer box with many cores.

Overriding compression level

Speaking of speeding up developer builds…Back in 2008, I added the default compression level feature to let you specify compression level at the project level instead of just in WiX authoring. That feature let you change compression level without changing authoring but you still had to change your .wixproj or other build script.

Now in WiX v3.6, you can override the compression level by specifying the WIX_COMPRESSION_LEVEL environment variable with the same values you can specify in, for example, the MediaTemplate/@CompressionLevel attribute. WIX_COMPRESSION_LEVEL overrides the default compression level specified in .wixproj MSBuild projects and explicitly authored @CompressionLevel attribute values.

There’s one simple use case: WIX_COMPRESSION_LEVEL lets developers specify “none” or “low” compression to avoid pegging all their CPU cores doing “mszip” or “high” compression that they absolutely don’t care about.