Multitargeting of WPF and Silverlight using PRISM

In my last job, I had change to lead a multitargeting project from an existing Silverlight solution to WPF one working together. Then, I will try to arrange all useful info that I needed regarding all this.


The first thing that we have to introduce is: What is Multitargeting and what is not Multitargeting:

- What is it? It is the possibility to build a solution in both WPF and Silverlight approachs with minor effort. So, the output of this work is to have an application in WPF AND an application in Silverlight.

- What is not it? The result is not a new application where you will be able to build separate components in either WPF or Silverlight within a whole unique application. This means you will have a separated application in WPF and Silverlight, not an unique application where you can include components either WPF or Silverlight.

Previously, a question, that you have to ask yourself, is: Do you want to adapt a wpf project to Silverlight or a Silverlight project to wpf? My suggestion is a Silverlight to WPF because, as everyone should know, Silverlight is just a subset of WPF, then if you build an application with limitations, we won't need a lot of adaptations.

Well, let we begin. The first thing, that I suggest, is to download the Project Linker adding for Visual Studio. This tool helps you to synchronize both type of projects. There are a lot of guides for it but, mainly, if you start with a Silverlight project (as I have suggested above), you have to create the WPF project alternative for it, open the contextual menu for this new wpf project by clicking on right button and then click on Add project link. After, you have to select the Silverlight project for this wpf project and that's all. When you make some change in the Silverlight project, automatically, this change will appear in the wpf one.

Of course, this has some limitations. The xaml's files won't be synchronised. This is because the xaml in Silverlight and WPF are huge differents because they have different compilers. Anyway there are some tips to solve them and we will talk about them below.

Another issue, with minor importance, is that if you linked project already had some files, these files are not synchronized, only the new or remove ones. A workaround, for this, is unload the linked project using its contextual menu and load it again by showing all files in solution. If you do this, all old files will be synchronized in the new alternative project.

Here, I have listed some equivalences in WPF and Silverlight that I will increase with some other that I find:

- Root element:

In Silverlight: Surely, it is an UserControl.

Application.Current.Host

In WPF: It is a Window control.

 Application.Current.StartupUri

- Toolkit control:

In Silverlight (Silverlight toolkit):

using System.Windows.Controls;

In WPF (WPF toolkit, if you want to use the ChildWindow also here, you will need to download the extended wpf toolkit):

using Microsoft.Windows.Controls;

- Differences in StorageFile behavior and controls.

Download the next document to find out them: http://wpfslguidance.codeplex.com/

For XAMLs, as I said above, Project Linker tool filters these files. You will have to add them manually as a link (add a new item and when you find the item, click on the cross icon and add it as a link).

The most issue for this, are the third party controls but if you use only the ones from the toolkit (Silverlight toolkit and WPF toolkit, remember to change the namespace property as I suggested above) you won't have a lot of issues by using a very interesting custom preprocessor. You will be able to find out more information in the next link: http://blogs.msdn.com/b/daviwil/archive/2009/05/25/a-custom-preprocessor-for-sharing-xaml-between-silverlight-and-wpf.aspx.

Basically, you will create a new WPF namespace that you will ignore in Silverlight but not in WPF thanks to mc:Ignorable tag and a preprocessor tool. Therefore, you will use this new WPF namespace to call to all controls or properties that you need.

And this is the end. With a little bit of work, you will have two applications in WPF and Silverlight sharing the code (as more as you use MVVM pattern) and even XAML. But never mind that even using these techniques in some point you will need to separate some files (you will thank to have partial classes :) )