My Technobabble

Building extensible RIAs at PDC

Glenn Block — Mon, 16 Nov 2009 18:14:29 GMT

This week I’ll be attending PDC in Los Angeles speaking about using MEF in Silverlight.

Building Extensible Rich Internet Applications with the Managed Extensibility Framework

In Hall F on Thursday at 11:30 AM

Learn how the Microsoft .NET Framework 4 introduces the Managed Extensibility Framework (MEF) for building customizable applications that can easily be extended by third parties. Whether you are building an extensible data grid, a custom rules engine, a pluggable editor, or a composite application such as a pluggable CRM system, you want to learn about MEF. Hear how to use MEF to decouple your applications into more maintainable and testable pieces, and partition your application into dynamically deployable chunks that download on-demand.

If you haven’t heard, MEF is available in Silverlight similar to it’s availability on the desktop. But what does it mean to build an extensible app in Silverlight? Yes it’s technically possible, but why should you care? In this talk we’ll explore different application scenarios for when MEF is a good fit. We’ll also explore some of the SL specific features we’ve introduced in order to enrich the MEF experience.

Hope to see you there!

Glenn

Should I use MEF with an IoC container? - Part 1

Glenn Block — Sun, 01 Nov 2009 10:31:00 GMT

In my post "Should I use MEF for my IoC needs" we took a look at the question of whether or not it is appropriate to use MEF instead of a traditional IoC container. In this post we'll discuss the question of whether or not you should use both an IoC container and MEF in the same application.

MEF and IoC container concerns

As we've mentioned in the past, MEF's primary design in V1 is around open-systems whose components (parts) are dynamically discovered at runtime. IoC containers on the other hand are primarily designed for decoupling a closed (fixed) set of application components in order to improve the maintainability of the system by the engineering team. In other words each is addressing a specific set of concerns. So if that is the case then is it plausable to use both in an application? The answer is Yes. Not only that, but we specifically designed MEF with the idea of integration with other containers in mind. Below will explore one of the key-scenarios for doing this.

Enabling third-party extensibility in an IoC container-dependent application.

You have an existing customer management system that uses an IoC container such as Castle Windsor which you use in order to promote separation-of-concens and testability. The application leverages advanced Windsor facilities for integrating with NHibernate and for applying cross-cutting-concerns (AOP) such as logging, etc. The loosely coupled design of the system has proven to be greatly beneficial and has minimized the friction for developing and deploying the system through several releases.

At some point requests start pouring in from customers want to create their own extensions in order to customize the application in their specific environments. Additionally several ISVs express interest in providing third-party value-adds such as telephony integration, and scheduling. You determine that adding a third-party extensibility model to the application makes sense in order to address this opportunity. Through your research you come across MEF and realize that it provides the infrastructure you need for extensibility. However it does so in a manner that overlaps with many of the functions that Windsor is providing. What to do? Let's explore various options.

a. Migrate the existing code to use MEF and remove the IoC container completely.

One option is to consider ripping out Castle and just using MEF. Technically this sounds reasonable, however after investigation it is not feasible. There are literally thousands of components that are currently registered in the Windsor container. Moving these to MEF involves modfying all of these existing classes in order to make them discoverable by MEF, not to mention refactoring all the places in the application where the container is accessed. Because the changes are so widespread, the likelihood of introducing breakages / bugs in the system is very high. Additionally there are the various Castle facilities such as Dynamic Proxy, and NHibernate integration which MEF does not yet support, which will have to authored by the team. The cost / risk of such changes is too prohibitive, not to mention that it seems like it should be unnecessary.

b. Implement a custom extensibility mechanism built on top of the IoC container?

Another option is to author a home-grown solution. This can be a viable option depending on the needs, and the willingness to author your own solution. For simple cases you can easily facade an extensibility mechanism on top of an IoC. Once you start getting into more advanced features like lazy instantiation, metadata, recomposition and stable composition, you are in for quite a bit of work.

c. Have both the IoC and MEF both present in the same application?

The final option I want to discuss (and the one I recommend for these situations) is to use both. Use the IoC container for addressing internal application decoupling needs, and use MEF for third-party extensibiltiy needs, that is the IoC container for IoCish things and the MEF container for MEFfish things :-)

This path is appealing for several reasons.

It works with existing codebases whether they be applications or frameworks. it does not require any significant rewrite.
It allows leveraging the strengths of each container for the things it does best. For example leveraging MEF's metadata model for discriminating between different extensions vs the dynamic proxy support in Castle.

However, there are several caveats of this approach.

It raises questions such as:
- Which component (part) should live in which container?
- Who owns the lifetime?
- Can a MEF part access services coming from the IoC? How?
- Can the IoC access exports coming from MEF? How?
It increases complexity in that now there are components living in mulitple places.
It increases the potential points of failuire within the application.

All of these issues are managable. In my next post we'll see how.

Open-generic support in MEF Contrib

Glenn Block — Thu, 20 Aug 2009 11:51:00 GMT

A while ago I said it couldn’t be done, at least without hacky string parsing. Folks weren’t happy and they let us know it including Oren. Our team know the power that open-generic support brings to systems, but at the time there was no clean way to implement it in MEF. Then a bunch of time passed, and we actually added some APIs to MEF which suddenly made achieving support a reality (thanks to Wes for pointing the path), and not in the hacky string-parsing way I had described.

It all came together a few weeks ago after I was pairing with my friend Karl Shifflett on the Cider team. We ran into an issue around usage of MEF which really needed open-generics, and without it made me question the usage of MEF for that scenario. As I have a tendency to do, I then set off on a personal mission to find a solution. And now several weeks and light nights later, and after quite a bit of help from many of my teammates I am happy to say there is one! I am a tech geek so I usually now take the opportunity to dive into all the nitty gritty of what what the implementation is. This time however, I am going to change that tune and only focus on what it is, how you use it and how you can get it (now).

How can I get it?

If you want to get right to the code, then GenericCatalog ships as part of MEF Contrib. I’ve uploaded two projects MefContrib.Extenions.Generics and MefContrib.Extensions.Generics.Tests. You can go grab the source on contrib here. Andreas is shortly releasing an official release of MEF Contrib, which will contain this in binary form. If you want the binary, tweet Andreas and say I want MEF Contrib!

What is it?

Open-generic support is very simple. It means that you can provide a part with a generic contract, that can be used to satisfy all imports of a closed form of that contract. The canonical example folks use is Repository<T> and IRepository<T>. What I want to be able to do is register a generic Repository such that any imports of IRepository<T> can be satisfied, this IRepository<Customer>, IRepository<Order>, etc can all be handled by a single Repository<T> that is registered in the catalog.

MEF’s attributed model however does not support this, we don’t allow even exporting open-generic types. If you put an export attribute on say Repository<T>, we ignore it. MEF does support closed generic types. For example I can have an importer of IRepository<Customer>, and i can register Repository<Customer> which exports IRepository<Customer>. However, that means that I have to add a specific implementation of IRepository<T> for every repository in existence. This is problematic because the importer doesn’t want to be burdened with having to add these specific implementations, or to know whether or not it even exists.

Enter GenericCatalog

The new GenericCatalog changes that. Generic Catalog is a custom catalog that can both discover open-generic implementations, and create closed implementations on demand. It also supports generic specialization, that is it allows you to register specific implementations of a generic contract, which override the default that will be created by the open-generic. Finally it supports one other requested feature, that is it can create concrete instances that are imported, even if they were not added to any catalog.

GenericCatalog is a decorator. You pass it in it’s constructor all your catalogs, and it sits on top, delegates to the inner catalogs, and intercepts requests for generic types that were not found in the catalog.

How you use it

To see how it works, check out the specification / context below (otherwise known as a unit test)

     [TestFixture]

    public class When_querying_catalog_for_an_order_repository_and_no_closed_repository_is_present : GenericCatalogContext

    {

        [Test]                    

        public void order_repository_part_definition_is_created()

        {

            Assert.IsNotNull(_result.Item1);

        }

        [Test]

        public void order_repository_export_is_created()

        {

            Assert.IsNotNull(_result.Item2);

        }

        public override void Context()

        {

            _result = _genericCatalog.GetExports(_repositoryImportDefinition).Single();

        }

        private Tuple<ComposablePartDefinition, ExportDefinition> _result;

    }

Looking at the spec we can see that we are creating the container passing in a generic catalog. We are then asking the container for an IRepository<Order> and we are verifying that we got one.

Notice in the test that we are calling the overload that accepts an ImportDefinition rather than just calling container.GetExportedValue<IRepository<Order>>. MEF creates special kinds of ImportDefinitions when you add an Import to a part. These definitions carry additional information that the generics implementation relies on. When you call GetExport directly on the container however, the definition that is created is a different definition which doe snot carry this information. As such, in order to take advantage of the new functionality, you import the generic type in a part. For example, the IRepository<Order> definition came from this import below.

    [Export]

    public class OrderProcessor

    {

        [Import]

        public IRepository<Order> OrderRepository { get; set; }

    }

OrderProcessor is importing IRepository<Order>

How do you setup the container?

