11

I have done one full project using WPF, and have (at least) a pretty good grasp of the main concepts, like XAML, Databinding, and MVVM. We did everything "by hand"--we did not use an MVVM framework or third-party tools. All XAML was written by hand as well (no Blend).

The new project I will start in a few weeks is pretty heavy-duty Silverlight, and I'm looking to get up to speed as quickly as possible. However most of the articles I've read on getting started with SL focus on XAML and databinding. Since my introduction to these concepts is still very fresh in my memory, I can certainly understand why these tutorials would spend a lot of time on these subjects--the learning curve can be very steep. However these are concepts that I am already familiar with, and find myself having to wade through a lot of covered ground to learn anything new and compelling.

So what I'm looking for are advice on what I need to learn and understand to go from being a journeyman WPF'er to a journeyman Silverlight'er. This can be in the form of:

  • General Advice
  • Key Differences
  • Rules of Thumb
  • Resources/Links ("A WPFer's Guide to Silverlight" would be perfect :)
  • Major Pitfalls/Things to Watch Out For

Thanks in advance for any insight.

Phil Sandler
  • 27,544
  • 21
  • 86
  • 147

2 Answers2

9

Rob Eisenberg (creator of Caliburn and Caliburn Micro) has a series of blog posts that talks about porting a WPF application to Silverlight. This may give you some insight into some of the framework differences.

Day 1 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx

Day 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx

Day 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx

Day 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx

Day 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx

Day 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx

Day 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx

Day 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx

Some other thoughts off the top of my head:

  • Binding defaults to One-Way
  • No DynamicResource
  • TabControl is fairly different
  • No ability to define implicit DataTemplates for types
  • No CoerceValue in Dependency Properties
  • Event routing is very basic
  • No built-in command structure. You have the ICommand interface, and ButtonBase controls have a Command property, though there's no class that implements the ICommand interface.
  • Missing x:Static, x:Type
  • All service calls need to be on a different thread than the UI thread. This essentially requires you to learn / implement async programming strategies. See here and here.
  • As was mentioned, it's a different framework so not all libraries are available to you. Example: there is no XmlDocument - you have to use XElement (which is arguably better, though even so)
  • The Navigation framework is totally different than WPF. Stay away from it. It will only cause you pain. ;]
  • Several of the Controls that you find in the core framework in WPF you'll find in the Silverlight Toolkit. Download it, you'll need it.
  • No built-in Triggers, though can use behaviors / actions provided in the Blend SDK (which essentially gives you the same thing)
  • If you need to interact with a database, it will have to be through services hosted somewhere, or through COM (which means Silverlight 4 OOB with Elevated Permissions).
  • I disagree with Kevin in that testing is actually fairly easy and all of the major testing frameworks and mocking frameworks support Silverlight. Where you run into issues is Code Coverage. The Microsoft Testing framework supports Code Coverage (Premium & above) or else you can use dotCover. I believe newer versions of nCover supports Silverlight though I'm not 100% certain. Use StatLight to run your Silverlight tests (regardless of testing framework) from the command line.
  • If you're not already using an IoC container pick one up. Autofac, Ninject, StructureMap, Unity, MEF. (Another bias of mine ;])

I would highly suggest looking into the available MVVM frameworks. This has cut down a significant portion of the framework code I typically have to write. The frameworks will probably only get you 80% of what you need, though that's 80% you didn't have to write yourself. I'm currently partial to Caliburn Micro, though most of the popular ones will give you what you need.

I'll add more if I think of more. Good luck in your journey!

Joe McBride
  • 3,789
  • 2
  • 34
  • 38
  • I'm confused about "•All service calls need to be on a different thread than the UI thread." -- my understanding is that all calls must be async because they *can* be on the UI thread. – Gabe Nov 06 '10 at 06:52
  • Hey Gabe, here is a quote from Tomasz Janczuk, a dev on the Silverlight WCF team (link now in answer above). "WCF proxies in Silverlight applications use the SynchronizationContext of the thread from which the web service call is initiated to schedule the invocation of the async event handler when the response is received. When the web service call is initiated from the UI thread of a Silverlight application, the async event handler code will also execute on the UI thread." So WCF will marshal the call back to the UI Thread for you. However you're not allowed to have a blocking service op. – Joe McBride Nov 06 '10 at 07:10
2

I've really only done Silverlight for a real app...but one of my co-workers was a big WPF guy, and so I hear some of his gripes.

  • You're going to probably need to use a WCF service, etc., for asynchronous queries to your service/business layer
  • You're using a subset of the .NET framework, so you cannot include ANY of your class libraries as a reference, only Silverlight class libraries can be included. However, you can do stuff like having a 'link to existing file' in a silverlight library that links to a file in other libraries...as long as the code still compiles with only the reduced set. This is a bit of a maintenance nightmare, but if you are doing WPF & Silverlight with some of the same code, it will probably save you from a lot of replication. Make sure to make it a link to the file and not a copy of the file, or changes in one won't change the other.
  • Unit testing your ViewModels will not be as easy. Need to Moq your service and use a Silverlight unit testing project.
  • Some of the reduced functionality is annoying for WPF veterans.
  • I think our WPF guy complained about not being able to bind stuff like a CanExecute method as easily on his commands as he was able to do in WPF. He had to call the method directly from the command or something. (I've only gotten a chance to look at MVVM a little so far as I'm now on a different project :(, so not quite sure on that one).

Hope that helps a little.

Kevin Nelson
  • 7,613
  • 4
  • 31
  • 42