Skip to main content
Post Closed as "Needs more focus" by Jim G., CommunityBot, gnat, jwenting
compiled answers into a more readable list
Source Link
Dmitry
  • 197
  • 2
  • 6

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

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.

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

Added note to asking to refrain from posting off-topic, microsoft/silverlight bashing statements
Source Link
Dmitry
  • 197
  • 2
  • 6

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.

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

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.

Source Link
Dmitry
  • 197
  • 2
  • 6

What are common Silverlight specific mistakes/pitfalls developers should avoid?

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