In order to setup the container to support open-generics, you create the GenericCatalog passing in all your other catalogs, usually this will be your conventional AggregateCatalog that contains all your catalogs today. For example below in the base context class you can see how we setup the catalog for this test.

    public class GenericCatalogContext

    {

        protected AggregateCatalog _aggegateCatalog;

        protected GenericCatalog _genericCatalog;

        protected ImportDefinition _repositoryImportDefinition;

        public GenericCatalogContext()

        {

            var typeCatalog = new TypeCatalog(typeof(OrderProcessor), typeof(RepositoryTypeLocator));

            _aggegateCatalog = new AggregateCatalog();

            _aggegateCatalog.Catalogs.Add(typeCatalog);

            _genericCatalog = new GenericCatalog(_aggegateCatalog);

            string orderProcessorContract = AttributedModelServices.GetContractName(typeof(OrderProcessor));

            var orderProcessPartDefinition = typeCatalog.Parts.Single(p => p.ExportDefinitions.Any(d => d.ContractName == orderProcessorContract));

            _repositoryImportDefinition = orderProcessPartDefinition.ImportDefinitions.First();

            Context();

        }

        public virtual void Context()

        {

        }

    }

In this case we are creating a type catalog that we are adding our types for our test, an OrderProcessor and a RepositoryTypeLocator (more about that in the next section). Next we are creating an AggregateCatalog, and adding the type catalog to it. Finally we are creating a GenericCatalog and passing it the Aggregate which contains everything else. Next I do a bit of hackery to get the ImportDefinition off of the OrderProcessor in order to do the query in the test. As i mentioned you shouldn’t have to do this, as you’ll be grabbing something from the container that likely depends on the generic import rather than needed it directly.

Type Mapping

If you are following along, you might be asking yourself where are the open-generic types? And that is where GenericTypeMapping comes in. As I mentioned earlier, MEF does not allow exporting / importing open-generics. To work around that, I’ve introduced a non-generic contract that carries generic type information :-) Not only that, but the implementation types passed in actually are open-generic parts!

GenericTypeMapping accepts two parameters in it’s constructor, one is an open-generic contract type, and the other is an open-generic implementation type. This type also is an inherited export, taking advantage of our new Preview 6 feature which thus removes the need for the attribute on derivers.

    [InheritedExport]

    public abstract class GenericContractTypeMapping

    {

        public GenericContractTypeMapping(Type genericContractTypeDefinition, Type genericImplementationTypeDefinition)

        {

        }

        public Type GenericContractTypeDefinition { get; }

        public Type GenericImplementationTypeDefinition { get; }

    }

To use it, you derive from GenericContractTypeMapping for each open-generic type you want to export. You then make sure that it is in one of the catalogs that is passed in to the GenericCatalog. In our example we have a RepositoryTypeLocator which has a contract of IRepository<> and an implementation of Repository<>.

    public class RepositoryTypeLocator : GenericContractTypeMapping

    {

        public RepositoryTypeLocator()

            :base(typeof(IRepository<>), typeof(Repository<>))

        {

        }

    }

Repository<> is a generic part. It supports constructor injection, can have imports / exports just like any other part.

    public class Repository<T> : IRepository<T>

    {

    }

So all you have to do is create generic parts, and corresponding type mappings, put them in the catalog, and as Karl Shifflett says, “DONE!”

How it works (You don’t have to read this)

GenericCatalog is what is doing all the magic here. This guy automatically queries his inner catalog for all GenericTypeMapping contacts. Once he has them, he takes the types within and adds them to a mapping table from generic contract to generic implementation. Whenever the catalog is queried, it will see if any exports were returned, if not and the importing type is generic, it will grab the generic type definition, and lookup in that table built earlier. If it finds that it can match against that definition, it will grab the implementation and create a closed generic type. It will then add the new type to a TypeCatalog, which it will add to it’s inner catalog. Once it does this, it then queries the catalog to grab the new export, returns it, and Voila.

You can dig into the source if you want to know more of the nitty gritty.

Will this ship as part of MEF V1?

No. Actually being brutally honest, the implementation here would probably never ship as part of the framework. This is an additive approach to solving the problem of open-generics, but it is not the approach we would choose to ship in the framework. We are looking seriously into baking such support into MEF in the future, but it will not be in V1. If and when we do, I guarantee it will be a much cleaner and deeply integrated part of MEF as opposed to what I am giving you. However, I believe as do others on my team that in the meanwhile, this approach is reasonable. We’ve put this in MEF contrib to ensure that the community can take it forward from here.

We appreciate any feedback. I take full responsibility for any hackiness you find within. :p

Special thanks to all my awesome teammates and to Andreas for help in getting this out the door.

Herding code on MVVM and other presentation patterns in WPF and Silverlight

Glenn Block — Thu, 20 Aug 2009 09:17:39 GMT

Recently I had the pleasure of having a nice lively discussion on Herding Code with my cohorts Ward Bell, Rob Eisenberg and Jeremy Miller around one of our favorite topics, Presentation Patterns. We let the gloves come off and went at it for about 2 hours. The conversation ranged from topics including View First vs VM First, Screen activation, commanding, and databinding. The podcast was a blast. Special thanks to the Herding Code team for their being great hosts, and for their awesome queuing system. Even I let others speak :-)

Get part I here: Herding Code 57: Presentation Patterns with Jeremy Miller, Ward Bell, Rob Eisenberg and Glenn Block (Part 1)

Should I use MEF for my general IoC needs?

Glenn Block — Sun, 16 Aug 2009 22:37:00 GMT

Disclaimer: This is not an encouragement to use MEF to replace your IoC container, these are guidelines to help those who are considering it's use.

This has been a question we hear again and again both internally and externally. MEF in V1 is targetting third-party extensibility scenarios, or open-systems which discover their components rather than having them explicitly configured. This is why our attributed model was crafted in the fashion that it was. Now that doesn’t answer the question, “Can I use MEF today for my general IoC needs?”. Like all things in software, it depends ;-), in this case on what your IoC needs are.

Update: The list has been updated based on feedback from my team.

On first glance, MEF may seem to be very similar to your favorite IoC container. However as they say, the devil is in the details. Here are a few details to consider which should help you in your decision and set proper expectations about using MEF:

If you need/want centralized configuration of plain old CLR objects (POCOs) then MEF is not the right choice.
- We do have TypeCatalogs which allow you pick and choose which Types you have in the container, but those types still have to attributed, thus the configuration mechanism is configuring which attributed MEF parts show up. This is because our attributed model is really optimized around discovery of a set of unknown components vs configuring a pre-defined set.
- As we don't have a central configuration mechanism, we also have no explict way to pipe configuration settings like "Port" or "Uri" into a specific part.
If you need AOP/Interception like injecting logging, or automatic transcation management then MEF doesn’t include any native support for this.
Open generics support (register IRepository<> which can handle all IRepository<T> dependencies) is not baked in.
If you need custom lifetime support such as per-thread, per-session MEF includes only two lifetime models, shared and non-shared. To get more complex lifetimes requires manually setting up container hierarchies. It is doable, but requires work.
If you need paramterized construction, that is creating a part where specific imports are passed in at the time of construction, then this is also not supported.

In enterprise applications with a large number of different types of components, the above list will probably be more significant. However, if none of the above are core concerns then MEF might be fine for your needs. MEF does an excellent job of decoupling implementations and assembling component hierarchies, but it is tailored today for implicit composition and discovery.

In the next version of MEF that will ship post .NET 4.0, we are planning to focus more on explicit composition, and will be addressing many of the items on the above list. Until then, it is likely that there will be some great community implementations such as MEF Contrib which will address many of these concerns, but these are not part of MEF itself.

The spirit of MVVM (ViewModel), it’s not a code counting exercise.

Glenn Block — Mon, 03 Aug 2009 08:13:26 GMT

<Warning>Long post follows</Warning>

Lately there is a lot of momentum and interesting conversation around Model-View-View-Model. There’s several good resources out there that discuss the basics of the pattern, who the actors are that are involved and what role the play. I’ll let those speak for themselves, including John Gossman’s great post here, Martin Fowler’s post on the more general PresentationModel pattern and more recently Josh Smith’s MSDN article, Rob Eisenberg’s new series, and Ward Bell’s posts which touch on some of the deeper complexities involved.

In many of these discussions (not including the posts I referred to) it seems like one aspect of ViewModel get’s lost, which is “Why use it in the first place?” This leads to a lot of debate around details of implementation including one item in particular which is whether or not code in the code-behind is an anti-pattern. Building off of the stage Phil set in his great LOD post, I’ll say ViewModel is not a code-counting exercise.

The essence and the spirit

John says in his post, “Model/View/ViewModel is a variation of Model/View/Controller (MVC) that is tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer. The designer is generally a more graphical, artistic focused person, and does less classic coding than a traditional developer.”

Martin then states in this Bliki that “The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.” Martin then adds “It's useful for allowing you to test without the UI, support for some form of multiple view and a separation of concerns which may make it easier to develop the user interface.”

From John’s perspective, it is a pattern that enables a UX designer (non-developer) to be responsible for the UI. From Martin’s perspective it’s about separation-of-concerns and testability. So which one is right? I say both. Also notice neither one said anything about having zero-code in the code-behind. Instead they spoke about maintainability.

