Constructors and XAML For managed code that backs a XAML implementation, the managed-code constructor serves a XAML-specific purpose. When a XAML processor encounters an object element, the processor searches for the backing managed class. The processor then calls the default (parameterless) constructor of that class immediately. Only after the default instance is created are any of the XAML attributes processed in order to set properties on the starting default instance. Therefore, any class that is intended to provide object element support in XAML must expose a public default constructor. This and other general concepts about XAML are explained in XAML Overview. When you write aspects of a Silverlight-based application in code rather than defining that aspect in markup, you can generally assume that if a given element could be defined in XAML with an object element, then you can also create it in code by following the same logic as a XAML parser, first creating the managed code object with its default constructor, and then setting properties as necessary. However, there are some exceptions to this general rule. In particular, Silverlight 2 does not support defining a ControlTemplate in code.
When you write aspects of a Silverlight-based application in code rather than defining that aspect in markup, you can generally assume that if a given element could be defined in XAML with an object element, then you can also create it in code by following the same logic as a XAML parser, first creating the managed code object with its default constructor, and then setting properties as necessary.
However, there are some exceptions to this general rule. In particular, Silverlight 2 does not support defining a ControlTemplate in code.