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

Answer 1

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 2

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 3

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 4

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 5

• 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

Answer 6

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