Advance Planning Your Application

The absolute first step in advance planning your application is to conclusively determine whether or not you do, in fact, need both a Silverlight and a WPF version of your solutions. If one or the other type of solution can satisfy your needs, you can save a considerable amount of work by building only one solution instead of two. Moreover, by using only one technology you can take advantage of those features in that technology which are incompatible, either in whole or in part, with the alternate technology.

Assuming you do need both, next you'll need to identify where the structural differences between WPF and Silverlight may impact your particular project. This is especially true if neither the WPF nor Silverlight solutions have yet been significantly completed since advance planning may reduce the effort required to achieve multiple working solutions. For example, consider items which can be implemented in more than one way, one or more of which is not available in the other type of technology but one or more of which will work in both technologies. A good illustration of this point is inline content which in WPF can be implemented in the following fashion: <Button> my content </Button> While this implementation will not work in Silverlight, an alternative implementation which specifies content as an attribute will work in both technologies: <Button Content="my content" />. Similarly, while both WPF and Silverlight permit the application of a Style to a particular element by referencing the Style via its Key, only WPF allows for implicit styles to be applied using the TargetType attribute.

The next key decision which is required will be whether to start with a Silverlight project or with a WPF project. My recommendation is that with only rare exceptions it will be preferable to start with a Silverlight project. Since Silverlight is a subset of WPF, those application features which you are able to implement in Silverlight you'll almost undoubtedly be able to be implement in an identical or similar fashion in WPF.

Joint Development Guidelines

One obvious method for improving long term maintainability for two different versions of an application is to share files between the two projects. This can be achieved by creating the file in one project and then adding it as a link in the other project, rather than adding a copy as is the normal practice when adding an existing item.

Figure 4. This screenshot shows how to add a file as a link instead of as a copy.

Sharing a file in two different projects is not without its problems, however, since as has been discussed above, there are differences between what code will work in Silverlight and in WPF. In some cases, this can be resolved by using conditional compilation.

#if SILVERLIGHT
//Silverlight compatible code goes here
#else
//WPF compatible code goes here
#endif

While conditional compilation is only applicable to code behind and not to XAML, fortunately the area of XAML tends to have fewer incompatibilities between the two technologies.

In February (2009), Microsoft's Patterns and Practices group released Prism v2, a Composite Application Guidance for WPF and Silverlight. Prism v2 consists of a reusable code library, a reference (sample) implementation and documentation including various QuickStarts and Hands-On Labs. The collective purpose of these items is to assist developers in creating modular applications in either or both WPF and Silverlight. In this context the term modular application is intended to refer to an application consisting of a number of discrete, loosely coupled, independently evolvable pieces which interact with each other within the overall application. The premise here is that these modules can be individually developed, tested and deployed by different individuals or sub-teams and that these modules can later be modified or extended with new functionality more easily than a "monolithic" application.

While the initial version of Prism targeted only WPF, Version 2 is intended to apply to both WPF and Silverlight. The Prism V2 code libraries have been designed to permit the maximum degree of code sharing between WPF and Silverlight. Moreover, the reference implementation and the associated documentation are intended to provide explicit guidance and sample code focused on jointly developed WPF / Silverlight applications.

Post Development Conversion Guidelines

In the event that you are facing a situation where a project based on one technology is either complete or at least mostly complete and you have been asked to create a solution based on the alternate technology, a decision must be made as to whether to try to make a copy of the existing solution and mark it up or, alternatively, to start with a brand new solution and copy and paste in code from the existing solution as necessary. One advantage of using a fresh solution is that the applicable template from which the project type is created uses all the correct project settings whereas modifying an existing solution forces you to manually make (but hopefully understand), the changes required by these differences. If this is a "one off" conversion, it will likely be easier to begin with a new solution but if you expect to do this on multiple occasions, there is likely an advantage to forcing yourself to learn about the differences at the outset.

Summary

Anyone hoping for a painless, flip a switch, conversion between WPF and Silverlight is certain to be disappointed. Any conversion, regardless of the direction, or joint development will require considerable advance planning and implementation effort. However, if you follow the proper strategy and procedures, the process is quite feasible.

My recommended checklist consists of the following steps:

• Determine whether joint development or conversion from one technology to the other really is desirable by carefully reviewing the scenarios for which WPF and Silverlight applications are most suitable.



• Review the areas where differences exist between Silverlight and WPF—in particular, review in detail the list of these differences provided by the MSDN Help Files.



• Based on this review, determine in general terms where the differences between Silverlight and WPF would be applicable to your project.



• For new development, decide whether to begin with a Silverlight project first or a WPF project first (normally you should choose the Silverlight first option).



• Then decide how many, if any, files can be shared between the two projects.



• Give careful consideration to whether to permit any divergence between the capabilities of the two projects in order to take advantage of any features available in one technology but not the other. While these exceptions should be kept to a minimum, in some instances the benefits of implementing such a feature may be sufficiently compelling to accept the variance between the different versions of your application.



• For converting an existing application to the other technology, decide on whether to create a new (fresh) project and copy and paste in portions of your existing code or whether to make a copy of your existing project and marking up that copy.

Links

Microsoft Silverlight, WPF and the Microsoft .NET Framework: Sharing Skills and Code (PDC 2008 Video by Ian Ellison-Taylor, General Manager for Microsoft's Presentation Platforms and Tools Team)

Silverlight-WPF Compatibility (MSDN Help File)

Silverlight Data Binding (Tutorial by Jesse Liberty and Tim Heuer)

Porting the Silverlight Dive Log Application to WPF (Blog article by Jonas Folleso)

Single Sourcing WPF and Silverlight (Blog article by Stefan Olson)

Silverlight Problems That Affect Me (Blog article about WPF / Silverlight Differences by Rob Eisenberg—dated)

Porting Silverlight 2.0 to WPF (Blog article by Mike Tucker—dated)

* This article was commissioned by and prepared for Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.