At PDC the WPF Tookit was made available which provides several new controls to WPF to help bring even more compatibility to the WPF and Silverlight story. The new controls were the DatePicker, Calendar, DataGrid and the VisualStateManager concept to WPF. Ribbon controls were also provided to the WPF Toolkit, but are not covered here.
With the introduction of this toolkit, developers now have a way to get some even more common XAML code-base between projects.
Let’s take a look at a very simple example of both UI and code sharing with WPF and Silverlight. Here’s the simple scenario. I’m going to use a common “Customer” class that I want to use in both a WPF and Silverlight implementation. Since there is no binary compatibility for Silverlight and WPF, I’m going to maintain source-level compatibility. In order to do this, I’m going to create a Silverlight Class Library project and implement my Customer class in that…here’s my simple customer class:
Now in my Silverlight project and my WPF application I add a linked file to that class library for customer. While not binary compat, each time I compile I’m using a common source compat for both projects. Here’s what my project structure looks like and you can see the linked source code:
Now in my WPF project I want to add some XAML, so I’ll add this to my Window1.xaml:
Here’s the backing source code logic for the simple windows app:
Now in my Silverlight project I’m going to paste the same XAML:
and here’s the Silverlight source code logic as well:
So if you have a keen eye you’ll see it’s not full cut/paste as you note the xmlns declarations in the root control. Since the implementations are in two different assemblies (System.Windows.Controls.dll for Silverlight and Microsoft.Windows.Controls.dll for WPF Toolkit) we have to make sure they are referenced accordingly. We can still use the same prefix though of “controls” so that we have greater re-use across our XAML. For DataGrid, we need to do an additional step since for Silverlight it is on its own assembly.
If we run these applications here is what we get:
Sure we had to do some maneuvering (xmlns stuff) but if you have some great XAML/code you can still get some good re-use out of those implementations with little effort and share code!
So what about VisualStateManager? How do you use that in WPF if you already have something in Silverlight? Let’s simplify it to the most common/basic control – Button. Using Blend we’ve styled a simple Button control and Blend has generated the appropriate VSM resources for us (note that I am not a designer and just used Blend to quickly make 2 changes that probably look horrible :-):
There is nothing more we have to do in Silverlight since VSM is a part of the core. We just annotate our Button with the style:
Now in WPF we can use those same resources by adding them to our Grid.Resources node in our Window1.xaml file. The thing is that we don’t need the vsm: prefix. A simple find/replace removes them and we have our style button. The resulting full XAML for the style looks the exact same (minus any vsm: prefix) and the XAML for the button also looks the same.
I think there has to be a better way to use linked files here as well, so I’ll think about that and report back if I find one. I know this is a very simple demonstration of only a bit beyond Hello World, but I hope at least it gets you thinking of how you can get source-level compatibility and some XAML re-use out of your Silverlight and WPF applications.
What are your thoughts? Have you found better ways? What are the stumbling blocks you are facing in code sharing?
Please enjoy some of these other recent posts...