What are the main friction points when moving from WPF to Silverlight and how do you fill the gaps in functionality? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this questi开发者_JAVA技巧on

Okay, to give a little background, I learned WPF about 3 years ago and have kept reasonably up to date with what's happened since in various different versions. I looked at (and implemented) MVVM on a couple of projects, had a good look at frameworks like Prism so I think I'm pretty well versed in most areas of the framework. I've also worked briefly on a couple of small Silverlight 2.0 projects.

My problem is this, I'm about to start a Silverlight job at a new company and while I'm very comfortable that I can do the job well, I feel like my WPF knowledge may cause me some issues. I've gone over the WPF/Silverlight guidance white-paper on codeplex which is excellent and really helpful but although it highlights the differences that still leaves me wondering how to get around those differences.

For example, I know that DataTriggers are missing as areMultiBindings and a whole array of other stuff. What I'm interested in reading about is not the differences per se but how you get aronud those differences or what other patterns are useful in Silverlight. What if I need a DataTrigger? clearly my design should take these things into account.

So, the question is,..if you've gone through this transition, what differences caused you the most trouble and how did you get around it?

---

First, while this is dated to Silverlight 3, this white paper goes through the differences between WPF and Silverlight in detail:

Microsoft WPF-Silverlight Differences White Paper http://wpfslguidance.codeplex.com/releases/view/30311

That is a great first step to familiarize yourself with the differences.

You might also want to take a look at the Prism project. One of the goals of this project is to build a set of interoperable functionality between Silverlight and WPF so you can essentially build enterprise applications that target both platforms and reuse the majority of code. Familiarizing yourself with the project will help highlight differences as well:

http://compositewpf.codeplex.com/

Finally, while Silverlight might not have data triggers, you can use a combination of features such as behaviors and triggers:

http://www.silverlightshow.net/items/Behaviors-and-Triggers-in-Silverlight-3.aspx

And the Visual State Manager (VSM):

http://timheuer.com/blog/archive/2008/06/04/silverlight-introduces-visual-state-manager-vsm.aspx

To accomplish most of what you need.

---

Giving a Silverlight port per se for our WPF App, the following are the two 'pain' points we encountered.

1. Splitting up and grouping XAML's/modules for improved performance and on demand XAP downloading using MEF.
2. Challenge of achieving Binary Compatibility using the same code base for WPF/Silverlight.
3. A few of our Functionality required OOB and user acceptance.
4. We optimized a bit of Functionality relying on IsolatedStorage.

Hope this helps.

[ Now that Silverlight 4.0 has a stable build, we had a few Visual Studio hiccups over the last few releases which resolved itself overtime. (We stuck to Silverlight 3.0 and somewhere in mid march jumped to SL 4.0 beta and final release)].

N.B. : I have tried to keep things way abstract to not reveal the identity of the client.

---

• MarkupExtension
• IMultiValueConverter
• Template.Triggers
• Style.Triggers
• Binding RelativeSource={RelativeSource AncestorType...
• Binding.IsAsync
• {x:Static ...
• {DynamicResource...
• Grid.IsSharedSizeScope / SharedSizeGroup

All of these are not supported in Silverlight and you have to workaround them. Every case needs it's own judgment about how to "fill the gaps"

For the triggers part, the only solution is to use VisualStateManger. The following article gives a good example of how to make the transition from triggers to VSM: http://blogs.msdn.com/b/wpfsdk/archive/2009/02/27/the-visualstatemanager-and-triggers.aspx

---

Next, OnApplyTemplate is fired in different order, which might affect any Custom Controls or UserControls you might have created.

WPF:

1. UserControl Constructor
2. MyControl Constructor
3. MyControl.OnApplyTemplate
4. UserControl Loaded
5. MyControl Loaded

Silverlight:

1. UserControl Constructor
2. MyControl Constructor
3. MyControl Loaded
4. UserControl Loaded
5. MyControl.OnApplyTemplate

And of course Microsoft has an article about that, called "WPF Compatibility" and gives a more thorough overview about the differences and changes between WPF and Silverlight:

http://msdn.microsoft.com/en-us/library/cc903925(VS.95).aspx

Hope this helps

---

Silverlight forces you to make some changes to your design patterns, which, if is pervasive throughout your software, can render code reuse quite moot.

For instance, data template selectors are missing -- I found this to be quite a shock.