Everyday's Software Design

Moving from WPF to Silverlight (part 1)

---

---

I used to have a colleague in the team I manage that was sure that moving back and forth from WPF to Silverlight was easy!!! I will dedicate these series to him as reality proves us most of the times wrong. (Research is the only path to knowledge).

So I am the architect of a quite big project and it was originally coded in WPF. But since we wanted to move to a unified architecture where both our users and the clients will have the same user-experience, we decided to move on to Silverlight. There are tons of things that are different and some of them are addressed to Silverlight 5 but still, there is quite a distance.

First things first… When you just copy over the code you will see you xaml getting full of red lines. The exactly same controls are not on the same namespace!!! (WTF?). So let’s say you have a label, well your xaml tag is no more <Label>  but instead it should be <sdk:Label>.

Then I moved on to test my colors and text fonts. Again we had to change most of our resources for the text to render correctly. But the best part is the Reflection capabilities. It was well known that SL will have a minimized API version of .Net and I was prepared that our reflection helper class would have problems. What I did not expect though was that BindingEngine would complain when I was trying to bind on protected properties or even public properties on internal classes! To make myself clear:
We are quite serious about coding standards and framework guidelines in my team so we make all of our classes internal until we need to "open" them. So let’s say we had a page call MyFirstPage and the code-behind file was starting like that:

internal partial class MyFirstPage
{
   //...
} 

and the xaml code was like that:

<UserControl

         x:Class="MyNamespace.MyFirstPage"

         x:ClassModifier="internal">

//…

Well in this situation any binding will fail with the message that the BindingEngine could not find the property named “blah” as the reflection mechanism used is unable to resolve internal classes!!! I was seriously disappointed. I mean it's the same class after all! It shouldn’t matter whatever the access modifier is.

Next incompatibility was the fact that we could no longer have multiple windows. I know this is now possible in Silverlight 5 Beta (which I am currently testing) but at that point in time we had to make some serious thinking about how we are going to be user friendly and still present the same amount of information to the user. The problem with child windows - as you may know - is that they don’t let you interact with the background window (the “parent”) and so you are left with one working window at a time.

I won’t talk about MVVM concepts that were not fully supported as I decided to let my team go away from that MVVM buzz-pain-in-the-ass. I have yet to see a real complex business MVVM application (working for portfolio/transaction management in banks or insurance companies).

I will talk though about how frustrating it is to not be able to chrome your OOB (out-of-browser) window any way you like. Well we have managed some pretty neat stuff with our own but it took us a lot of time and effort. And as if these were not enough already, autoupdate needs you to have your code signed for having an elevated trust OOB getting the new version. Moreover, if you dare update the Silverlight version you build against the auto update will fail anyway. And of course you have no control over the whole operation. You just have one method call (to check and download the update, yeah two in one either you want it or not) and an event (just to let you notify the user that the next time he starts the app it will be the new version). That’s it. Period! I really miss ClickOnce…

In part 2 of this post I focus on the design changes that one has to make as Silverlight lives in an asynchronous world, has no double clicks, no default buttons and last but not least the focus operation is not as trivial as it used to be.