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: 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.