MSDN Magazine - October 2008 - (Page 35) the requirements of the Silverlight XAML parser. This task largely benefits from the high level of compatibility between the two syntaxes. Most of the time, adjusting XAML is a matter of fixing a few elements and attributes. Let me provide a couple of examples. Desktop WPF features a element that Silverlight doesn’t recognize. When porting this markup to Silverlight, you have to find a workaround for the label. A rectangle with a text block inside may be a workable solution. In WPF, you can associate a tooltip with controls using the ToolTip attribute, as you see in the following: performance problems that could be caused by the richer object model. The key fact to remember is that Silverlight supports a subset of the possibilities offered by desktop WPF; it is up to you to devise a cross-platform solution by choosing the appropriate features. Writing Cross-Platform WPF Code In Silverlight 2, the ToolTip attribute is not supported. You have to resort to the ToolTipService, as in the following code snippet: It should be noted that both solutions work in desktop WPF. In addition, the ToolTipService offers a number of additional tooltip properties in desktop WPF such as placement, offset, initial delay, and duration. However, none of these extra properties are supported by Silverlight. Are these all of the compatibility issues between WPF and Silverlight? It depends on how you use WPF. In general, porting a nontrivial WPF application to Silverlight is difficult and not really even a primary goal. To begin with, in Silverlight 2 you do not have triggers everywhere you might need them. For example, there is a Triggers collection on UI elements—descendants of FrameworkElement—but not in styles, data, and control templates. Likewise, data binding is supported in Silverlight but not in the same manner as it is in WPF. For example, you have the Binding element, you have data context, data templates, and observable collections. As mentioned, you have no triggers and a simplified XAML markup that requires you to write code more often than in WPF. Plus, the internal implementation is quite different. The Binding object in Silverlight has much fewer properties than in WPF. Globalization is another area that might cause Analyzing Managed Code you headaches. For performance reasons, the For some reason, code reuse between WPF core CLR doesn’t include its own globalization and Silverlight is perceived to be a XAML data for all supported cultures. Instead, the Culproblem. As mentioned, you do have some tureInfo class in Silverlight relies on the global- Figure 1 A Sample WPF Application XAML issues when adapting your code, but ization functionality provided by the the biggest challenge is the codeunderlying operating system. This behind class. means that there’s no way for you In both Windows and Silverlight, to give applications the same gloa XAML file is paired with a codebalization settings across different behind class written in C# or another operating systems. managed language. Unfortunately, Finally, WPF has a richer set of these codebehind classes target difcontrols that are not available in ferent versions of the .NET FrameSilverlight. A good example is the work. The desktop version of WPF RichTextBox control. relies on the full base class library In summary, porting a Silverlight (BCL) of the .NET Framework 3.5, application to WPF is relatively while Silverlight 2 uses a lightweight trivial, although as a developer you version of the BCL. should be concerned with possible Figure 2 A WPF Application Adapted for Silverlight The Silverlight version of the BCL msdnmagazine.com The easiest way to port code from WPF projects to Silverlight projects is through user controls. Aside from a distinct XML namespace and markup differences, a user control is the only way to share markup and code between desktop and Web-based WPF. If your WPF application is natively organized, or can be refactored, to make extensive use of user controls, porting code to Silverlight will be much easier than the other, less appealing, option of cutting and pasting. So can assemblies be shared between WPF and Silverlight projects? In Silverlight 2, you can certainly create custom class libraries packed into assemblies. However, you should be aware that these libraries target the Silverlight version of the .NET Framework and use a different security model (for more, see this month’s installment of CLR Inside Out at msdn.microsoft.com/magazine/cc765416). Any assemblies you use in a desktop WPF application must be recompiled as Silverlight class libraries to ensure that they refer to the correct assemblies and make legal calls to classes. Needless to say, this process of recompiling may generate additional work to fix calls to unsupported classes. In summary, with a bit of work you can certainly take a WPF application and expose it over the Web through Silverlight. And when you do so, you are actually exposing your code over a number of non-Windows platforms without forcing clients to have the full .NET Framework installed. Figure 1 shows a simple WPF standalone desktop application. Figure 2 shows the same application hosted in Internet Explorer through Silverlight. October 2008 35 http://msdn.microsoft.com/magazine/cc765416 http://www.msdnmagazine.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.