So what is the spirit of MVVM then? I say it’s building UIs that utilize platform enhancements in WPF and Silverlight to provide good separation between UI and business logic in order to make those UIs easier to maintain by developers and designers.

When I say designer, I don’t mean only the stereotypical guy/gal who wears a black sweater :-). It may also be a developer who is using Blend/Cider to define the UI, which is likely, as we all know hand coding a ton of XAML is anything but fun.

Why have I called out WPF and Silverlight? Because the pattern is specific and solely on the specific data binding, data templates, attached properties and command implementations found in the platform. Presentation Model on the other hand is entirely general and places no such specificity. I would not for example recommend ViewModel as an appropriate pattern for ASP.NET or Winforms, but I would however recommend PresentationModel, in addition to MVP, etc.

It’s not about counting code

They key here (and which I want to touch on) is the last part, “easier to maintain by developers and designers.”. This means (if you buy my definition) that the chosen implementation should consider both aspects of the equation, that is what does it do for the developer and what does it do for the designer. Obviously tradeoffs have to be made, but the key is finding a healthy balance, reducing the negative impact to both.

Which brings us to the code counting question. Does having zero code in the code-behind make the UI easier to maintain? I say it depends on what kind of code you are talking about:

If the code is UI level business logic which does not relate directly to the rendering of the view, such as determining whether or not certain elements are visible, or enabled, then I agree, this kind of code is a separate concern and should not appear in the View at all and be within the ViewModel. I would include in this the XAML, as the XAML is still part of the view. Why shouldn’t this logic be there? Because it makes the UI difficult to maintain by creating a tight coupling between the UI and the logic. It makes it difficult to test, and is also very brittle and likely to break as the UI evolves in response to changing requirements.

On the other side of the coin are UI-specific concerns, I would include in this setting enabled state, visibility or starting/stopping animations as well as even logic that relates to which model data a specific UI element binds to. That may sound contradictory to my previous statement but it is not. What I mean is, the ViewModel should contain the logic to determine whether something is visible or not, and the View should act on that knowledge to then hide the element. Adding this logic to the ViewModel would introduce tight coupling between the ViewModel and the View, this time from the ViewModel side.

Now being that it is a UI specific concern, the next question is how should it be handled, as code in the code-behind or in XAML? And for that answer I would say it depends on the specific concern itself, as well as whether or not there is a UX designer who handles the UI. Even still, I would look at an approach that best meets the needs of both developers and designers.

Data binding

Let’s take data binding as an example. If I am working with a dedicated UX designer then bindings in XAML is the prevalent technique that our tooling provides for data binding. Now it does negatively impact the development team to some degree in that due to XAML’s very loose nature it is very easy to break and difficult to verify and test. However there’s no other option for the designer other than forcing them to write code, which is how should we say less than optimal.

If there was no UX designer present however, I would see no issue with putting that binding definition in code, even in the code-behind. As developers are used to writing code, not markup, and the developer IDE provides much richer support for developers in code. Now that being said, the API for defining bindings is not really well-suited for doing them in code, but OSS solutions like “Fluent Silverlight” help bridge that gap.

Animations

A different example relates to animations. The user clicks a Save button on the Edit Order screen which requires some UI cue to the user such as an hourglass while the order is saving, and another cue once the Order has saved. The question is where should this logic live? In the XAML or in the code? You could handle this in the XAML by using triggers, attached behaviors and the like. In the case of Silverlight, you don’t yet have triggers yet baked in, but you could look to using those included with Blend.

Now although you “could”, I wouldn’t, though you might feel different. The reason goes back to maintainability, having such logic in the view means once again it is easy to break and difficult to test (How do I know it actually works?). Instead, I would opt in this case to separate into two parts, the pure visual part and the logic. The pure visual would be the hour glass animation, and the saved completed screen which could likely be purely defined in XAML. However, the logic part which determines to show the hour glass while saving is in progress would rest in the code. I would achieve this by adding OnSave,OnSaveCompleted methods to the view which would both contain the logic to actually display the elements.

The ViewModel would get injected with either an interface to the view, or with a set of delegates it could call to once save begins and completes. Yes, I did say I’d put code in the code-behind! That is ok because it is code that relates entirely to a view-level concern. Also I would argue that putting the one line of code in the View, only minimally impacts the designer. They can still verify that the animations works. On the plus side it means that we’re remove one more potential piece of brittle, un-testable logic. Also it improves debugging as a developer can put a break-point on the view methods to and see whether or not they are even getting called, additionally it ensures that an exception is thrown if the animation in question is removed.

Commands and Parameters

The last thing I want to touch on relates to invoking commands, and usage of command parameters through element binding, vs using bound properties on the ViewModel. The user selects an item in the Order list, and double clicks. Do we a) Use element binding and have clicking on the “Open Order” button invoke the OpenOrder command passing in the currently selected order as a parameter, or b) Set the orders list selected item to bind to a SelectedOrder ViewModel property and then have a parameterless OpenOrder command which uses the SelectedOrder order property on the VM itself.

I would argue B over A, and why relates back to the maintainability question. If I use element binding, again I make the view harder to maintain. In this case, I haven’t coupled it to the VM, but I have coupled one part of the View to another part of the View. The impact here is on future refactorings of the View. If move around elements in the view such that the relative binding is broken, I broke my UI, if I use the second approach however, I can re-factor / replace elements all day long without breaking any relative bindings.

Yes, I’ve added properties to the ViewModel, but those properties are easy to discover, and result in UIs that are less prone to break over time. I should also add that using approach B works just as well for a designer, as they can easily bind to the properties on the VM for the parameters and parameterless commands.

Conclusion

In conclusion, the spirit of MVVM is about producing maintainable UIs for the developer and the designer, not UIs that have zero code. I would recommend folks who are developing using the MVVM pattern to focus less on whether or not there is code in the code behind, and rather focus on the type of code and whether it improves / or hinders the maintainability of the UI. Sometimes having a bit of code in the code behind actually goes a long way toward improving it.

What are your thoughts on this topic? I’d love to hear them.

Stable Composition in MEF Preview 6

Glenn Block — Sun, 02 Aug 2009 22:58:00 GMT

Nick just posted on a new and very important feature we added in Preview 6 which we call Stable Composition. To give you an idea of why we added this, in the past if you had a part, say OrderProcessor, that had a required import of ILogger, and no logger was present, then composition would fail, and in so doing would corrupt the state of the container. Once that corruption happened, you were basically left with no option but to tear down the container, and in most cases shutdown the application. With Stable Composition the troublesome parts are rejected from the system thus maintaining stability.

In summary, it basically has two components to it:

First, it ensures that only parts whose imports can be satisfied will ever be allowed to enter the system. Those imports might not be satisfied for one of several reasons including the export not being present (Importing ILogger and no loggers are present), or too many exports being present (Importing ILogger and many loggers are present). Note: You can still use the approach described here to provide defaults in the presence of multiple implementations.

Second, this feature ensures that once parts have entered the system, they will never be allowed to enter an invalid state (i.e. their dependency requirements will not be able to be upset). For example if a part in a running system contains an import of a single logger, and one attempts to add a new logger to the catalog/container, then that new logger will be rejected.

In either case, the effect is to reject such parts and their transitive dependencies, meaning the entire object graph that is problematic is pruned. In Nick’s example, A PointOfSale part imports ItemLookup contracts. ProductLookup depends on ProductRepository which is preset, so it is imported without a problem. ServiceLookup however depends on ServiceRepository which the standard POS SKU does not provide, thus ServiceLookup is rejected.

Subtleties of rejection

Now having such a feature present has some subtle implications in particular when the hierarchy of dependencies is deep, and the part at the bottom of the chain is rejected. For example, Shell imports Toolbar, and Toolbar imports the ToolbarButtonState service which is missing some dependency for one reason or another, then the Shell itself will be rejected. If you are debugging the application, you might be staring at the debugger dumbfounded when you see the message “No Exports Found” for Shell. The problem has nothing to do with Shell directly, but it is related to one of it’s deep dependencies.

There are ways to design around this, for example if Toolbar is an optional import on Shell, then Shell will load even if Toolbar is not present. Thus you could check the Toolbar property, determine it is null and throw an exception indicating that there is an issue with the Toolbar or one of it’s dependencies.

Nick has posted an indispensable tool which he discusses in the Preview 6 post which analyzes the container to determine which parts have been rejected and why. Finally in our next drop, Preview 7, (and in Beta 2) you’ll see we’ve added tracing infrastructure that in the debugger will write part rejection messages to the output window. You will also be able to use the tracing to write to a log file at runtime for diagnosing rejection in a deployment environment.

We are planning further guidance on Stable Composition which will ship with our documentation.

Check out Nick’s post for more details on the feature, and as always feedback is appreciated.

MEF and XAML integration – Self composition

Glenn Block — Sat, 18 Jul 2009 11:59:55 GMT

As I am hoping you heard from Nick, we just shipped MEF Preview 6 which includes a version of MEF for Silverlight 3! At the same time that we’ve been wrapping up on our .NET 4.0 release, we are busy working on a proper release for Silverlight vNext. The things you see in MEF Preview 6 for SL3 are just the beginning.

