What .Net/WPF features do you miss when working in Silverlight? [closed]

Question

I recently started working with Silverlight and immediately noticed the difference between the Silverlight BCL and the full .Net and WPF. For some of them I've found great solutions posted online by other developers, and others were more complicated. What features/classes were you surprised/disappointed to find absent from the Silverlight class libraries, and what did you do to work around them?

Some of mine were:

1. No event triggered animations - I created a helper class with static methods for attaching each type of animation I've used to storyboards in a shared library, and at the application level I create classes with static methods to put them all together as I would have in XAML if working in WPF. So far, this has been a good solution for keeping my animations organized and the logic out of my event handlers.
2. ScrollViewer doesn't support the mouse wheel - Adam Cooper created an excellent class library that adds this functionality that requires the bare minimum of code to implement in any Silverlight project. His site seems to be down at the moment, so here's a link to Tim Heuer's blog that explains and links to it (so it'll be available when his site is back online). Add mouse wheel support to ScrollViewer in Silverlight
3. SortedDictionary<T, K> is missing. I found this post that contains an implementation, but I didn't end up using it myself.
4. ResourceDictionary.MergedDictionaries is not available - Again...found someone who implemented this and posted the source code, but it seemed to be a little complicated. I'll probably work through it a little bit, but have yet to do so. MergedDictionaries in Silverlight
5. ZIndex attached property is only available on the Canvas object. I posted this as a question here on SO, and someone made a great suggestion to wrap my containers in a collection if that's what it takes. It feels a little sloppy, but you gotta do what you gotta do. My containers are nested three levels deep, so I may need to warp them all in Canvas objects and set the Canvas.ZIndex three times for each event. Ugly as sin, but if it's the only way, then so be it.

I'm interested to see what other common issues the more experienced Silverlight developers have come across and what you've done to fix them.

Answer 1

Where do I begin? :)

• No MultiBinding
• No ElementName= binding
• TemplateBinding can only refer to direct properties, not attached DP's
• No RelativeSource binding
• No binding to child properties - e.g, {Binding Path=Foo.Bar[0].Baz}
• No ability to subscribe to changed events on any arbitrary dependency property - the class author has to explicitly define an event (and in most cases, only one or two properties in SL controls actually do)
• The Visual State Manager requires the control author to know all style-able states when the control is written, which completely breaks the "extension through styles/templates, not inheritance" story that WPF promotes
• No Adorners
• No Navigation
• No dependency property inheritance
• No/sucky support for external ResourceDictionaries/merged dictionaries
• Validation story sucks (it's only marginally better in WPF)
• Printing
• <Setter .. Value="{Binding ...}" /> is not supported

On top of that a number of method signatures changed for no good reason. E.g., IIRC, the overloads for Dispatcher.Invoke are different, instead of SL just ignoring the parameters it can't yet handle. Or as another example, ObservableCollection in WPF can raise Add, Remove, Replace and Move events - in SL it's only the first three.

Since I write code to work on both platforms, the code ends up being littered in strategy patterns and #ifdefs. Feels like C++ all over again :-)

Answer 2

In addition to Paul Stovell's excellent list:

• No custom markup extensions.
• No x:Type markup extension.
• No LayoutTransform (though there are workarounds).
• No convenience metadata for DependencyProperties (have to manually define measure/arrange/render invalidation, property changes, etc).
• No light-weight Drawing or DrawingContext classes (have to use Shape elements).
• No commands.