1

I have been using WPF for a new project which is far from done. It's a hobby project and a very useful one.

I'd like to have cross-platform compatibility (i.e. Linux + Mac + Windows), but Windows is the primary target. I'm pretty good with web languages and C# and Erlang, but C/C++ are not among them and I hate Java. So it was a natural move to choose WPF for me.

However, after reading numerous sources like http://www.mono-project.com/WPF:

At this point, we strongly suggest that users interested in WPF adopt Silverlight instead as it can now be used outside of the browser and offers a rich set of cross platform APIs and features.

I'm starting to wonder if I should port my app to Silverlight and use it instead.

A couple of facts:

  • My application is pure desktop application and meant to be so. It needs lower level access to system resources (but not that low that .NET wouldn't be enough).
  • I'd like to have the three platforms support, but Windows is the primary concern.
  • I'd prefer C# and .NET and something equivalent to WPF where the UI is declarative, separated from code in a clean way and allows for rich user interfaces.

I've heard Silverlight works in Mac already, and support for Linux is possible via Moonlight.

Should I consider switching to Silverlight from WPF and what problems may arise?

Tower
  • 98,741
  • 129
  • 357
  • 507

2 Answers2

3

To start i'd consider this answer.

The main point is that (actually) Silverlight is a sub set of WPF, so if your application user base are PC/Window user only, you might want to develope your app in WPF because function wise it's still much richer than Silverlight and because it's a desktop application so you have all the access to the local machine. If you want to develop an application that is Web based runs on browser, not only on PC but also on Mac, then you want to develop in Silverlight.

In my opinion for your requests WPF remains the best choice.

Community
  • 1
  • 1
gliderkite
  • 8,828
  • 6
  • 44
  • 80
2

Well, from experience I can tell that some things won't work in Silverlight like they do in WPF. Some things I've encountered recently (although there are many more):

  • Bindings don't work exactly like you want. For instance, in WPF by default your bound property changes on keyUp on a text field. In Silverlight that's not the case: it will update on Blur. Frameworks like Caliburn.Micro fix this by adding this implicitly.
  • WPF has something called Adorners. These basically allow you to add small UI elements for things like resize, rotate, etc. Things you typically see in designers (drag to resize). You can make something like that in Silverlight, but it's a bit more complex.
  • I'm not sure about WPF, but in Silverlight a call to a webservice is eventually done on the UI thread. You can set it up wherever you want, but the actual call and callback is done on the mainthread. Something to keep in mind when dealing with a result from a web call which might take a while to execute (someone can correct me on this if I'm wrong).

I think the typical way you should work with a new application is start in Silverlight, and move to WPF if you really need to. Also, I've been told that it's slightly easier to port a Silverlight application to winRT/Metro, so that might be something you would want to check out.

Addition Here's a link from MSDN describing various differences: http://msdn.microsoft.com/en-us/library/cc903925%28v=vs.95%29.aspx

Erik van Brakel
  • 23,220
  • 2
  • 52
  • 66