Puneet Ghanshani

Chief Architect at Microsoft

6 minute read

[Republished after additions]

This is in continuation to my previous post Silverlight Best Practices – II, where I talked about Business Layer Design Considerations.  This post, the area of concentration, will be a list of to-do’s while developing a Silverlight Application.

Development Tactics and Practices

Defacing Errors

One of the regular application development exercise is debugging and debugging errors in Silverlight applications can be really tough job if your default browser is Chrome. I’m not sure whether there is problem with Chrome, or with Silverlight IDE, or something else – but until today, the breakpoint will not be hit in Chrome. Hence, prefer using Internet Explorer.

Using Team Foundation Servers (TFS)

Silverlight developers often struggle setting up a source-safe (read TFS) within a team. To enable TFS, install VS 2010 and Silverlight Tools on Team Build Server machine.

First-class rule

Ideally, for a file Page.xaml, the first class definition in the Page.xaml.cs should be Page class.  This otherwise has known issues related to code refactoring.

Locally defined StaticResource fails to load

When a StaticResource object is both defined and referenced inside the same element, the Preview Window will fail to load with an error “The type StaticResource was not found.”

Hence, it is advisable to keep Static Resources in App.xaml file. This also helps usage of these resources across the modules in the application.

Share a Brush than copying it

Instead of defining Brush in XAML, define it as StaticResouce and reference it. This creates only one instance and then reuses it.

A Generic TODO list

This is more of a compilation of single-liners that aptly fit in the TODO list of a Silverlight developer.

  • Naming Convention - Casing:
    • Pascal Casing and not Camel Casing is preferred (unlike in C#). myButton is wrong in Silverlight though it is correct in C#. The correct version is MyButton.
    • Use x:Name instead of Name as x:Name is generic and can be used for all elements.
  • Indentation:
    • Place first attribute in-line with the element name like.

<StackPanel  DockPanel.Dock="Top" Orientation="Horizontal">

  • Choose a StaticResource over DynamicResource. For further read, click here
  • Resources should be placed at one location, preferably at Application Level in App.xaml file. This will avoid reloading of resources over and again when objects are created and destroyed.
  • SnapsToDevicePixels – Using graphic objects can appear nice on some monitors, while it may fade on others.  It is preferred to use a Style resource in such scenarios. For more read, click here
  • Define a definite folder structure before starting application development
    • Services – to have WCF service references
    • Images – to store application images and videos
    • Resources – platform specific APIs
    • Data – to store XML, text files
  • Remove the Object Handlers when not in use.  Not removing object handlers may keep the object alive, which may degrade the performance. RegisterClassHandler is called on every instance of object creation, which may cause performance problems
  • Frozen objects over Non-frozen:
    • Frozen objects occupy lesser memory space and are fast in execution.
    • Consider the example on MSDN-  Prefer VirtualizingStackPanel (40mSec) over a simple StackPanel (takes 3000mSec for same UI) to speed up the execution time.
    • Avoid using a TextBlock in FlowDocument
    • Since Label.Content property is slow in execution, TextBlock.Text should be used. (This is one reason why Label is not a part of Silverlight framework, and it is part of WPF)
    • Show underline in Hyperlink only on MouseOver events.  TextDecoration is performance intensive.
    • Bind an IList to an object, not an IEnumerable to avoid an automatic wrapper creation.  This will enhance your performance.
  • Proper node at proper place:
    • While the tree is developed, there can be two approaches – bottom-up or top-down. A top-down approach is 10 times faster. This is because when a node is added or removed from the logical tree, property invalidations are raised on the node's parent and all its children.

Best practices generally evolve as a result of implementations and errors/observations. So this post remains unconcluded for the users to add in their inputs and make it extensive guide. Keep adding to it

Note: The next in this series is the Data Access Layer Guidelines.

You May Also Enjoy