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:
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:
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:
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.
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.
PingBack from http://www.tmao.info/wpf-and-silverlight-toolkit-compatibility/
In this issue: Silverlight Girl, Mehdi Slaoui Andaloussi, David Anson, Cheryl, Justin Angel, Kathy Kam
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.
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.
Good feedback - thanks everyone.