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):
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).
Hi! Nice blog you have here :) Very well written... quick question about LocBaml/Localization... do you feel this is the best, and "sanctioned" method of localization? After looking at tons (ok, maybe 7 or so...) methods and libraries that perform localization, I'm torn between which methodology to use. I'm leaning back towards the method you blogged about... Does this method easily allow a user to switch to a different language from the application? It doesn't necessarily have to be at run-time, but can they store in user-prefs, I'm using "my-MX" (Mayan Mexican... would be cool :), then at load-up, set the current culture thread to their preference?
Again, nice blog :)
Thank you for the kind words. In terms of your question, I'm far from an expert in this area, but it's clear that at the moment locBAML is more of a "utility" that hasn't yet been brought into the mainstream of the dev process (like integration into VS), and as you can see, it requires a bit of manual effort.
Rob Relyea has a post (http://is.gd/ljP8) where there's a good discussion in the comments of locBAML and other approaches. That may help in your evaluation. Here's one for instance (http://is.gd/ljPP) that you may have already looked at. Rob's post alludes to some improvements as well, although they may not show until VS 2010, as well.
In terms of switching culture on the fly, yes you can do that. In fact the documentation for locBAML shows just that as a mechanism for testing your satellite assemblies.