Building an Avalon application: Part 2
We've previously looked at MSBuild and how it relates to Avalon's build process. Now let us delve deeper into the Avalon build pipeline. The image here provides an overview.
The goal of Avalon Build is to provide a command line and tool-based (Visual Studio or other) build experience that exploits the same project file (.*proj). There is currently support for compiling and building WinFX applications written in XAML with C# and/or VB. Resources can be packaged in satellite assemblies or as loose content files. Avalon has full localization commenting and attribute setting support. Consequently, there is built-in support for localization in the build. Avalon follows the assembly model of Multi-lingual User Interfaces (MUI) where an application can contain language-neutral resources in the main assembly and locale-specific satellite assemblies.
The build process involves pre-build cleanup and initializations: getting the framework path, initializing properties etc. Then all types of references in the project are resolved to ensure they are up-to-date. Pass 1 of markup compile then takes XAML and generates a code-behind file (.g.cs or .g.vb depending on your language setting) and BAML for
You've just seen how the Avalon Build pipeline compiles and builds a WinFX application. In order to save you this work, we have codified this logic into the
Tags: WinFX
The goal of Avalon Build is to provide a command line and tool-based (Visual Studio or other) build experience that exploits the same project file (.*proj). There is currently support for compiling and building WinFX applications written in XAML with C# and/or VB. Resources can be packaged in satellite assemblies or as loose content files. Avalon has full localization commenting and attribute setting support. Consequently, there is built-in support for localization in the build. Avalon follows the assembly model of Multi-lingual User Interfaces (MUI) where an application can contain language-neutral resources in the main assembly and locale-specific satellite assemblies. The build process involves pre-build cleanup and initializations: getting the framework path, initializing properties etc. Then all types of references in the project are resolved to ensure they are up-to-date. Pass 1 of markup compile then takes XAML and generates a code-behind file (.g.cs or .g.vb depending on your language setting) and BAML for
Application definitions, Pages and MarkupResources. At this point if you're swelling with questions, I'd advise you to read Rob's excellent treatise on markup compilation. Following that, the file classifier looks at items in ItemGroup and properties, and culture (or locale) settings decides what files have to be embedded into main assembly or in the satellite assembly and which ones need to be loose content. The resources file is then generated. If any custom-defined types exist, a second pass of the markup compile process creates BAML for those XAML. Code is then compiled (using CSC or VBC, as the case may be) and the main assembly is created. Based on your project's culture settings, the satellite assembly is generated. At this stage, the time is right to generate manifests for the application. As we had seen in the post on Avalon's deployment story, your project file settings dictate whether the application will be browser-hosted or standalone installed. All build artifacts are then copied to the output directory.You've just seen how the Avalon Build pipeline compiles and builds a WinFX application. In order to save you this work, we have codified this logic into the
Microsoft.WinFX.targets file that accompanies your WinFX install. Moreover Visual Studio 2005 uses this same infrastructure to build your Avalon apps. Do give it a shot and leave a comment for me if you have questions or issues. Tags: WinFX
0 Comments:
Post a Comment | Home | Inference: my personal blog