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

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

The biggest complaint I have is lack of full support for all the available WCF bindings. Only being able to use BasicHttpBinding very often means a silverlight solution to a problem isn't a valid choice.

Answer 2

No socket or UDP support is probably the biggest pain for me followed by the missing crypto classes.

In addition the missing classed like StringDictionary and ApplicationException that you get used to and then find aren't around are a pain. Generally it's possible to find a substitute or workaround but personally I'd rather the Silverlight download go from 5MB to 6MB so we didn't have to ;-).

One really handy trick I saw on a blog that allowed me to reuse my normal .Net assemblies was to add existing items as a link. In a number of cases now I have two project files using the same class files with one targetting .Net 3.5 and the other the Silverlight runtime. I'm extremely thankful I found that trick as I was already starting to go down the path of creating different code bases for .Net 3.5 and Silverlight!

Answer 3

No 3D support.

Answer 4

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

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 5

That's just crazy talk. - kidding -

Nice feedback. Just sent to the teams on your behalf.

-

Scott Barnes

Rich Platforms Product Manager

Microsoft.

Answer 6

As a designer, a lack of Event/Property triggers is so disempowering.

I'm no C#/oop guy so when I have to trigger a chain of storyboards when an item loads or a button is clicked or after another storyboard finishes, I have to call the devs in :(

Answer 7

Apparently commenting on felixthehat's comment required a certain reputation.

But I'd like to second his call for Event/Property triggers... The Triggers framework in WPF allows me to do really powerful things as a interaction designer without having to dive into the code. I miss it.

Answer 8

Here are some things I encountered when I converted a WPF app to Silverlight:

1. Enum class is different...Cannot do this in Silverlight (can in WPF) to bind to an Enum:

   HoleType1.ItemsSource = Enum.GetValues(typeof(Hole.HoleTypes));

2. Brush colors work differently...

WPF:

  protected Brush _CurrentHoleColor = Brushes.Red;

Silverlight:

  protected Brush _CurrentHoleColor = new SolidColorBrush(Colors.Red);

3 . Haven't worked this one out yet, but something is different about this WPF code which I had used to check where the mouse was clicked:

System.Windows.Media.VisualTreeHelper.HitTest(canvas1, p);

4 . I think something is slightly different about the overloads used for creating new threads with

this.Dispatcher.BeginInvoke(....)

Answer 9

Silverlight's immutable styles and lack of dictionary merging is also a big one - if you are writing controls, these two give you a lot of hassle - not to mention unmanageably large generic.xaml files.

Answer 10

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.

Answer 11

Perspective 3d is great, but I can't wait for real 3D!

Answer 12

• ScrollViewer has no change event (you have to use a binding hack)
• No browser-agnostic context menu support until version 4
• Limited DocumentFlow support
• No MD5 support (but the more modern hash algorithms instead)
• WebClient doesn't allow you to do HTTP authenticated requests.

My biggest peeve:

• A rat's nest of namespaces