For SL, we are working on among other things, a set of MEF/XAML integration features. One of the problems we want to address is have parts within XAML which are (optimally automatically) composed. That is elements which normally would have to be manually added to the container in the code-behind in order for their imports to be satisfied. For example you drop a control anywhere in XAML that has imports, and it will get composed, regardless of where it sits within the XAML hierarchy.

In order to do this, we’re exploring a pattern we’re calling “Self composition”, that is an unreachable part (one that the container has no access to) can register itself to get composed. The way this works is the part (UIElement) calls a RegisterForComposition method on it’s load event. Calling the method, forces it to get composed by a host-specific strategy, one which in the case of SL might use an app-wide container, or one that is scoped. The important thing is the grid itself is not coupled to how it is going to get composed. For example, see the sample control below.

CustomGrid is a UserControl and it imports a set of IGridBehavior contracts. It’s using MEF for extensibility, thus the application author can deploy behaviors in the container’s catalog, which the grid will use.

So why does the grid need to register itself? Can’t it somehow be created from the container, which will then satisfy it’s imports? Short answer, no. First notice it has no Export, so it will not get picked up by a catalog. But second, the grid itself is declared within XAML, much like any other control, thus the XAML parser is the one who creates it. This would be the case whether it was manually defined within the .XAML file or if the control had been dragged from the toolbox. Thus our only option at that point is to grab the existing instance, and see that it’s imports get satisfied.

But, can’t we somehow take over the creation of the element from XAML, can we have the parser pass of creation to MEF? Actually the XAML 2.0 parser does provide hooks for factories for doing this, however after investigating, there’s a bunch of “devil is in the details” type issues around us doing this, which prevent us from taking this approach, including significant performance hurdles.

One option is to consider using markup extensions, for example an {ImportMany} ME that is a service locator that can be used within XAML. This would allow setting a Behaviors Dependency Property to all imports of IGridBehavior. This could work, however it means that every user of the grid, must explicitly specify one or more markup extensions each time they use the grid, something that is leaky, and very poor from a usability perspective. As a side note, we are actually looking to add Markup Extensions for explicitly specifying imports on Dependency Properties, but that is geared more towards the user of the control vs the author.

Another option is to consider using attached properties, for example a “Compose” attached property would allow specifying Compose=True on our Grid.

Although this is less painful then having to specify all the gory details, it still means that the user of the control must explicitly set this wherever the use it. It means the control author cannot transparently decide to start using MEF without impacting every single XAML file that has ever sited that control.

Now all that being said, in general we're of mixed feelings on the team on the self-registration approach:

On the down-side:

Having parts have to compose themselves is a violation of SOC, in an ideal world, a part should never be responsible for telling itself to get compose. It’s generally a bad idea.
It’s a DRY Violation, my part has imports, yet I still have to “Tell” it to compose itself.
It poses several challenges relating to lifetime management.

On the up-side:

It allows for components which are instantiated by the runtime (in this case FrameworkElements in XAML), and normally unreachable by the container to be able to leverage MEF. This means frameworks (including our own) and applications can gradually migrate to leverage MEF rather than having to be completely re-written / designed in order to leverage composition. It also means that you can use MEF where you see fit, regardless of whether the framework infrastructure supports it.
The pattern can even be extended outside of XAML, for example the same approach could work in Winforms, or ASP.NET Web Forms, or even Mobile. This is possible, because the design relies on a host-specific strategy, thus ASP.NET could provide a per-request container, etc.
Self-registered parts are not coupled to a specific container instance. It's up to the host strategy to decide the container.

What do you think? Do the pros outweigh the cons? Or should we hold off on introducing such functionality because it will cause more harm than good?

Your candid feedback is appreciated.

Meffifying Windows Azure

Glenn Block — Fri, 03 Jul 2009 20:08:00 GMT

Magnus has been off doing some interesting work around integrating MEF with Windows Azure. The first question you might be asking is Why?

In his words, he set out to build a template for Windows Azure templates that:

enables testability

abstracts away storage

is extensible and easy to evolve during development

In the post he shows how to take the RoleManger and expose it through MEF, thereby making it pluggable. He then creates a mock Role Manager for use in his unit tests, thus removing the dependency on all the Azure infrastructure.

I am guessing this is the first of many posts to come on MEF and Azure.

For more, check out Magnus post here.

Upcoming talks at NDC in Oslo and Poland

Glenn Block — Thu, 11 Jun 2009 01:51:00 GMT

Next week, I am heading to Europe for two weeks to give several talks. My first stop is NDC 2009, where I’ll be delivering the following talks:

NDC looks like an amazing event with a great lineup of speakers. I am hoping to be able to attend a few talks so I can soak up all their goodness. All my talks are in one day, so it’s going to be real wild ride!

Next is on to Poland for a 5 city user group tour in: Olsztyn, Toruń, Warszawa, Kraków, Katowice where I’ll be speaking about building extensible apps, or other topics if folks attending would like (comment to this post if you have other topics)

If you are attending NDC or will be in any of the cities mentioned, I look forward to chatting with you about how we can build better software!

Customizing container behavior part 2 of N - Defaults

Glenn Block — Thu, 14 May 2009 11:14:34 GMT

Before I get into the post, let me start off with a word of advice for new bloggers. Never say in a post, this is the first of many to come. RESIST! You are just setting yourself up for never doing that second post. I know as the last post in this series was five months ago. ;-)

In the last post, I introduced the concept of ExportProviders as a way to customize how the CompositionContainer discovers exports. One of the primary use cases for doing this is to provide default exports, which is particularly important for cases where you are importing a single value for which there are multiple present. The common case I like to use is the overused Logger example. Let’s say you have multiple loggers in the system, which are used for different functions. One logger logs locally, while others can log remotely perhaps invoking a web service, or using MSMQ. These loggers are all pluggable, as different organizations that use the app may have different needs. Each of these loggers export an ILogger contract.

Now most of the time when logging occurs the local logger is sufficient. It’s only exceptions to the rule that require the special loggers. And this is where you run into a problem. How do you specify that you need to import that default logger, where there are multiple present? In the default configuration of MEF, the only way to really handle this if you are using imports is to either create a specialized contract for the default logger say IDefaultLogger which is imported, or to import the entire collection lazily using Export<ILogger> and then looking at the metadata for each to find the right one. You could also create a custom service called LoggerService, which imports all the loggers finds the default one, and then returns it when LoggerService.DefaultLogger is called. None of these are optimal though.

For example, you could do this….

[Export]
public class LoggerManager : ILoggerManager
{
    [ImportingConstructor]
    public LoggerManager(Export<ILogger,ILoggerMetadata>[] loggers)
    {
        var logger = loggers.Single(e => e.MetadataView.IsDefault==true);
        DefaultLogger = logger.GetExportedObject();
    }
    
    public ILogger DefaultLogger { get; private set;}

}

The problem is this means the LoggerManager has to have hard knowledge of which logger is the default. It also means the logger itself needs to somehow declare that it is the default, which is problematic because one logger might be the default in one app, but not in another. Separation of concerns anyone? Even worse you might have two loggers that say they are the default!

Now there are other mental hoops you can jump through to find a workable solution, but it’s a lot of pain when what you really want you want to do is tell MEF’s container somehow “This is my default logger for this application”. Not only that but you want to do it in a way that does not require the app to hardcode it, does not require explicit configuration, nor does it require the parts to somehow ‘tell’ MEF they are the default. Also you don’t want the parts that are importing ILogger to have to know or care about a LoggerManager or anything like that. Instead they should simply have an import of ILogger.

[Export]
public class Executor
{
    [ImportingConstructor]
    public Executor(ILogger logger)
    {
    }
}

The $25000 question is how? The answer is using our friendly ExportProvider. In my last post I described the role of ExportProviders, which is to simply return exports. Those exports can come from several different sources, including from catalogs.

Constructing the container with ExportProviders

If you look on the constructor of the container, you’ll see several overloads which accept an ExportProvider.

    public CompositionContainer(params ExportProvider[] providers);public CompositionContainer(ComposablePartCatalog catalog, params ExportProvider[] providers);  

Any export providers passed in to the container are incorporated into the container’s query strategy. This means whenever anyone pulls on the container for an export, these providers will also get queried. Now catalogs have a special provider associated with them called a CatalogExportProvider. As a matter of fact the overload on the container that accepts a catalog is really just syntactic sugar. Behind the scenes we immediately create a CatalogExportProvider passing in the catalog. This means you can pass in an additional default catalog. If you’ve worked with MEF before, you might be shaking your head at this point and thinking “How is this any different than just having an AggregateCatalog and adding two catalogs?” And that IS the key question ;-).

The answer is that adding catalogs to an AggregateCatalog does not allow handling defaults, however using this technique with ExportProviders does. I’ll explain how next.

AggregateCatalogs vs AggregateExportProvider

AggregateCatalog is a catalog that contains a list of catalogs. It is a composite pattern, so querying the parent, queries all the children. This is especially useful when you have parts that are “built in” to the application which are added via an AssemblyCatalog, and other parts which are discovered through a DirectoryCatalog. You can add both catalogs to an AggregateCatalog and everything works nicely. It doesn’t help you though in a default scenario however. The reason is because if one of your catalogs contains your default ILogger and your other catalogs contain the pluggable ILogger implementations, then the aggregate catalog will return them all when it is queried. This means the Executor above will blow up as the constructor is expecting a single ILogger.

