How is a WPF XAML file tied into the application’s executable environment?

By hidden source code file…

A hidden source code file is auto-generated for each WPF XAML file. The names used for this file and for the class it contains are based off the XAML file’s filename. In a C# application, the file MyWindow.xaml will have a hidden code-behind file named MyWindow.g.cs containing a class named MyWindow.

…containing a class…

The contained class inherits from the WPF core class corresponding to the associated XAML file’s root element. If the root element in the XAML file is <Window>, the class in the hidden code-behind file will inherit from Window.

public partial class MyWindow : System.Windows.Window, System.Windows.Markup.IComponentConnector

The contained class is defined as a partial class, allowing the programmer to add code to the class without modifying the auto-generated hidden file. Microsoft Visual Studio encourages this practice by creating a non-hidden code-behind file each time a new XAML file is added to a WPF project. In the case of MyWindow.xaml, the corresponding non-hidden code-behind file will be named MyWindow.xaml.cs.

…that loads the XAML as a component…

In most cases (with the most notable exception being the case of App.xaml), the auto-generated class contains code loading the XAML file into the application as a component via a call to System.Windows.Application’s static method LoadComponent(..).

private bool _contentLoaded;

public void InitializeComponent() {
    if (_contentLoaded) {
    _contentLoaded = true;
    System.Uri resourceLocater = new System.Uri("/WPFXAMLExecution;component/MyWindow.xaml", System.UriKind.Relative);

    #line 1 "..\..\MyWindow.xaml"
    System.Windows.Application.LoadComponent(this, resourceLocater);

    #line default
    #line hidden

…and connects named controls to instance variables.

In most cases, this class also contains code wiring up named controls (controls whose defining XAML specifies a x:Name or Name attribute) to instance variables. If  MyWindow.xaml defines <TextBox x:Name=”FirstName” />, this wire-up allows that TextBox control to be accessed from code via MyWindow’s FirstName property (e.g. myWindowInstance.FirstName.Text = “Joe”;)

#line 5 "..\..\MyWindow.xaml"
internal System.Windows.Controls.TextBlock FirstName;

#line default
#line hidden

[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.Design", "CA1033:InterfaceMethodsShouldBeCallableByChildTypes")]
void System.Windows.Markup.IComponentConnector.Connect(int connectionId, object target) {
    switch (connectionId)
    case 1:
    this.FirstName = ((System.Windows.Controls.TextBlock)(target));
    this._contentLoaded = true;

Differs from Windows Forms

Those of you with a Windows Forms background may have noticed a significant difference in the content of WPF’s hidden code-behind files. In Windows Forms, each form’s hidden code-behind contains a compete representation of the form written in executable code. In WPF, each XAML file’s hidden code-behind contains only the code necessary to wire the XAML file into the executable environment as a component.

Related: WPF, Where Is Your “static Main()” Method? – on the auto-generation of the static Main() method in WPF applications.

One thought on “How is a WPF XAML file tied into the application’s executable environment?

  1. Mark Wain

    Hi Ben:

    Nice article.

    I’m using VS 2012 for desk top applications. I believe myWindow application has different executable environment from the 2010 one.

    I wish you’d rewrite your articles related to the coupling between the XAML file and the code-behind.




Leave a Reply

Your email address will not be published. Required fields are marked *