Today, I went to 4 sessions.

1-MEF

First one was presented by Dino Esposito and about “Managed Extensibility Framework (MEF) in Action”. MEF is now part of .NET 4.0 framework

The primary role of MEF is to extend the application at runtime. As a framework, it is to improve productivity by providing the required features for extensibility and dicosvery.

What is that?

I understood better the concept when Dino spoke about MEF like a “plug-in” framework. Plug-ins allow application to get updated and new features to be added later on in the life cycle of the application (that could be days, weeks, months after that new functionality will be shipped and added).

How does it work?

For a plug-in framework, the application must first decide and offer a hook where the new functionality can be added (i.e. extend the application). Nowadays in .NET, this is usually done through an Interface (or base class). That interface must define the operations that the application expects and will use with the new “part” (or plug-in) of the application. A plug-in developer will develop its plug-in using the interface as the contract (obviously, in reality, a .NET interface is not enough, documentation about use cases and behaviour will also be required).

The application will need to have a mechanism to discover the new “parts” (i.e. plug-ins). That could as simple as a folder where the parts can be dropped. The key is that when the application was built and compiled it did not know about the new parts – it only new about the “contract (e.g. interface)”.

MEF fits exactly in that scenario of “plug-in”, but it does more than that. MEF is “component based”.

A MEF component is an artefact that export a contract, or import a contract or both at the same time.

MEF provides a “composition feature” and a “catalogue” feature.

• MEF can compose, i.e. put together, components that export and import the same contract. This contract resolution process can be customized => this is a very powerful feature – you can decide how things can get glue together (obviously this is not limitless, but very flexible).
• Catalogues are a way to contain components, but they also offer different ways to discover the “new parts” – like from an assembly already in memory or from a folder structure.

Here is a slide from Dino’s presentation:

As MEF is now part of the .NET Framework 4.0, this is something to look at.

2 & 4- Memory in Action

The second and fourth one were presented by Mark Russinovich – “Mysteries of Windows Memory Management Revealed – Part 1” & “Part2”.

I invite all windows developer to watch these sessions (I will try to found a public link, although I am not sure that are available outside of TechNet).

Two new (at least to me) tools were used during those two sessions:

• VmMap : Virtual Memory Map viewer (link to VmMap v3.01)
• RamMap: RAM memory viewer (link to RamMap v1.1)

Very good tools that can help you analyse and observe your application (and the system) memory usage.

3 – WPH – Performance

The third session was on “Microsoft Silverlight Performance on Windows Phone”, by Oren Nachman. There were some good points to take away and think about:

• A Silverlight Application on the Phone should not target for 30 frames per second, but rather 60 frames/s – knowing that 40-45 frames/s will good enough.
• To increase the frame rates, it will depend on what your application is displaying.
  • Animated bitmaps and or sprites: you will need to understand how images are rendered behind the scenes, specially what has changed. You will need to think on “how to reduce the area that requires re-drawing”.
    • There are techniques to cache images on the graphic card memory.
    • If you have a large bitmap with a lot of transparent regions, maybe you could cut and split that image on smaller chunks (then they can be cached).

• During development phase use the debug counters and RedrawRegion flags.
• From a thread perspective, with Silverlight animation, try to minimise the load and usage of the UI thread and instead let the compositor thread do the work in the background. For that matter you need to understand how the layout work in Silverlight.

One thing for sure: in any WPF/Silverlight development for desktop or phone, a developer must understand the logical tree and visual tree. For performance, you  will need as well to understand what the GPU is able to cache and help you with performance.