For the AggregateExportProvider however, we designed specifically to allow this defaults scenario to be addressed. The provider behaves differently depending on whether it is being queried for a single export or multiple. If the query is for multiple exports, then it works similar to the AggregateCatalog and collects all the exports it finds in any of it’s providers. If on the other hand the query is for a single export, then it uses a prioritization scheme. It will start at the top of the list of ExportProviders and query the first one for the single export (Logger). If it does not find one, then it keeps querying on to the next ExportProvider and so on. Once it finds an ExportProvider that returns one, then it will be returned, if it does not find one, then it will throw an exception.

This means you can have default ExportProviders in the chain (including CatalogExportProviders) that contain your defaults so that the Executor class always succeeds in creation. You can even configure the behavior so that the defaults are overridable or not. For example if you want the default ILogger to always be the logger that is returned for all single import queries no matter what, then put the defaults at the top of the chain. If however you want the default logger to be overridable by another single ILogger, then put it at the end.

Here’s an illustration of what I mean.

    public void OverridableDefaults()

    {

        var catalog = new DirectoryCatalog(@".\Extensions");

        var defaultCatalogEP = new CatalogExportProvider(new DirectoryCatalog(@".\Defaults"));

        var container = new CompositionContainer(catalog, defaultCatalogEP);

        defaultCatalogEP.SourceProvider = container;

    }

In the configuration above, we are placing our defaults at the end of the chain of providers. Remember as I mentioned above that the ‘catalog’ reference will get wrapped in a CatalogExportProvider as well. It will get added first, followed by the additional providers. We then have to set the SourceProvider to the container, I talked about why this is necessary today in my previous post, though it may be possible for us to infer the setting in the future. Anyway, now when a query happens for a single logger, the container will first check the parts in the Extensions folder, and if none are found it will revert to the defaults.

    public void NonOverridableDefaults()

    {

        var defaultCatalog = new DirectoryCatalog(@".\Defaults");

        var catalogEP = new CatalogExportProvider(new DirectoryCatalog(@".\Extensions"));

        var container = new CompositionContainer(defaultCatalog, catalogEP);

        catalogEP.SourceProvider = container;

    }

In this example, we are passing in the default catalog first, and then passing the catalog (as an EP). This configuration now means that the defaults are NEVER overridable, as whenever the container is queried for a single logger, it will ALWAYS return the default.

Using Type or Assembly Catalogs for defaults

Now in the approach above we are using DirectoryCatalogs for specifying defaults. But remember, this is an option, you don’t have to, and in many cases might not want to. For example you might want to just specify your list of defaults in code, or even in a config file. TypeCatalog provides a great way to do this. (It accepts a params of Types, so you can add as many as you want).

    public void OverridableDefaultsWithTypeCatalog()

    {

        var catalogEP = new CatalogExportProvider(new DirectoryCatalog(@".\Extensions"));

        var defaultCatalogEP = new CatalogExportProvider(new TypeCatalog(typeof (ILogger)));

        var container = new CompositionContainer(catalogEP, defaultCatalogEP);

    }

OK, so now that you sold me, what are the caveats?

As with all things, there are some. Really, I can only think of one primary one, and that is that there’s still a bit of indeterminism as to what will get returned on a single import depending on how you set up the provider chain. If you go with the approach of putting defaults first, then it is completely deterministic. You know that whenever a single import request is issued to the container, the exports in that catalog will be returned, period. If however you arrange the defaults at the end of the chain, then it really depends on what is in the middle. Let’s say you have 3 EPs, and the one in the middle has a part with the single export that you are looking for, while you also have a default. In that case the one in the middle will get returned. Another caveat might be that this does add a bit of complexity, however I would argue that’s a reasonable trasdeoff to having to import collections all over the place.

The code

You can download sample code that illustrates using ExportProviders in various fashions here

If you look inside, you’ll find much more than just what we covered here. Including how to do do role based composition, or even wire MEF to a configuration store where config info is an import. All of this will get covered at some point.

Additionally:

You’ll find several test classes which are using a context/specification style of testing to illustrate how to use ExportProviders. If you are not familiar with BDD/CS it may seem very foreign, but I think you’ll find it easy to follow once the initial shock wears off. Having gone through this experience made me a big fan of CS style, and that is for another post.
You’ll find several test helper classes I’ve written specifically for MEF. These are really useful for folks writing their own ExportProviders and who wish to mock / fake certain parts of our programming model. Specifically I am talking about FakeExportDefinition and FakeExportProvider. Additionally you’ll see some common classes I’ve used for my own CS experiments.

For stuff relating to what was covered in this post, go check out the Import_Logger_Specs.cs unit-tests.

Special thanks to Scott Bellware as well as Scott C. Reynolds and David Foley who invested a lot of time and effort in getting me off the ground in using this style of testing. Without their help, I would have been stranded in a pool of confusion. This post is really not doing CS justice, and I really need a separate series. I can’t guarantee that I’ll get to it, but I’ll try.

What’s next

In the next post we’ll talk about establishing parent-child containers hierarchies. You may be asking how does this relate to ExportProviders? I’ll leave you with this thought to ponder, our container IS an ExportProvider.

“View Model” - the movie, cast your vote.

Glenn Block — Tue, 05 May 2009 06:58:28 GMT

http://www.flickr.com/photos/richardmoross/3064808115/

No we’re not actually making a movie about View Model. If we were I am sure we’d get a low turn-out. :-) However it did get your attention.

What we are doing is some serious exploration into how we can help from a platform perspective folks that are implementing ViewModel (AKA Model-View-ViewModel AKA Presentation Model) in their Silverlight and WPF applications.

In the sense of a movie production, we’re in the script-writing phase. Here’s the general background.

Why is ViewModel important?

There have been many a post on the importance of ViewModel as a pattern and the benefits it brings. In that there is little disagreement that it benefits both developers and designers.

For developers it allows them to have clean separation of presentation logic from the UI rendering, thus making the app easier to maintain. It removes code from the code-behind that often makes the UI logic difficult to test.

For designers it provides a way for a designer to completely change the look of the UI in a tool such as Expression Blend, without breaking the application functionality. Furthermore it gives the designer freedoms beyond simple look and feel, to actually decide which data elements are exposed, as well as defining the interactions between the UI elements through commands and attached behaviors.

The debate over roles

Although the benefits of ViewModel are known, there’s quite a lot of debate both inside and outside Microsoft on the roles the developer and designer play in developing applications that use the pattern. This runs the spectrum from the designer having complete control of every aspect of the UI, to the development team having more of a tight handle on the UI components, and the designer being responsible for skinning. In either case there are tradeoffs.

What is important to you?

What is your experience with ViewModel today?

Where does the platform help,? Where does it hinder?
What can we do in the platform to make life easier?
What role do developers / designers play in your application of ViewModel.

Like any movie, we need to touch on the right nerves in order to make it a box-office hit. We need your feedback so we can complete the script.

Thanks for your help

MEF Preview 5, changes and enhancements

Glenn Block — Sun, 12 Apr 2009 09:10:16 GMT

We recently shipped MEF preview 5 on Codeplex, an exciting release.

In the latest release, you’ll find we’ve made quite a few changes, and some really powerful enhancements to our previous codebase. In this post, I’ll talk about those changes in detail, and why we made them. I’ll also discuss some changes we will be making in the future, in order to give you a heads up, so that you can adjust your code bases now.

Throughout the development of preview 5, we’ve done our best to minimize the impact to you. There are some breaking changes, primarily in terms of namespace refactoring, most of which do not effect part authors, but will effect MEF hosters, and authors of custom programming models or export providers.

Here’s a summary of these changes for those who want to just cut to the chase. For those who want the full skinny, that comes after the summary.

Change	Summary description
New sample application, MEF Studio	We have included a new sample application which is a mock pluggable IDE using MEF.
Namespace changes	System.ComponentModel.Composition – For part authors System.ComponentModel.Composition.Hosting – For hosters System.ComponentModel.Composition.Primitives – Infrastructure for defining programming models System.ComponentModel.Composition.ReflectionModel – Services for implementers of catalog caches, and for reflection based programming models.
Part Discovery Model and Lifetime Changes	CompositionOptions has been removed New PartCreationPolicyAttribute for specifying part lifetime (Replaces CompositionOptionsAttribute.CreationPolicy ) Exports are not discovered on base classes by default New PartNotDiscoverable attribute for specifying that a part should not be discovered by the catalog. (replaces [CompositionOptions(DiscoveryMode = DiscoveryMode.Never)]) New PartExportsInherited attribute allows a base class / interface to declare itself as discoverable by inheritors. (replaces [CompositionOptions(DiscoveryMode = DiscoveryMode.Always)] )
Collection Imports	New ImportManyAttribute replaces ImportAttribute on collections in the future. Array imports are now supported
Typed Import/Exports	Imports and Exports now match on type as well as contract. Exporters of string contracts such as [Export(“Foo”)] must now specify the type they expect to be imported as well. e.g. [Export(“Foo”, typeof(string))]
Custom delegates	Method exports can now use custom delegates in addition to Action and Func
Directory Catalog changes	DirectoryCatalog no longer has watching functionality. We’ve added a Refresh() method for explicit refresh.
Removal of caching / new infrastructure	Old caching infrastructure has been ripped. We’ve added a new more general purpose API that is more flexible, and supports builders of custom programming models. We are not shipping a default caching implementation of that API in the box, but one is available in our samples.

