Microsoft has indicated that the long-term goal is for Silverlight to be a true subset of WPF (which means WPF would be a true superset of Silverlight). That is not the case now, and won't be the case in .NET 4.0 or Silverlight 3.0.

So now, and into the foreseeable future these two technologies have large regions of overlapping functionality, but each have unique elements that are unavailable in the other technology. Clearly Silverlight is smaller and simpler, and WPF is larger and more complex.

To mitigate some of this today, you should get the SilverlightToolkit and WPFToolkit from CodePlex. And .NET 4.0 and SL 3.0 will help, but won't completely solve the mismatch.

Given all that, my default start position is, and will be, Silverlight. I'll only fall back to WPF if there's some specific requirement (business or technical) that prevents Silverlight from meeting my needs.

This is strategic. If Microsoft does achieve the true superset/subset goal, then you can't go wrong by targeting SL, because that code is then guaranteed to run in WPF. But the reverse isn't true, so starting with WPF pretty much prevents future use of SL.

But it is also tactical. SL deploys in a simpler manner than WPF. ClickOnce is good, but it still isn't as smooth as the browser-based SL model.

And SL is smaller and simpler. I keep working in SL, and rarely do I miss anything from full .NET. Now maybe this is because I'm doing CSLA coding, and my server is .NET and my objects are mobile - but I find that SL has everything I've been needing to build my UI and business layers, and .NET provides what I need to build the data access layer.

If I needed to do Office integration or something more extensive on the client I'd obviously have to switch to WPF, but most of the apps I've been working on haven't had those requirements.

All content and CSLA .NET is Copyright © 2009-2011 Marimer LLC