B is for... BAML
Well, in keeping with the letter of the week, the answer is, of course, b, Binary Application Markup Language.
BAML is the compiled version of the XAML (eXtensible Application Markup Language) markup that describes the user interface of your application. At build time, the XAML is parsed and tokenized into this binary format to improve runtime performance (over parsing and loading the source XAML). BAML also provides a mechanism to support application localization.
In general, the existence of BAML is an implementation detail, but you can get a glimpse of it when building applications in Visual Studio by looking in the obj subdirectory for your build environment.
Also in that directory is a g.vb (or g.cs) file that implements the IComponentConnector interface, the two methods of which (InitializeComponent and Connect) serve to instantiate the user interface from the BAML resource.
The BAML is ultimately stored as a resource in the resulting EXE file as well. Using the .NET Reflector along with the BAML Viewer plug-in, you can disassemble the BAML format into its original XAML (see below):
One notable direct use of BAML in your development tasks is during application localization. There are several options for localization; however, choosing BAML as the mechanism has the benefits that you can perform the localization as a post-build step as well as merge prior localizations with a newer version of your application.
The steps of localization can be summarized as below (see MSDN for a more detailed description of the process):
- Mark the localizable UI elements with a unique x:Uid attribute in your source XAML. You can do this manually, but that can be an error-prone process, so the recommendation is to use the /t:updateuid switch of msbuild as part of the build process.
- Generate a neutral satellite assembly containing the localizable resources (which get included as BAML in the dll). To generate this neutral assembly at build time, you need to add a <UICulture> tag manually to your Visual Studio project file.
- Parse the localizable elements from the satellite dll (using APIs in the System.Windows.Markup.Localizer namespace)
- Perform the translation of localized elements to the target language
- Generate a new localized satellite assembly
For steps 3 through 5, locBaml, a sample program included in the Windows SDK, provides a command-line interface to aid the localization process. locBaml wraps many of the Localizer APIs to extract the resources as a comma-separated (CSV) file. The localization (step 4) can then be carried out with any editor capable of handling comma-separated files - like Microsoft Excel. After the manual translation process is completed, locBaml can be run again to create the new localized assembly, using the edited CSV file as input.
At runtime, the .NET Framework will automatically load the appropriate localized assembly based on the CurrentUICulture, provided, of course, that the satellite dll is placed in the subdirectory matching the language code for the targeted culture (e.g., /de-DE for Germany or /fr-CA for French Canadian).