MEF Studio

MEF Studio is a designer hosting sample. It has an IDE that hosts various designers like Windows Forms, UserControl, etc. One can add controls on to these designers from the toolbox, set properties using the property grid, view generated code, etc. It provides design time experience for the designers and has extension points for extending the adding custom parts.

Migrating from preview 4

When you upgrade your existing apps, you will likely run into a few issues. Wes put together the following useful list of common errors that you might run into when migrating.

System.ComponentModel.Composition.Container does not exist -> Add reference to System.ComponentModel.Composition.Hosting namespace
CompositionContainer does not container method AddPart or Compose -> Need to start using CompositionBatch, or one of the helper extension methods ComposeParts or ComposeExportedObjects
CompositionOptionsAttribute does not exist -> For CreationPolicy use PartCreationPolicyAttribute
INotifyImportCompleted does not exist -> Use IPartImportsSatisfiedNotification interface and change method from ImportCompleted to OnImportsSatisfied

Part Lifetime changes

Previously, the CreationPolicy property of the CompositionOptions attribute was used to declare a part’s lifetime. We found this was less discoverable for customers as they have to know about the existence of the attribute. We also found that CreationPolicy was ambiguous in name, as it does not make clear whether or not the policy applies to the part or the export.

With the new changes, you will use the new PartCreationPolicyAttribute. CompositionOptions has been removed. Having part in the name of the attribute makes it easier to discover, and also removes ambiguity as to it’s scope.

Below the Logger class is declared as shared:

[PartCreationPolicy(CreationPolicy.Shared)]
[Export(typeof(ILogger))]
public class Logger : ILogger
{
}

Part Discovery / Inheritance

In MEF Preview 4, a part by default would be discovered if there was an export on the most derived class. Additionally a part author could decorate the part with the CompositionOptions attribute, and set the DiscoveryMode property to change the behavior. Regardless of which mode was chosen, we would always look at all exports in the inheritance chain and discover them once we determined a part was a part.

We heard quite a bit of feedback both internally and externally around both the naming of the different enum values for DiscoveryModel, and the resulting behavior.

Default Behavior

By default we will only look only at the most derived type to discover exports. If exports are found, then we will do a deep dive to discover all imports wherever they live in the hierarchy, including interface members. This is because imports are an implementation detail of a part, and the part many not function without them.

In the example, we will discover a single export of IOrderScreen, and the OrderList import.

[Export(typeof(IOrderScreen))]
public abstract class OrderScreen : IOrderScreen
{
 [Import]
 public IOrderListView OrderList { get; set; }
}

[Export(typeof(IOrderScreen))]
public class NorthwindOrderScreen : OrderScreen
{
}

Below, we will not discover anything, as the export is on the base.

[Export(typeof(IOrderScreen))]
public abstract class OrderScreen : IOrderScreen
{
}

public class NorthwindOrderScreen : OrderScreen
{
 [Import]
 public IOrderListView OrderList { get; set; }
}

Inherited exports behavior – using the PartExportsInheritedAttributed

The PartExportsInherited attribute allows declaring on a base class or an interface that it’s exports should be discovered by inheritors / implementers. This replaces the previous [CompositionOptions(DiscoveryMode = DiscoveryMode.Always)]. This basically allows you to define a template for a part, and is useful hiding MEF’s implementation details from a part author. Implementers can further extend on what has been provided, such as adding their own exports and imports.

There’s a few guidelines / caveats to using this feature.

PartExportsInheritedAttribute only makes the exports of the type it decorates discoverable by inheritors. It does not make exports of derivers of that type discoverable. The deriver itself needs to be decorated in order to make its exports discoverable.
We will ignore loose ExportMetadata attributes (and custom metadata attributes) that do not have an associated export.
If an inheritor overrides a member from the base which has an export, and decorates the overridden member with an export, two exports will be discovered, even if the contract names are the same. This means if you expect implementers to add their own metadata, this might not be the best option, or at least you will need to provide special handling. We are looking into changing this behavior to have the inheritor override rather than be additive.

In the example below, NorthwindOrderScreen will automatically export IOrderScreen.

[PartExportsInherited]
[Export]
public interface IOrderScreen
{
}

public class NorthwindOrderScreen : IOrderScreen
{
}

Below NorthwindOrderScreen exports 2 instances of IOrderScreen, one with metadata and one without. The explicit export of IOrderScreen by NorthwindOrderScreen is in addition to the existing export.

[PartExportsInherited]
[Export]
public interface IOrderScreen
{
}

