How to develop applications targeting both Silverlight and WPF
Steve Porter, Consultant
10.07.2009
Rating: --- (out of 5)
|
With the release of Silverlight 2 and now Silverlight 3, the gap between Silverlight and Windows Presentation Foundation (WPF) has shrunk by a large margin. That gap does still exist though and there are many scenarios where a light browser-based interface, a heavy feature-rich desktop interface, or both is warranted. It's that last scenario, where both a Silverlight and WPF version of an application will be developed, that I will be covering in this tip.
Linked files in Visual Studio
Sharing physical files by linking is a great feature of Visual Studio and without it we wouldn't get very far with sharing UI or code. This feature will come in handy whether you are developing an application, targeting Silverlight and WPF, or just want to organize some files shared among various projects. In practice you add an existing item to a project as a link much the same way you add a copy of an existing item. The "Add as Link" option is available in the "Add" dropdown of the "Add Existing Item" modal dialog.
Now instead of your project containing a physical copy of the existing item, it contains just a logical link to the physical location of the existing file. From this point forward, changes made to the file via either the primary or secondary project will be reflected in the other project. It's also worthwhile to note that there is nothing preventing a file from being shared with more than one project.
Sharing UI: User controls
When I think about developing application targeting two platforms I often jump straight to sharing code and forget about the user interface, but a sharable UI is an important part of the Silverlight/WPF story. In the past it has been pretty straight forward to share design artifacts such as images and videos. Now with XAML you can ta...
To continue reading for free, register below or login
To read more you must become a member of SearchWinDevelopment.com
ke a big step forward sharing part or the entire actual application user interface. Most likely you won't be able to and won't want to share the entire user interface between Silverlight and WPF; this is why user controls are such a fit for the scenario.
User controls already provide a level of modularity for your UI. If you keep that modularity in mind when designing your application you will be able to get a large amount of reuse from user controls. To achieve this there are two main themes to keep in mind. One is to stick with the subset of XAML that Silverlight supports. You will find this to be very doable with the XAML support in the latest versions of Silverlight and when there is an exception there will just be a piece of your UI that remains separate for the two platforms. The second theme is to place little or no code in the code-behind file associated with your user control. This is a best practice in general and part of the MVVM design pattern, so it will make your life much easier in the long run.
Sharing code: Preprocessor directives, partial classes, and extension methods
I guarantee that your application will have some functionality that will be implemented differently in Silverlight versus WPF. An example would be the "Open File Dialog" where the Silverlight implementation is just different enough to force you to implement it for both platforms. These cases are certainly not showstoppers as there are several techniques you can use to cordon off these implementations from shared code.
Probably the most used technique, since it has been around longest, is preprocessor directives. Preprocessor directives are embedded commands allowing you to instruct the compiler to conditionally compile certain sections of code. Silverlight already has defined a Boolean preprocessor directive symbol for allowing you to know when an application is being compiled for Silverlight. Using this technique, all Silverlight code would be placed in an If statement checking the SILVERLIGHT symbol and any WPF code would be placed in the Else branch of the If statement.
Using preprocessor directives is an easy solution but is not my favorite because you end up with both Silverlight and WPF code sections intermingled within the same files and classes. A much more elegant and better organized technique is to use partial classes to separate shared code from platform specific code. Starting with version 2.0, the .Net framework implemented a feature called partial classes. Prior to compile time, partial class functionality allows the implementation for a since class to be separated into several "partial" classes split over several files. In a Silverlight/WPF scenario, this allows you to have functionality specific to each platform implemented via partial classes in separate files. All shared code would remain in one physical file linked between the projects and at compile time the platform specific implementation would be injected into single classes.
Conclusion
Using the techniques described in this tip you will be able to easily write applications targeting both the Silverlight and WPF platforms sharing much of your UI and application code. Taking the concept of UI and code reuse further there are several more techniques, extension methods for example, and coding practices that will allow you to squeeze out even more shared UI and code between the Silverlight and WPF platforms.
About the author
Steven Porter is a Senior Consultant and Project Manager for Wintellect, a consulting/debugging and training firm founded by industry experts Jeff Prosise, Jeffrey Richter, and John Robbins. He specializes in technologies such as ASP.NET, ASP.NET Ajax, Silverlight, and WPF. Steve is a Microsoft MVP in Client Application Development and a frequent speaker at events such as user groups and code camps on topics ranging from Silverlight and WPF to Windows Communications Foundation.
|
|
|
|
|
|
