(All samples from this session are available at http://www.wintellect.com/downloads/techedeurope2009.zip)
Typically Silverlight uses the browser's connectivity for all network access. However, Silverlight 3 introduces the "client stack", that uses the operation system's networking APIs. This makes it a lot more stable and reliable - for example you now get full access to headers, and when you hit a SOAP error you'll now get the full error details back, instead of the munged version that the browser returns (the browser stack will only ever return a 200 or a 404). This also gives you access to http PUTs and DELETEs, rather than just GET and POST as supported by the browser stack.
On the other hand, the client stack will never give you cached results; also you're limited to two concurrent connections.
You just have to call this:
HttpWebRequest.RegisterPrefix(<span>"http://[whatever]"</span>, WebRequestCreator.ClientHttp);
... and then access connections as usual.
An event called CompositionTarget.Rendering is fired about 60 times per second on the UI thread, and can be used for custom animations. It's mostly used for games, but can be useful elsewhere, for example to work through a long-running queue of changes that need to be made to the UI - running on another thread would be inappropriate as that thread wouldn't be able to update the UI.
There's an enhanced frame-rate counter that monitors the amount of memory used by the GPU.. This is shown when EnableFrameRateCounter and EnableGPUAcceleration are both set to true.
BitmapCache.RenderAtScale can be used to scale up controls using the GPU, without pixelation.
A new class called Analytics allows you to monitor CPU load (both by this process and by all processes), as well as information about any GPUs that might be present.
The AssemblyPart class represents an assembly that's part of a Silverlight application. AssemblyPart.Load enables you to load assemblies at runtime, minimising the initial download time of the application. (NB. this can only be called on the UI thread.) By changing the CopyLocal property of a reference to false, you still get full intellisense when developing the application, but it's not sent down in the initial xap file. So long as you dynamically load the associated dll before you try to use it, your application will still work.
Be careful though! The JIT compiler compiles methods the first time it sees them: if this happens before you've loaded the assembly, you'll get a runtime exception. Also, the JIT compiler may choose to in-line some methods, so you don't know for sure when a method will be compiled. The safest way to avoid this (and retain strong-typing) is to use the [MethodImpl(MethodImplOptions.NoInlining)] attribute on the method that uses the dynamically-loaded reference.
Application Extension Services are services that have the same lifetime as the Silverlight application - they start just before the app, and end just after it ends. Implement IApplicationService (and optionally IApplicationLifetimeAware) on a class to make it such a service. We saw a sample where dynamic assembly loading was handled on-demand by such a service. It's a little complex, so check out the sample code.
The VisualTreeHelper class gives you access to the xaml that's been generated by templates in data-bound controls. This can be handy for programmatically styling items in a list, for example.
Silverlight 3 now has support for xaml-styled modal dialogs, using Child Windows.
VirtualizingStackPanel acts like a StackPanel that handles large numbers of items much better, by deferring templating the items until they scroll into view. ListBox now uses it by default, though ComboBox still doesn't.
RelativeSource can be used to bind a property of an element to the property of a nearby control (such as its parent).
AutomationPeer is usually used for accessibility issues, but can also be used to simulate button clicks.
NetworkInterface.GetIsNetworkAvailable() tells you whether or not a network is available. NetworkChange.NetworkAddressChanged is an event that will let you know when the network drops out or comes back.
A lot of this was typing code, so I won't reproduce it here, but there were a few key points.
Visual Studio uses MEF (Managed Extension Framework) as its extensibility mechanism, so it's now included in VS2010. It gives you extensions for commands, gestures (such as drag-and-drop) and model validators. This does most of the hard work for you, giving you easy points to plug into VS events, so you can just concentrate on the things you want to do.
Model validators can be set to run whenever the model is saved or opened, or run manually from a menu.
VSIX is a packaging technology that uses Office's xml model to package up your extensions and makes them much easier to install.
Whilst developing an extension, pressing F5 launches a new instance of Visual Studio, installs the extension, and enables debugging in the first instance. This instance is entirely separate from a normal one, down to using its own set of registry settings. This is so much easier than it used to be!
There's a whole now (and much, much easier) model for inspecting and altering existing code. This was a third-party library he found, but I'll see if I can dig it out - our code generation tools are a little painful to work with sometimes.
This session focused entirely on extending the class diagram and the UML model diagram, but I believe similar extensions are available for other actions and items in Visual Studio.
I was going to try to keep up, writing them here as they were explained, but there were too many coming too fast, and in any case there'll all here: scottcate.com/tricks. Thanks Scott!
(Most of these work in VS2008 as well - you don't have to wait for VS2010.)