IDisposable Thoughts

I hope you enjoyed learning about MEF and started thinking about all the possibilities around it in your applications, awesome right?. Well, now that you know a little more about things like MEF catalogues and MEF exports we can freely start talking about the basics in creating an extension for Expression Blend.

By default all the extensions in Expression blend made by 3rd party developers would live in a MEF directory catalogue under the folder Extensions in the installed path of your Blend application (the same happen for Expression Web). To “register” our application we need to provide a special bootstrapper known as Package, this special class implement the contract IPackage and takes care of our extension initialization (you know, things like registering your own services or adding things to blend) and when everything finish, provide support for cleaning up routines.

I mention a very common word in software development, services, the base of Expression extensibility. Every time we expose a new functionality to Blend we need to create and register a service and of course we will be consuming other services in our extension. The way to access this service collection is through the contract IServices, it exposes two important methods: Load and Unload, well, we will cover some important exposed core services in this series but if you want you could start taking a look by yourself using any “decompiler” tool like Red Gate’s Reflector, Jetbrains’ DotPeek, Telerik’s JustDecompile or the now popular ILSpy. Go feel free to start playing with them.

Well, no more to talk, let’s create our first simple package

1. Add a reference to Microsoft.Expression.Framework and Microsoft.Expression.Extensibility tell to Visual Studio to never copy those assemblies to output. Those assemblies are in the Expression Blend installation directory
2. Add a reference to System.ComponentModel.Composition, this library is in the GAC
3. Create a class library for your extension
4. Tell to Visual Studio to copy the output directly to your Expression Extensions directory

1. Specify your library will be named with the postfix .Extension, this is needed for the MEF Extension Catalog to load the assembly, sort of convention.

1. To easy your development effort, tell to Visual Studio to run Expression Blend when you debug the extension.

1. Write the code for your “Package”

The code for your package would be very simple, let’s output to the debug output a simple message

using System.ComponentModel.Composition;
using Microsoft.Expression.Extensibility;
using System.Diagnostics;

namespace SampleExtension01 {
    [Export(typeof(IPackage))]
    public class SamplePackage : IPackage {
        public void Load(IServices services) {
            Debug.WriteLine("Hey, I'm in!");
        }

        public void Unload() {
            Trace.WriteLine("Boo! time to go =(");
        }
    }
}

Now we just run the Extension and look, our package works!

There are some differences in the way we create and register an Add-In instead of an Extension, but I think the bloggers around there already pointed them.

Now, the next time we are going to start doing a little more complex things, I promise =)

Meanwhile I let you with some links to people who explain a little more about the same thing:

• David Burela’s blog post about using Visual Studio to create Blend plugins: https://davidburela.wordpress.com/2010/02/02/guide-to-creating-expression-blend-3-addins/
• Tim Koke wrote a good beginning tutorial about the same subject: http://www.timmykokke.com/2010/03/building-extensions-for-expression-blend-4-using-mef/
• There’s a really good article in CodeProject about it: http://www.codeproject.com/Articles/75961/Building-extensions-for-Expression-Blend-4-using-M/
• Scott Barnes blog posted something about it too: http://www.riagenic.com/archives/275
• Jeremy Alles wrote a little about debugging a live compiled application using Reflector (in this case I can ensure you it’s Expression Blend): http://www.japf.fr/2010/03/debug-any-app-in-visual-studio-without-the-original-sources/

You can get my sample code from Bitbucket. https://bitbucket.org/cprieto/extendingblend

NOTE: The index of the series could be found here http://cprieto.com/index.php/2011/09/17/a-week-extending-blendintroduction/

Expression Blend is an amazing piece of software. It is created with the same philosophy as awesome products like Visual Studio.That is, there is only a simple shell with common and very clear extensibility points and everything else (the designer, the toolbox, even the compiling process) is written as an extension to that shell. Personally I like that way of thinking about such a complex application, you can easily designate a team to create the shell and many different teams to create all the functionality around your main application as extension to the main application, even better, you expose your main application as an composite application in a way other developers or companies can take advantage of that and even create an ecosystem around your application. Imagine applications such as CRM’s, accounting software or even tools like word processors taking advantage of that.

Well, Expression Blend 4 (and the whole Expression Suite by Microsoft) is created around this principle using the Microsoft Managed Extensibility Framework (MEF)http://msdn.microsoft.com/en-us/library/dd460648(VS.100).aspx to handle extensibility concerns. I strongly recommend to become familiar with the principles around MEF and take advantage of this amazing framework. Before Expression Blend 4 Microsoft used MEF “kind of predecessor” the Extensibility Add-In Framework in the .Net Framework 3.5 (available also in 4.0 of course). So with this in mind we need to differentiate between two different types of extensions in Microsoft Expression:

• Add-Ins: It’s the old way to extend Expression, this model is available from Expression Blend 2.0 to Expression Blend 4.0, it’s not as flexible as the Extension model but together expose the same functionality and works almost in the same way. If you need to support versions before 4.0 this is the model you need to use.
• Extensions: It’s the new way and uses MEF as extensibility mechanism. If you love things like Inversion of Control and auto discovery this is the model you need to use. It is very similar to the Visual Studio Extensibility Model and I hope one day in the future both models would merge together (so we can share extensions from one package with the other, just imagine that, well, I can dream). We are going to use this model for our samples and mention the differences with the classic Add-In model when necessary.

A primer to MEF

MEF is the extensibility core for Microsoft Expression Suite, it’s an amazing framework to handle concerns about discovery, dependency, lifetime and registration of components for extensions. This framework is used by other Microsoft products like Visual Studio. We are not going to cover the usage and basics around MEF, but before continue with the series I strongly recommend you to take a look at some basic MEF tutorials like the simple tutorial written by Brad Adams or the walkthrough in the MEF home page in Codeplex. Go ahead, take your time and have fun with the joy of using MEF.

UPDATE: After publishing the post I just realized a big mistake in it, MAF (Managed Add-In Framework) it is not MEF predecessor, it’s just another “application extensibility model” different than MEF, maybe in the next future I will talk a little more about it. Sorry for my mistake!