[ExportMetadata("Customer", "Northwind"]
[Export(typeof(IOrderScreen))]
public classNorthwindOrderScreen :IOrderScreen
{
}

Ignoring part discovery – Using the PartNotDiscoverableAttribute

This attribute replaces replaces [CompositionOptions(DiscoveryMode.Never). It is useful for when a part author has parts that they do not want to be automatically discovered by catalogs and . The scenarios where this make sense are where you either have a part which you will manually compose outside of a catalog, or you have a part that you intend for inheritors to use in a catalog but which cannot be made abstract.

In the sample below, class OrderScreen will be ignored by the catalog. However, when class NorthwindOrderScreen is scanned, we will discover IOrderScreen, and will satisfy the OrderList import.

[PartNotDiscoverable]
[PartExportsInherited]
[Export(typeof(IOrderScreen))]
public class OrderScreen : IOrderScreen
{
 [Import]
 public IOrderListView OrderList { get; set; }
}

public class NorthwindOrderScreen : OrderScreen
{
}

Changes to collection imports

ImportMany attribute

We’ve added a new [ImportMany] attribute. This attribute is to be used for specifying that an importer is expected to import all parts that match the contract. This attribute is equivalent to using [Import] on collections today. By our next release however, [Import] will change to mean import an exported collection.

Once we make the switch, the [ImportMany] attribute will be required on both properties and importing constructor parameters in order to get the same behavior as today.

As an example let’s take an importer of a collection of IOperation contacts.

With the new build the following will have identical results.

[Import]
public IEnumerable<IOperation> Operations { get; set; }

[ImportMany]
public IEnumerable<IOperation> Operations { get; set; }

In the next drop, the behavior of the first will change. Instead of importing all exports of IOperation, it will instead be looking for an exporter of IEnumerable<IOperation>. The main reason for this is to support custom collections. Today for example the following code won’t yield the expected results if IRepository<T> is an ICollection<T>.

[Import]
public IRepository<Customer> Customers { get; set; }

What the part author is intending here is to import a repository of customers. The repository as a whole is the import. Instead what will happen today is the container will set Customers to a new instance of Repository<Customer>. It will then query for all the Customer exports and add them to the Repository.

Array imports

In this release we’ve added support for array imports. This allows the following syntax to be supported.

[ImportMany]
public IOperation[] Operations { get; set; }

Future Deprecation of ExportCollection<T> and ExportCollection<T,M>

In the next preview (not this one) we will be removing ExportCollection from MEF. The reasoning is that ExportCollection does not introduce any additional functionality, and we don’t want to introduce a collection which is solely there for syntactic sugar. The alternative recommended syntax for doing ExportCollection will be to use the new array support. Using the new syntax is significantly more compact than using ExportCollection, and is also less cryptic as arrays are very clear as to how they function.

[ImportMany]
public Export<IOperation>[] Operations { get; set; }

[ImportMany]
public Export<IOperation, IOperationMetadata>[] Operations { get; set; }

Additionally we support custom derived collections, thus you can easily create your own collections that provide the sugar.

Typed Import/Exports

In Preview 4, MEF discovers exports based on contract name, and not based on the type of the exporter. This means that an export can actually have an incompatible type with the importer. At the time when the export is set on the import, if the cast fails, then an exception is thrown.

This new feature in Preview 5 enables MEF to match imports and exports on contract AND type. When a part imports a contract, it additionally specifies the specific type that it is looking for. Only those exporters that also match on the importer type are matched. This means instead of failing, if the exporter’s type is incompatible, then it will not be matched.

In most cases, the type specification is done implicitly, and does not require any work on the part of the part author. The overloads of Export and Import that used to take Type as param, will now in addition to converting to the string contract representation, also embed the type information.

For example the code below works as it would have before.

[Export]
public class Editor
{
 [Import]
 public ISpellChecker SpellChecker { get; set; }
}

[Export(typeof(ISpellChecker))]
public class SpellChecker : ISpellChecker
{
}

However code that uses pure string contracts, will yield a different result than it would have before. The SpellChecker below will not be imported into the Editor.

[Export]
public class Editor
{
 [Import("SpellChecker")]
 public ISpellChecker SpellChecker { get; set; }
}

[Export("SpellChecker")]
public class SpellChecker : ISpellChecker
{
}

Although SpellChecker implements ISpellChecker the type that the export carries is SpellChecker. The importer on the other hand is of type ISpellChecker so they do not match. In order to make the above code work, the export needs to specify the type.

[Export("SpellChecker",typeof(ISpellChecker))]
public class SpellChecker : ISpellChecker
{
}

This works as long as the type of the importer is ISpellChecker. Another option is for the importer to lift the restriction altogether by specifying the type as object.

[Export]
public class Editor
{
 [Import("EditorContracts.SpellChecker",typeof(object))]
 public EditorContracts.ISpellChecker SpellChecker { get; set; }
}

Now SpellChecker can be imported by any importer with the same contract name as long as the importer is either a SpellChecker or a derived type.

Custom delegates

In Preview 4, we only support Func and Action delegates for exports. Back by popular demand, we now support custom delegates again as we did in our earlier previews. This means that when you export a method, you can use a custom delegate, as opposed to having to use one of the pre-baked ones. For example in the code below, the Validate method is exporting ValidatorDelegate<Customer> which CustomerView is importing. String contracts are also fully supported.

public delegate bool ValidatorDelegate<T>(T value);

public class CustomerValidator
{
  [Export(typeof(ValidatorDelegate<Customer>))]
  public bool Validate(Customer customer)
  {
    return customer.Name != null && customer.Name != String.Empty;
  }
}

[Export]
public class CustomerView
{
  [ImportingConstructor]
  public CustomerView(ValidatorDelegate<Customer> validator)
  {
  }
}

Directory Catalog changes

Prior versions of the DirectoryCatalog internally used a FileSystemWatcher in order to notify the catalog that changes have occurred within the watched directory. Using the watcher was problematic for many reasons usually related to MEF trying to grab the file too early. Today it is very common for apps that enable the watcher to fail whenever a file is dropped in the folder.

As such we removed the watching functionality and replaced it with an explicit Refresh() method. The advantage of the refresh is it allows the host to determine when the refresh should occur. For example, a .NET Reflector type app could have a refresh button on the addins screen, the rescans the folders on demand. Once the folder is scanned, the catalog will do the delta to determine any changes, and it will fire change notifications as it does today, thus triggering re-composition in the container.

public class Application
{
  private DirectoryCatalog catalog;

  //triggered by the user clicking the Refresh button on the addins page
  public void Refresh()
  {
    catalog.Refresh();
  }
}

Removal of caching / new infrastructure

We found several issues with our previous caching design which was black box. We’ve completely removed the old caching apis. We’ve added in a new API that can be used for caching, however we are not including a default caching implementation within MEF itself. We will however be shipping a caching API sample which illustrates how to use the APIs. The new APIs provides the further benefit of making it much easier to build new programming models that utilize reflection for are reflection based.

We’ve now introduced a new set of classes in System.ComponentModel.Composition.ReflectionModel that can be used by cache implementers. ReflectionModelServices provides a set of static helper methods that can be used for manufacturing part definitions from a cache store.

Summary

A lot of new things to play with in preview 5. My personal favorite is the support we’ve now added for exports on interfaces, though I am sure if you ask different members of the team you’ll get a different answer.

Thanks as always to the team for all their efforts, and thank you for your continual patience and feedback. We’re getting closer and closer to RTM!

So what are you waiting for? Go download MEF Preview 5 here.

Creating a functional programming model for MEF

Glenn Block — Fri, 03 Apr 2009 13:06:00 GMT

Disclaimer: This is a prototype, not production ready code. It is more illustrative of what you can do with MEF, and how things work under the covers.

The other day I was working one of our internal partners who is looking to integrate MEF into their framework stack. One of the interesting ideas that came out of that discussion was around a need they had to add POCO instances directly to a catalog (in addition to using our standard attributed part).

Now MEF supports the ability to add existing instances to the container through the AddExportedObject method, but that did not suit their need. Instead they wanted these instances to actually be parts. Primarily because the types they were instantiating were not attributed MEF parts, and they did not want to incur the reflection cost.

I started thinking down the path of creating a programming model where the part definitions are actually wrapping instances. What I mean by programming model, is teach MEF a new way to represent parts, exports and imports. In MEF parlance, a programming model is almost like a type system, though far less complex. For more on programming models themselves, i'd refer you to Daniel's nice post on programming models themselves here.

Out of the box, MEF ships with an attributed programming model, however others can be created by implementing on top of a set of abstractions we call the primitives. What’s really nice about MEF is that all of the models can safely interact with one another in the container.

Building an instance model however is problematic in that parts in MEF should be lazily instantiated. I realized (probably due much influence of my Autofac workmate Nick Blumhardt) that the right way to go was not build an instance model, but rather build a model for representing functions as parts. And so, the FuncCatalog was born.

FuncCatalog

The FuncCatalog allows you to add functions directly to itself, and to associate those functions with a type to be exported. Each function gets a single parameter which is an ExportProvider. This allows you to build up an instance within your function, that can have constructor parameters pulled from the EP, similar to the registration style in Autofac.

Below is a sample acceptance test that illustrates how this works. In the example I am adding a function to funcCatalog which creates an OrderService. In the OrderService’s constructor, I am passing in an ILogger that I retrieved from the Export Provider.

[TestMethod]
public void FuncPartCanImportFromTheContainer()
{
var catalog = newAggregateCatalog();
catalog.Catalogs.Add(newTypeCatalog(typeof (AttributedLogger)));

    var funcCatalog = new FuncCatalog();
    funcCatalog.AddPart<OrderService>(
        ep => new OrderService(ep.GetExportedObject<ILogger>()));
    catalog.Catalogs.Add(funcCatalog);

    var container = new CompositionContainer(catalog);
    var batch = new CompositionBatch();
    batch.AddExportedObject<ExportProvider>(container);
    container.Compose(batch);

    var service = container.GetExportedObject<OrderService>();
    Assert.IsNotNull(service.Logger);
}

In terms of what the code is doing, I am first creating an aggregate catalog (a catalog of catalogs). Then I am adding to it a type catalog which contains an AttributedLogger (that is a logger with an ExportAttribute on it). Next I am creating a FuncCatalog which I am adding the new func part to. Notice how the lambda passes ep.

ep => new OrderService(ep.GetExportedObject<ILogger>())

Next I am creating the container, and then adding itself to itself (via the batch) with ExportProvider as the contract. This is to allow the FuncPart to import the ExportProvider so it can use it to resolve other dependencies.

Finally I am asking the container to grab me an OrderService, which I am then checking to see if there is a logger present. Remember the logger actually was an attributed part that was added through MEF’s normal catalogs. So right here we have an illustration of multiple models living side by side.

How is it done?

As I mentioned above, I created a custom programming model. Depending on the model, this can be a lot or a little work. Andreas Haakanson has a project on CodePlex that simplifies creating such programming models, but that is for another overdue post :-) Below I’ll detail the approach I took in order to give you a view into how programming models work.

Programming model players

Below are the main abstractions you need to implement for building your own programming model which live in the System.ComponentModel.Composition.Primitives namespace.

Here’s a quick summary of the responsibilities for each of these classes.

ComposablePartDefinition – Schema for a part, analogous to a type in many respects. As a matter of fact in our default Attributed Programming Model (APM), the Composable Part Definition wraps a type. Aside from being schema, the other main responsibility for CPD is to create a composable part.
ImportDefinition – An import definition is carries information about a contract that a part needs, it’s import. In the APM, import definitions are created for properties decorated with the ImportAttribute, or constructor parameters if the constructor has an ImportingConstructorAttribute.
ExportDefinition - An export definition carries information about a contract that a part offers up, it’s export. In the APM, an export definition is created for each member that is decorated with the ExportAttribute. This includes the class itself, or methods / properties.
ComposablePartCatalog – The catalog aggregates part definitions, which the container will query during composition in order to find available exports. The catalog does not create any parts, it only returns requested definitions. In our APM, the catalogs read assemblies and types in order to create these definitions.
ComposablePart – The part itself. If the CPD is the schema, then the part is the instance. This does not mean it is the actual instance that is being returned from the container. No. The part contains an instance which will get created only at the time when the first exported object actually pulled from it. There’s a difference between an export and an exported object, but I’ll resist to go deeper and try to explain it for now.

In my new model I implemented FuncCatalog, FuncExportDefinition, FuncPart, and FuncPartDefinition. I did not need a new ImportDefinition as the standard one was fine. Also my parts only support a single import, namely an ExportProvider.

FuncExportDefinition

Ok, so first stop is to build a FuncExportDefinition. In my case I need a definition that carries a custom function. So here it is.

public class FuncExportDefinition : ExportDefinition
{
    public FuncExportDefinition(string contractName, 
        Func<ExportProvider,object> factory) :
        base(contractName, null)
    {
        Factory = factory;
    }

    public Func<ExportProvider, object> Factory { get; private set; }
}

Pretty simple, I basically allow associating a contract and an additional func which accepts an ExportProvider as a parameter and returns object. Now notice the second parameter I pass to the base class is null. That represents metadata. I decided for simplicity to not allow support of metadata, though that could easily be added back.

FuncPartDefinition

Now that I can define Funcs as exports, I need a PartDefinition which can carry that information, and manufacture a part. This one was a bit tricky, below are the important pieces.

public abstract class FuncPartDefinition : ComposablePartDefinition
{}

public class FuncPartDefinition<TContract> : FuncPartDefinition 
{
    private static ContractBasedImportDefinition 
        _exportProviderImportDefinition;


    static FuncPartDefinition()
    {
        string importContractName = CompositionServices.GetContractName
            (typeof(ExportProvider));
        _exportProviderImportDefinition = new 
            ContractBasedImportDefinition(
            importContractName, null,
            ImportCardinality.ZeroOrOne, false, false,
            CreationPolicy.Any);
    }

    public FuncPartDefinition(Func<ExportProvider, object> factory)
    {
        _exportDefinitions.Add(new FuncExportDefinition
            (CompositionServices.GetContractName(typeof(TContract)),
            factory));
        _importDefinitions.Add(_exportProviderImportDefinition);
    }

    public FuncPartDefinition()
        : this((ep)=>(TContract) Activator.
            CreateInstance(typeof (TContract)))
    {
    }

    public override ComposablePart CreatePart()
    {
        return new FuncPart<TContract>(this);
    }
}

As I mentioned earlier, my func parts need to access an ExportProvider so they can retrieve things from the container. The question was how to do this. I could make the ExportProvider a parameter on the constructor of the part. Then however, I would have to pass it in to the catalog, which would pass it in to the part. This is further problematic as catalogs can actually be passed to several containers. So I decided the easiest way to do it, was to have the part actually import the ExportProvider through MEF’s composition, that is similar to the way I would import on an attributed part through a constructor param.

In order to do this, all I need is to add a single ImportDefinition to every part instance. The static constructor of FuncPartDefinition does the work of creating this definition. The definition never changes, and it is cheaper to create it once, which is why I made it static.

The instance constructor accepts the func. It then goes and creates a FuncExportDefinition which it adds to the collection of export definitions. Next it adds the export provider import. I added an additional overload just as a convenience which simply creates the type. Probably just being gratuitous ;-)

