Thursday, March 31, 2011

Building WPF and Silverlight Applications with a Single Code Base Using Prism

Contents
Composite Application Guidance for WPF and Silverlight, also affectionately known as Prism v2, has been out for several months now. One of the areas Prism provides guidance on is the ability to target your application to both Windows Presentation Foundation (WPF) and Silverlight. It's interesting that, initially, this part of our guidance met quite a bit of resistance. Why were we focusing on multi-targeting for the first couple of iterations when we could be spending our time giving guidance on composition? But since the release of the Prism v2 project, we've found that a lot of our customers really love this part of the guidance. They especially like the Project Linker tool we built to help multi-targeting; as basic as it is, the tool has been well received and is being used in ways we couldn't have imagined.
So let's look at the approach we took for writing multi-targeted applications and how Prism can help you do the same.

Introduction

When we started work on Prism v2, in August 2008, we knew we wanted to support both WPF and Silverlight. Silverlight makes big strides toward closing the gap between the power of a rich-client application and the reach and ease of deployment of a Web application. The first version of Prism targets only WPF, but since WPF and Silverlight are very similar, we knew it wouldn't be too hard to create a Silverlight version. And since Prism helps in writing loosely coupled, modular applications, we felt that Prism could also help in allowing you to write applications that target both WPF and Silverlight from a single code base. The challenge is, of course, that although WPF and Silverlight are similar, they are not binary-compatible. The API and XAML language itself also has minor differences that make it harder to multi-target.

What Is Multi-Targeting and Why Should You Care?

Multi-targeting is the ability to target multiple platforms from a single code base. In this case, we are talking about targeting both the normal desktop version of the Microsoft .NET Framework version 3.5, which contains WPF and the Silverlight version of the .NET Framework.
So why should you care about this capability? The most obvious reason would be that you would like to take advantage of the strengths of WPF and Silverlight. In WPF, you can build applications that make full use of the client platform and interact with existing applications, such as Microsoft Office. It's also a lot easier to reuse existing assets, such as through COM interop or Windows Forms interop.
Whereas WPF gives you more capabilities, Silverlight gives you a much broader reach, because it runs on multiple platforms. It also runs in a protected sandbox, so end users can safely install Silverlight without needing administrative privileges. You don't need to completely multi-target your application to make it worthwhile. For example, you might expose small parts of internal applications over the Internet to give customers the ability to view and change some of their own information.

Creating a Silverlight Version of Prism

Even though we felt that multi-targeting would be a valuable capability for our customers, we also had a somewhat selfish reason for creating it. We wanted to build a Silverlight version of Prism, but we didn't want the overhead of maintaining two code bases. Because we didn't know how much code we would be able to reuse, we did a couple of spikes. A spike (in "agile" terminology) is a time-boxed exploration that allows you to learn more about a problem domain so that you can make a more valid estimation. So we did a couple of spikes to see how much of the Prism v1 code base we could migrate to Silverlight and how hard it would be to port our code to Silverlight. The conclusion was fascinating. We estimated that we could reuse around 80 percent of the code in the Prism library without modifying it.

Read more: MSDN
Tags: , ,