7

What are some common mistakes/pitfalls, specific to Silverlight development, that developers should avoid?

PS: Please, if you don't have hands on experience with Silverlight and want to simply state that people should just not use it, refrain from doing so.

Thank you for you time and consideration.

Here is a compilation of input from users on both StackOverflow and programmers.stackexchange.com to this question:

  • Thinking it's the same as WPF
  • Not using the MVVM design pattern
  • Not knowing that it doesn't support ADO.Net Connections
  • Not knowing that it only supports basicHttpBinding (no wsHttpBinding allowed)
  • Not knowing that RelativeSource bindings don't support AncestorType
  • Forgetting to setup IIS MIME types
  • Thinking that Silverlight works the same way as WPF
  • 5mb limit on XAP files and the need for third party solutions to work around that

  • Not abstracting out the service layer calls.

    Abstracting out the service layer calls so that the silverlight pages load in the designer (either Visual Studio or Expression Blend) without the presence of the service helps out. Especially if the UI is being designed in Expression Blend. Some dummy data can be returned without calling the service and the UI designers still get a feel for the look and feel of the application with data.

  • Not using MVVM

    You can program Silverlight like a winforms app but you are in for a world of grief. The whole platform was designed to use MVVM and if you don't work with that you are going to be swimming upstream the whole way.

  • Networking: there are limits on sockets, e.g. no UDP, only the async model

  • Networking: two (3.0) different HTTP stack, the browser one and the client one - each has its own quirks (a lot of applications ends up using both);

  • Security: some API are marked as [SecurityCritical] and you won't be allowed to use them, even if it will compile just fine, at runtime (e.g. but that code has been working for years in my other application)

  • Security: security policies on HTTP[S] and sockets (but works so well on your own computer)
  • ditran.net/silverlight-common-errors
  • Using MVVM but not truely understanding it

    blindly obeying its principles as if they were the 10 commandments, some people really make things hard for themselves I bet most don't have any separate UI design team nor are using Unit tests, so the benefits of MVVM would be minimal

  • Not grasping the Asynchronous nature of Silverlight.
  • Over using UserControls when they should be using a Templated control

Thank you for constructive input to the following people: Rachel, maple_shaft, Jesse C. Slicer, ChrisF, Jon Raynor, poupou, RKitty, DShah, AnthonyWJones

Dmitry
  • 197
  • 2
  • 6
  • 2
    Cross posted to Stack Overflow - http://stackoverflow.com/questions/7260097/what-are-common-silverlight-specific-mistakes-pitfalls-developers-should-avoid – ChrisF Sep 01 '11 at 19:35

5 Answers5

7

The main problems I encountered when building a Silverlight app were:

  • Thinking it's the same as WPF
  • Not using the MVVM design pattern
  • Not knowing that it doesn't support ADO.Net Connections
  • Not knowing that it only supports basicHttpBinding (no wsHttpBinding allowed)
  • Not knowing that RelativeSource bindings don't support AncestorType
  • Forgetting that clients needed to install Silverlight framework to run it
  • Forgetting to setup IIS MIME types

I'm sure there's others issues, but I forget them. I usually do WPF develpment, and have only done a handful of silverlight apps. The biggest issue I had was thinking that Silverlight was the same as WPF... it's not. There are a lot of things you can do in WPF that you can't do in Silverlight.

Rachel
  • 23,979
  • 16
  • 91
  • 159
  • 1
    +1 Excellent Answer! I would also like to add the 5mb limit on XAP files and the need for third party solutions to work around that. – maple_shaft Aug 31 '11 at 16:58
  • Wow ...sounds like a bunch of good reasons *not* to use Silverlight! Not being able to use ADO.Net connections is huge. But I'm mostly a WinForms dev - so what do I know ... – IAbstract Aug 31 '11 at 17:10
  • 3
    Silverlight as of version 4 supports netTcpBinding as well. – Jesse C. Slicer Aug 31 '11 at 17:22
  • 1
    @IAbstract - not being able to use ADO.Net is not a problem. You should be using RIAServices for database connections anyway. – ChrisF Sep 01 '11 at 12:32
1

Not using MVVM is the biggest mistake I have seen. You can program Silverlight like a winforms app but you are in for a world of grief. The whole platform was designed to use MVVM and if you don't work with that you are going to be swimming upstream the whole way.

RKitty
  • 280
  • 1
  • 3
1

Most silverlight apps use services to get data. I would add that abstracting out the service layer calls so that the silverlight pages load in the designer (either Visual Studio or Expression Blend) without the presence of the service helps out. Especially if the UI is being designed in Expression Blend. Some dummy data can be returned without calling the service and the UI designers still get a feel for the look and feel of the application with data.

Jon Raynor
  • 10,905
  • 29
  • 47
1

Networking:

  • there are limits on sockets, e.g. no UDP, only the async model - the later is a good thing IMO;

  • two (3.0) different HTTP stack, the browser one and the client one - each has its own quirks (a lot of applications ends up using both);

There quite a few security considerations as well. The major pitfalls (it works in some cases, not in my app) are:

  • some API are marked as [SecurityCritical] and you won't be allowed to use them, even if it will compile just fine, at runtime (e.g. but that code has been working for years in my other application);

  • security policies on HTTP[S] and sockets (but works so well on your own computer);

poupou
  • 111
  • 1
  • 4
1

Not being able to leverage existing Class Library DLLs.

Silverlight Client-Side applications must link to Silverlight Class Libraries.

This may force you to keep business logic on the server end (which works fine with regular .NET Class Libraries) - which is a good thing!

Sheldon Warkentin
  • 1,272
  • 8
  • 12
  • You can use COM in elevated permission mode i believe (out of browser). Existing class libraries can be converted to Silverlight ones as long as they are not referencing anything in them that is not available in the Silverlight Client version of .NET, and then that DLL can be used both on the server and the client. (please do correct me if I'm wrong) – Dmitry Sep 01 '11 at 20:10