Microsoft Silverlight will reach end of support after October 2021. Learn more.
Configures XAML compilation to join partial classes between markup and code-behind. The code partial class is defined in a separate code file in a CLR language, and the markup partial class is created by code generation during XAML compilation.
XAML Attribute Usage
<object x:Class="namespace.classname"...> ... </object>
Optional. Specifies a common language runtime (CLR) namespace that contains the partial class identified by classname. If namespace is specified, a dot (.) separates namespace and classname. If namespace is omitted, classname is assumed to have no namespace.
Required. Specifies the CLR name of the partial class that connects the loaded XAML and your code-behind for that XAML.
x:Class can be declared as an attribute for any element that is the root of a XAML file/object tree and is being compiled (where the XAML is included in a project with Page build action), or for the Application root in the application definition of a compiled application. Declaring x:Class on any element other than a page root or application root, and under any circumstances for a XAML file that is not compiled, results in a compile-time error.
The class used as x:Class cannot be a nested class.
The value of the x:Class attribute must be a string that specifies the fully qualified name of a class. You can omit namespace information so long as that is how the code-behind is structured also (your class definition starts at the class level). The code-behind file for a page or application definition must be within a code file that is included as part of the project that produces a compiled application. You must follow name rules for CLR classes. The code-behind class must be public. Unless using DLR, the code-behind class must be partial. For more information, see Code-Behind and Partial Classes.
Note that this meaning of the x:Class attribute value is specific to the Silverlight XAML implementation. Other XAML implementations outside of Silverlight might not use managed code, and thus might use a different class resolution formula. WPF has a slightly different meaning of x:Class because WPF supports certain features that Silverlight does not, such as the ability to declare the access level of the code-behind class.