次の方法で共有

B is for... BAML

  • [アーティクル]

 

b

BAML is....
  1. Bamm-Bamm Rubble's rapper persona
  2. Binary Application Markup Language
  3. Superman's long lost uncle
  4. A mixed-up ovine

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.

image

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):

.NET Reflector

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):

  1. 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.
  2. 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.
  3. Parse the localizable elements from the satellite dll (using APIs in the System.Windows.Markup.Localizer namespace)
  4. Perform the translation of localized elements to the target language
  5. 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).

Comments

  • Anonymous
    February 28, 2009
    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 :)

  • Anonymous
    March 01, 2009
    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.