Leading technology-code reuse in WPF and Silverlight 2

This column is based on the pre-release version of Silverlight 2. All the information in this article may be changed.

Directory

WPF compatibility with Silverlight 2

Introduction to the Visual state Manager

Share Code

Inference about WPF applications

Writing cross-platform WPF code

Analyzing managed code

Get policies for critical code

Sample Analysis

Final considerations

In Silverlight 2, you can use Extensible Application Markup Language (XAML) to design and render the user interface. At the same time, you can take advantage of the built-in core CLR to handle managed code within the browser. Such a web-based Silverlight 2 application becomes very similar to a desktop Windows presentation Foundation (WPF) application. One of the benefits of a similar programming model is that code can be easily reused between the two. In this column, I'll describe several patterns that are the easiest to share code and XAML markup between Silverlight 2 and WPF.

The CoreCLR in Silverlight

Silverlight 2 does contain a CLR, but it is not the CLR used by other. NET applications and Assemblies. The Silverlight CLR, also known as CORECLR, is designed with full consideration for different uses. Designed for Cross-platform interoperability, CORECLR can run with the CLR and support different security models and different versions of the underlying class library. This is explained in detail in the August 2008 excellent column, "Comprehensive and thorough analysis of the CLR" (see msdn.microsoft.com/magazine/cc721609).

The use of different CLR by Silverlight and. NET applications means that you cannot reference the same assembly in two projects for. NET applications and Silverlight applications. The main problem is on the mscorlib assembly. The set of features required for Silverlight to work properly is very small-just the kernel. But any. NET assembly is linked to the standard version of mscorlib, which is the problem.

In the sample application discussed in this column, I used an interface to share Windows presentation Foundation applications with Silverlight applications. The only workaround is to copy C # and interface definitions between two projects because you do not have a common referenced assembly, so in the. NET Framework version, it is necessary to divide the functionality within the standard mscorlib assembly into two parts: kernel and desktop transactions for Silverlight and Provides the basis for binary compatibility between. NET assemblies.

WPF compatibility with Silverlight 2

Following the introduction of Silverlight 2, XAML quietly becomes the API for the next generation of UI modules. Silverlight 2 supports a subset of the full WPF framework, including rich layout management, data binding, styling, media, animation, graphics, and template features.

However, XAML is fully supported within Silverlight 2 by the size limit of the downloadable plug-ins. In only a few megabytes (less than 5MB in Beta 2), Silverlight 2 Plug-ins must provide the core CLR, which includes a subset of WPF and Windows communication Foundation (WCF) client platforms, a XAML parser, and a large number of The Microsoft. NET Framework for Silverlight-specific controls 3.5.

The WPF 3D graphics feature is not supported in Silverlight 2, and some of these properties and elements have also been discarded or trimmed. To sum up, you already have a compatible subset, so you can create a more complex WPF user interface for the Silverlight version. Later, I'll go back to the key parts of compatibility.

Note that while Microsoft has added some new APIs to Silverlight, they are not currently functional in the desktop version of WPF. The most relevant features include controls such as DataGrid and classes (such as WebClient for simple get-style network calls). These features will also be added to WPF.

Introduction to the Visual state Manager

Another great feature that comes with Silverlight 2 is added to WPF-the visual state manager for the control (VSM). VSM simplifies the development of interactive control templates by introducing visual state and state transitions. Because of the introduction of WPF, developers can customize the appearance and behavior of WPF controls through templates and styles. For example, you can't just change the shape and appearance of a control, but you should also define a new behavior or animation when the control clicks, gets, or loses focus.

With VSM, visual state and state transitions will do some of the work for you. Typical VSM visual states are normal, hover, disable, and gain focus. You can define a style or shape for each of these states. State transitions are used to define how a control transitions from one state to another visual state. You can usually define transformations by animating them. At run time, Silverlight will play the appropriate animation and apply the specified style to smoothly transition the control from one state to another state.

To define the visual state, insert a tag fragment in the control template, as follows:

<vsm:VisualStateManager.VisualStateGroups>
　<vsm:VisualStateGroup x:Name="CommonStates">
　　<vsm:VisualState x:Name="MouseOver">
　　　<Storyboard>
　　　　...
　　　</Storyboard>
　　</vsm:VisualState>
　</vsm:VisualStateGroup>
</vsm:VisualStateManager.VisualStateGroups>

Each control defines one or more sets of states, such as CommonStates and FocusStates. Each group defines specific visual states, such as "MouseOver", "pressed", and "Checked". For transitions between each visual state and state, you can define a storyboard that Silverlight can play automatically at the right time.

In short, WPF has many features that are not supported by Silverlight 2, and many of the features in Silverlight 2 are not available in WPF. To a large extent, these differences affect XAML-level compatibility. You can use a common subset for full compatibility, and thankfully, it's enough to guarantee that you can perform almost any operation.