Can you keep a secret? The biggest little-known features in Microsoft Silverlight
The default networking calls in Silverlight are all made through the browser. This has limitations to do with when web service return server faults. The browser can not interrupt it correctly.
There are now two networking stacks in Silverlight 3. Browser stack and client stack. The client stack goes direct to the OS network stack. This stack works correctly for web service faults. The browser stack only support 200 and 404 return codes. This is the root of the problem with web service server fault limitation. A limitation with the client stack is that it does not get the content caching built in to the browser.
To start using the client stack, you call HttpWebRequest.RegisterPrefix("http://", WebRequesterCreater.ClientHttp) and all calls after that will be on the client stack.
You can check any request object by checking the CreaterContext.
Silverlight 3 has an updated frame rate counter. To enable that, add ENableFrameRateCounter and EnableGPUAcceleration.
RenderToScale is part of the BitmapCache that allows you to control the size of the bitmap that gets handed off to the GPU by Silverlight.
Analytics class allows logging of CPU load and GPU usage.
AssemblyPart.Load allows you to load up assemblies on the fly. This means you can keep your xap file small and just pulled down the extra parks as and when you need them. To lighten up your xap file, you can change your references to be copy local = false. This means it won't be shipped in your xap. For the dll to be easily downloaded, put a manual copy inside the ClientBin folder.
This technique does have a big flaw. The CLR will die trying to find that reference. The CLR scans the method before it's run for all its types. MethodImpl(MethodImplOPtions.NoInlining) forces the JIT compiler not to scan that method for types it does not know.
Application Extension Services is a service model for building services that run with your applications. All you need to do is implement IApplicationService, StartService, StopService. Silverlight will create the service as it starts and close it just before exiting.
SynchrosationContext.Current has access to the UI dispatcher
VisualTreeHelper is a handy class to grab controls inside Composite controls.
RelativeSource allows two way template binding! Awesome!
AutomationPeer class allows you to click buttons etc.
Architecting Silverlight Applications with MVVM
MVVM is only a solution for large scale applications. It's not really ideal for small projects as it can be very bloated with layers etc.
MVVM is Model, View, ViewModel. As you start using this concept it is very similar to MVC. You create a Model which is your entity with data access. View is your control XAML on the page and then you create a model for your view that has everything you can bind to. The advantage with this is that ObservableCollection does not need to exist in your model, you can just expose that in your VIewModel. This keeps your model very clean from UI dependant references.
A cute way to reduce the dependency on the view calling the model in code is to use behaviours that you can just attach to elements in the view. One handy behaviour out of the box is CallDataMethod which can be wired up to to your method on the model.
Code Contracts and Pex: Power Charge your assertions and Unit Tests
CodeContracts does validation on your code and comes up with warnings for certain coding errors. Code Contracts allows you to make code method call intentions on your methods and code contracts will generate the correct code to run that intention.
Pex allows you to do unit testings on firing cases of your code that you might not have considered.
The Code Contracts does make for very bloated code. For interfaces you need to make two more classes to just say something doesn't need to be null.
Code Contracts has a runtime checker, static checker and documentation output. So that single intention gets used in a bunch of places.