The theory states that Silverlight is a subset of WPF, so it is likely to think that it is an easy task to convert a WPF Application to Silverlight.
I’m in the process of doing this task – migrating from WPF to Silverlight – and it is not an easy one. Actually, I would recommend that the two technologies, WPF and Silverlight, are treated as completely distinct platforms. That is, you should never expect to be able to switch freely between them.
September 2nd 2010 update: The more I work with these two technologies, the more it becomes clear to me that this is a crucial point! WPF and SL are very much completely different technologies and requires different developer mindsets. The cool thing is that it is easy as a developer to move between the two platforms, but it is however not easy to move an application between the two platforms. If you are an architect and think it would be cool to have a WPF client because “then you can always switch to Silverlight later”, then you are missing the point.
So far in the progress I have noted the differences below. I thought that they might be relevant to others. As my work progresses, I’m sure I’ll locate more differences, and at that point I’ll update this post.
The toolbar functionalities are completely missing. However, Telerik has some (not free) stuff, and a guy at codeplex has developed a prototype of a Ribbon. However, don’t expect anything out of the box.
ComponentResourceKey object in System.Windows is missing
If you don’t know what this is, you’re not going to miss it. However, I created a global resource framework based on this class, and I had to rewrite the whole stuff when moving to Silverlight.
Statusbar uses host (IE)
If you need a status bar, you can either write one yourself, or you can use the statusbar in IE. Unless, you want Silverlight to run out of browser (I think). Nothing out of the box here neither.
No xps-document viewer
This was actually a quite critical functionality in my app. There are some (not-free) controls out-there, but when you read about them you don’t get the ‘stable code impression’ that you would like from your 3rd party vendors. Actually, I originally decided on XPS because my guess was that Microsoft in general would do a lot to support this format. But when I migrated to silverlight I actually switched my XPS document format out with PDF format to be rendered in a browser control as a workaround.
Assemblies cannot be re-used directly
This is a very important point. A WPF app and a Silverlight app cannot share the same dll! This means that if you have a WPF class library, you should expect to copy-paste the code to a new Silverlight library and rebuild it. Visual Studio does however come with a possibility of creating a Silverlight library and link to the .cs-files in the WPF library – i.e. you will have two libraries, but only one set of .cs-files, since one of the libraries is linking to the other.
However, after playing around with this, I would recommend in most cases to eat the redundancy and copy-paste the code But this also points to a crucial point – do not treat the two technologies as if Silverlight is merely a subset of WPF. I really do not consider it to be so. Way to many design decisions, both in your UI and in your code, will be different and platform dependent.
No sharing between client and server
In some situations you would might like to share libraries between the client and the server. Do not expect this to be possible since SL cannot read WPF class libraries.
WebServices in assemblies cannot be linked.
As I wrote a couple of paragraphs ago, it is possible to create .cs file links. However, you cannot link a webservice in one class library to another. Expect that you will have to generate all your service references all over.
System.Configuration is not supported
Nope, it’s true – it’s not included. I really don’t understand why. Jonas Follesøe has a blog post where he suggests an approach for writing your own.
IExtensibleDataObject is not supported.
This interface is used by Visual Studio when generating code for proxy clients in WPF. It’s not included in Silverlight. If you have made a partial class and implemented this interface, for example with the purpose of extending your proxy classes, you will have to refactor this.
XmlDictionaryReaderQuotas can only be set to max
And thus it doesn’t make sense to set this propert in Silverlight. As far as I can see, it has a different signature also, but I haven’t investigated it more in depth – I only noticed that my configuration factory stopped working ;-D
wsHttpBinding is not supported in SL. In Silverlight 4 netTcp is supported, however. What makes the missing support for wsHttpBinding a bit awkward, is that this is the default binding in the WCF world, but if you use Silverlight you could consider basicHttpBinding or netTcp. This also means that classes like ReliableSessionBindingElement are not supported.
That was it for now:-)
UPDATE September 2nd 2010:
Silverlight can handle only PNG and JPG images. This has some implications: For instance multi page TIFF files is not possible to handle in Silverlight. Also animated GIF’s are not possible. Also, you cannot use the “frame”/animation feature of PNG files in Silverlight. Only static images. I had to display multipage TIFF-documents for preview, and I made a service on the server which grapped the document from the database and at runtime created a PNG array which was returned to the client.
Mouse wheel is not supported in silverlight out of the box at least. I recommend this approach instead.
No standard way to get user name
Now – this is not a joke – many clever people suggests implementing a webservice on a server, disabling anonymous authentication, forcing the browser to authenticate the user, decoding the user from the asp.net httpcontext on the server and returning the user name to the Silverlight client. Sigh! Such workarounds did not appear because people like to make it hard to obtain the username, but because it is hard to obtain the username from within Silverlight. Another approach is to grap the username from the windowsidentity within the asp.net hosting page. Setting it in a hidden html field, and retrieving the value from that hidden field from within the Silverlight client. Isn’t the reason that we have a framework to avoid silly hacks like this? I’m aware of all of the good reasons why this is hard – including cross browser compatibility and cross os compatibility, but come on guys – it’s just a freakin’ username, I want
UPDATE May 2011
BooleanToVisibilityConverter missing in Silverlight. Doh! I had a minor change request that I wanted to throw in with a minimal effort. Luckily I found out that .NET 4.0 provides a BooleanToVisibilityConverter – well, great – this is the stuff that I expect from a good framework – it seems really quite stupid to write stuff like this yourself since everyone will need it sooner or later. I upgraded my Silverlight App to .NET 4.0 (making sure with our IT Operations guys that they support .NET 4.0 on our client pc’s – they didn’t the last time I deployed), and then … sigh! This feature is not supported in Silverlight, only in WPF. But why???? Because of the well-known security risk associated with hiding and displaying controls (being ironic)? Anyway, it ain’t there, write your own