Localizing more than strings in WiX v3.6

Localizing an MSI package—primarily the user interface but also bits like the product name, shortcut names, and other user-visible, localizable strings—has been pretty much unchanged since WiX v2.0:

  • 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.


Microsoft Source Analysis for C# released

Microsoft Source Analysis for C# — known inside Microsoft as StyleCop — is now available. We use StyleCop on new WiX code, in addition to FxCop to analyze code for style consistency and correctness. Now that StyleC…er, Microsoft Source Analysis for C# is available outside the campus grounds, we can include the settings files we use in the WiX codebase.

StyleCop is a Visual Studio package that integrates analysis commands in the Solution Explorer and a tool window to show analysis results. StyleCop also includes MSBuild tasks so you can make analysis runs part of your daily builds.

Naturally, the Style…dammit…Microsoft Source Analysis for C# installer is authored in WiX. The package is extremely clean. There are no ICE errors and only ICE33 warnings about non-advertised COM registration. The only custom actions come from WixUIExtension and WixVSExtension. The UI is built with WixUI, though the StyleCop team chose to use some logo-themed white bitmaps rather than the classic-yet-modern red.

The first few times you run StyleCop on existing code, you’re bound to be surprised and probably frustrated. The rules are, after all, about enforcing a consistent coding style. Unless you happen to already be using the StyleCop style, you’ll get a lot of “violations” that seem quite arbitrary. Yep, and that’s the point: Coding style discussions are pretty much religious wars over arbitrary decisions. (Yes, there are exceptions, but mostly it’s personal esthetic choice. Except for tabs versus spaces; don’t mess with tabs versus spaces!)

Just stick with StyleCop style and you’ll be consistent, even if elements of the style aren’t your personal favorite.

Raymond Chen on setup UI

Raymond Chen, famous Windows shell ninja, suggests today in his blog that the “action” button in a setup wizard, should be labeled Next instead of Finish. While I wholeheartedly agree that Finish is a bad label for the button that kicks off the actual installation process, Next has its own problems. In WixUI, each installation action gets its own label: Install, Change, Remove, Repair. Buttons labeled Next are reserved for pages that lead to more options.

Raymond can undoubtedly call upon legions of minions to punish me for my heresy, but I think the current WixUI model is better because it’s more explicit. And it means you can “page surf” to your heart’s content as long as you see Back and Next buttons.