Finally the CreatePart method goes and creates a FuncPart passing in the definition (the part’s schema) which leads us to our next suspect.

FuncPart

This guys job is to pass back export definitions of our func, to the container on request. Those definitions can later be activated to invoke the actual func.

public class FuncPart<TContract> : ComposablePart 
{
    private FuncPartDefinition<TContract> _definition;
    private ExportProvider _provider;

    public FuncPart(FuncPartDefinition<TContract> definition)
    {
        _definition = definition;
    }

    public override object GetExportedObject(ExportDefinition definition)
    {
        var funcExportDefinition = definition as FuncExportDefinition;
        return funcExportDefinition.Factory(_provider);
    }

    public override void SetImport(ImportDefinition definition, 
        IEnumerable<Export> exports)
    {
        _provider = exports.First().GetExportedObject() as ExportProvider;
    }

    public override IEnumerable<ExportDefinition> ExportDefinitions
    {
        get { return _definition.ExportDefinitions; }
    }

    public override IEnumerable<ImportDefinition> ImportDefinitions
    {
        get { return _definition.ImportDefinitions; }
    }
}

When the part gets constructed, it stores a copy of it’s definition. The ExportDefinitions and ImportDefinitions delegate directly to the part definitions members. In the SetImport method I have got a bit of a hack going on. This method will get called by the composition engine to set the imports. In the method, I am grabbing the first export passed in and then assuming it is the export provider. This is actually an OK assumption in my case, since there is only a single import that I allow in my programming model. However, I really should be verifying that it is passing me the right definition.

And just when you thought I was done with hacks, another one :-) GetExportedObject takes the definition passed to it and assumes it is a FuncExportDefinition. Again, this is an ok assumption in the cases where I am using it, but it should be more bullet proof and not make those assumptions. Anyway, once it has the definition unwrapped, it grabs the factory and invokes it passing in the provider.

FuncCatalog

Last stop on our journey is the func catalog. He’s actually pretty straightforward. I added a few convenience methods on him so that you don’t have to create parts a head of time.

public class FuncCatalog : ComposablePartCatalog,     
    INotifyComposablePartCatalogChanged
{
    private List<ComposablePartDefinition> _parts = new List<ComposablePartDefinition>();

    public FuncPartDefinition AddPart<T>(
        Func<ExportProvider, object> factory)
    {
        var addedParts = new List<FuncPartDefinition>();
        var definition = new FuncPartDefinition<T>(factory);
        _parts.Add(definition);
        
        addedParts.Add(definition);
        OnChanged(addedParts);
        return definition;

    }

    public void AddParts(params FuncPartDefinition[] parts)
    {
        _parts.AddRange(parts);
        OnChanged(parts);
    }

    public void RemoveParts(params FuncPartDefinition[] parts)
    {
        _parts.RemoveAll(c => parts.Contains(c));
        OnChanged(parts);
    }
    
    public override IQueryable<ComposablePartDefinition> Parts
    {
        get
        {
            return _parts.AsQueryable();
        }
    }

    private void OnChanged(IEnumerable<FuncPartDefinition> parts)
    {
        var args = new ComposablePartCatalogChangedEventArgs(
            parts.Cast<ComposablePartDefinition>());
        Changed(this, args);
    }

    public event EventHandler<ComposablePartCatalogChangedEventArgs> 
        Changed = delegate { };
}

First thing is the catalog implements INotifyComposablePartCatalogChanged. This is to allow the catalog to notify the container when parts are added or removed from it. Implementing a catalog only requires to to override one property, namely the Parts property, which as you can see returns a queryable of Parts. The rest of the methods are concerned with the mutability of the container. Now catalogs do not have to be mutable, as you can handle loading up all the part defs in the constructor. However, for usability sake, I wanted mine to be mutable. This means that I need to have methods for adding, removing, and I need to support notification. The code should be pretty easy to follow.

So what have we learned?

Well first thing we learned that MEF supports alternative programming models other than the attributed model we ship in the box. Next, we learned about the key concepts involved in authoring your own programming model. In this case the model was very, very simple, which is why I was able to cover it in a single post. I am not recommending every one go out an author their own model. Lastly we saw learned that parts can be functions :-)

If your interested in other applications of programming models in MEF, I recommend you check out Nick Blumhart’s posts on Ruby. Also don’t forget to check out Andreas’s provider based programming model on MefContrib.

Why doesn’t MEF support open-generics for exports? Because MEF is not type based.

Glenn Block — Sat, 21 Mar 2009 23:14:00 GMT

Update: We've posted an extension for doing open generics in MEF contrib. Read about it here: http://blogs.msdn.com/gblock/archive/2009/08/20/open-generic-support-in-mef-contrib.aspx

I get this question all the time. Recently it popped it’s head on the forums in this thread (which I referred to in my last post)

In that thread, Andrew was asking why the following does not work?

[Export(typeof(IDomainController<>)), CompositionOptions(CreationPolicy = CreationPolicy.Shared)]

public class DomainController<T> : IDomainController<T>

  /* some code here */

  [ImportingConstructor]

  public DomainController(IRepository repository)

    _Repository = repository

That is he wants to export a generic IDomainController with the idea the closed generic versions like IDomainController<Customer> could be imported.

He also rightly observed that many of the IoC containers that exist support this functionality including Unity. (I chuckled when I heard that because I was in p&p when we first wrote Unity) However, it is a valid question, why don’t we support it? This is one of those questions that I, Hammett and Nick all asked when we joined the team. We do support closed generics without a problem, but not open. Why?

As you dig into the details, it quickly becomes clear. The root of the answer is that MEF is not type based, it is contract based. Below are the details from my response…

MEF parts relate on contracts which are strings, not types. To illustrate, see the code below.

namespace Orders {

  public interface IOrderRepository {}

  [Export(typeof(IOrderRespository))]

  public class OrderRepository : IOrderRepository {

Although I have passed typeof(IOrderRepository) to the export, that is just a convenience that gets converted to a contract name of "Orders.IOrderRepository". The same applies to the importer...

[Export]

public class OrderService(

  [Import]

  public IOrderRepository Repository {gets;set;}

The import on IOrderRepository also gets converted to a contract name of "Orders.IOrderRepository". During composition, the container is able to satisfy the import as the 2 contracts match. In the same way we support closed generics, so this code....

public interface IRepository<T> {}

[Export(typeof(IRepository<Order>))]

public class OrderRepository : IRepository<Order> {

[Export]

public class OrderService(

  [Import]

  public IRepository<Order> Repository {gets;set;}

will work because the OrderRepository is exporting the contract name "Orders.IRepository<Order>" and the OrderService is importing the same contract.

However, this is what it looks like if we try the same with open generics.

public interface IRepository<T> {}

namespace Utils {

  [Export(typeof(IRepository<>))]

  public class Repository : IRepository<T> {

[Export]

public class OrderService(

  [Import]

  public IRepository<Order> Repository {gets;set;}

Now the contract names will be different. The exporter will have a contract of "Utils.IRepository<>" and the importer will have a contract of "Utils.IRepository<Order>".

It is a simple match up, that breaks down in the open-generics case. This is because fundamentally, MEF is not matching on type.

There are theoretical ways to address it, but they are all very ugly, require a lot of string parsing and really go against the grain of MEF’s core design.