WPF and Silverlight Toolkit Compatibility

General Compat Thoughts

The majority of the controls in the Silverlight Toolkit November 2008 (PDC) release are Silverlight versions of controls already present in WPF.

These "WPF Parity" controls include:

  • DockPanel
  • WrapPanel
  • ViewBox
  • Label
  • Expander
  • TreeView
  • HeaderedContentControl
  • HeaderedItemsControl

We focused heavily on API compatibility for these controls, only making changes (I'm actually not sure if there were any) for things that aren't currently possible on the Silverlight 2 runtime.  And some things, like supporting Visual State Manager, required internal changes that made the process more complicated than just copying the existing WPF code. 

We did leverage the WPF control specs and use the WPF controls behavior as our guidelines, and we were pretty hard-core about making sure the Silverlight Toolkit control's API was a strict subset of the corresponding WPF control's API.  One of the primary compatibility goals was also to enable sharing of design assets, via VSM between WPF and Silverlight with minimal changes, and this enables that as well.

Even so, the controls aren't "strictly" compatible for two main reasons:

  1. CLR Namespace: All of the Silverlight Toolkit controls are in the Microsoft.* namespace instead of the System.* namespace.  We made this change for a variety of reasons, some of which I mentioned in a prior post.  Basically we want our "out-of-band" controls to be in "Microsoft.*" and the platform ones (e.g. in the core runtime) to be "System.*".  The main benefit of this is that when/if we decide to move controls into the runtime they will NEVER collide with the existing ones and therefore won't break any applications.  This then is an opt-in model for developers for when they want to swap over to the runtime controls
  2. XML Namespace: Silverlight doesn't currently support the same XML namespace semantics that WPF does.  In WPF you can use the XmlnsDefinitionAttribute to "collapse" multiple CLR namespaces into a single XML namespace.  Silverlight's parser doesn't currently support this, hence the need to have a separate XML namespace for each CLR Namespace + Assembly pairing, and you need to have a prefix for that in your XAML.

The upshot of all of this is that, to move your code from Silverlight to WPF, for the "parity" controls listed above, you'll need to do two things:

  1. Change your using/Imports* clause to be System.Windows.Controls from Microsoft.Windows.Controls.
  2. Remove the xmlns declaration and the prefixes from the XAML. So  <controls:DockPanel /> becomes <DockPanel/>, for example.

The constraints outlined above made it difficult to make compat "Just Work" at this point in time.  Doing so would have required a set of complex tooling changes and too many "moving parts" that could result in broken applications or versioning issues.  As such, our main goal was to make this compatibility experience simple, consistent, understandable, and something the compiler can help you with.  All of which tend to be my preferences in most cases.  It's much easier for us to implement and deliver, while being easy for developers to manage.  At some point we may add some help to automate this if developers do have trouble with it.

How Compat Affects The Silverlight Toolkit

Which brings me to the point of all of this.

Looking at the CodePlex IssueTracker, there are quite a few issues reported that are more feature requests than bugs.  Unfortunately, many of these are things that we can't do without affecting the "subset" compat that I mentioned below.

For example, there are several of these relating to the the TreeView:

TreeView: Drag & Drop, Inline Node Editing

TreeView: Ability to Cancel TreeViewItem Selection

TreeView: Showing Connecting Lines in TreeView

We are having some conversations about how to handle this.  The optimal solution would be for us to be able to have a derived TreeView class that does all this stuff, that we can then port back over to WPF so the same "extended" functionality works there.  Another option would be to write a separate "TreeViewEx" that does this, but that brings with it the potential for a lot of confusion and duplication.  And in both cases, we're investigating how many of these modifications can coexist peacefully.  We're still investigating.

In any case, this is an area where we're happy to take feedback on or any other ideas about how best to handle this.


* when controls move from the Toolkit such that a control exists in both places for some amount of time you may need to do an explicit "using DockPanel = System.Windows.Controls.DockPanel;" disambiguation.

Comments (5)
  1. In this issue: Silverlight Girl, Mehdi Slaoui Andaloussi, David Anson, Cheryl, Justin Angel, Kathy Kam

  2. davidjjon77 says:

    Hi Shawn,

    Even though WPF is larger and older than Silverlight, it is my opinion that Silverlight will be far more important than WPF in the future and therefore Silverlight should drive the design of WPF and not allow WPF compatibility to cause inferior design decisions in Silverlight.  I do feel that Silverlight WPF compatibility is important but I strongly feel that WPF should be the product making the compromises going forward.

    David Roh


  3. Colin Blair says:

    I think I have to agree with David here. I am not worried about the Microsoft.* controls not matching the System.* controls. I do care that the System.* controls match each other and that the Microsoft.* controls match each other. The way to completely fix the compatibility problems you already have it to just go ahead and create a set of WPF controls in the Microsoft.* namespace. Then you can add new features to the Silverlight control and at least stub in the methods and properties on the WPF side to make sure that the XAML is staying compatible.

  4. Good feedback – thanks everyone.

Comments are closed.

Skip to main content