Managed API for Silverlight
Microsoft Silverlight will reach end of support after October 2021. Learn more.
The Silverlight API defines its set of objects as object trees that enable you to populate the initial content of a Silverlight-based application by loading XAML, and then adjust the object tree at run time. In the managed API, interaction with the Silverlight object tree is defined with managed code. Using the CLR, your managed code is compiled into an assembly. The assembly typically also contains the XAML for your Silverlight-based application. Your managed code can support the Silverlight application model, and can be called in response to object lifetime events or user-initiated events. You might also use managed code to write support classes, to define data objects, and for many other application scenarios. You can also use the DLR rather than the CLR, which is discussed in Dynamic Languages in Silverlight.
Characteristics of the Managed API
Managed Code Is Extensible
In Silverlight 1.0 previously, and under the JavaScript API currently (independent of the client version), there is no support for defining a truly custom UI element. You could composite an element and then load it multiple times from the same defining XAML, and assign the same functions as code support, but this approach cannot support large-scale extensibility. Using the managed API, extensibility is simply a matter of deriving from an existing class or control that supports a useful baseline of functionality, and perhaps also defining some support elements such as a new control template, updated class-specific event handlers, and so on. Extending managed code is a basic concept of managed and .NET Framework programming and does not have a single dedicated topic in the Silverlight documentation, but you might find the following topics useful:
Object Trees
The object tree concept exists in the JavaScript API, but manipulating the tree in that model is somewhat limited by the lack of an object construction technique. In the managed API, you can call constructors on classes and can add to the tree without having to use the XAML parser as an intermediary. In fact, you can build up large parts of the tree using purely code, by calling constructors in succession and adding objects to the object tree starting from the root and working through various "children" properties. For more about how to work with the Silverlight object tree using code, see Silverlight Object Trees.
Managed Code-Behind and Partial Classes
The primary technique for defining a UI in Silverlight is to define the elements in XAML markup. This might include use of styles and templates, which are also defined in XAML markup. In many cases you will want to factor the markup into different XAML files that integrate with the Silverlight application model. In order to define the interaction that is needed for the application, you generally want to define event handlers that respond to object lifetime events or user-initiated events for the objects defined in XAML. In the managed API, each XAML page where event handling is required, or where the XAML is intended as root element content, must undergo a markup compile pass as part of the build. The markup compile pass provides the necessary hookups for run-time interaction with the object tree that is created when the XAML page is loaded. These hookups include the event handlers as well as references for any object that is given a Name or x:Name in the XAML. In the Silverlight architecture, XAML is not compiled in its entirety. Much of the object tree creation that comes from XAML markup for UI is deferred until the XAML page is actually loaded into an application at run time and is processed by the Silverlight XAML parser. These concepts are explained in more detail in Code-Behind and Partial Classes.
Formalized DOM Interaction
In the JavaScript API, referencing objects or variables in the HTML DOM from your Silverlight scripting or vice versa can be done informally, because the script is interpreted by the same browser script engine and could potentially exist in the same scope. In the managed API, a more formal separation exists because the managed code is used by the Silverlight core libraries and its CLR, not by the browser. To interact with the DOM from the managed API, you can use a series of features that are sometimes collectively referred to as the HTML bridge, or HTML DOM bridge. These include the following:
APIs that expose the commonly used parts of the DOM (for instance, the Document object) to managed code.
Facilities that can make your managed types scriptable from the DOM.
Conversion techniques for generating managed types from marshaled JavaScript values or objects.
APIs that specifically expose the Silverlight plug-in's object representation in the DOM.
For more information, see HTML Bridge: Interaction Between HTML and Managed Code or Silverlight Programming Models, XAML, and the HTML DOM.