The last year in Redmond has been truly amazing. Besides working with the great people in the .NET team and elsewhere at Microsoft – an experience that can’t be done justice in a brief blog post like this – I’ve also had a chance to take in Seattle and to explore the incredible Pacific Northwest.
It might come as a bit of a surprise then to hear that I’m leaving the US to return to Brisbane, Australia. Despite the many attractions of being here, I’ve found that it is too far to be away from my family and friends.
This Friday will be my last day here, and this blog will shortly be going into ‘read-only’ mode, so please find me on Twitter if you’d like to keep in touch.
Nick
This morning Dave came up with a great suggestion for finding MEF composition problems from within Visual Studio.
By registering the composition analyzer as an external tool, the root cause of a composition problem can be located in a flash!
Step 1 - Obtain MEFX.EXE
First, you’ll need to build mefx.exe from the MEF Codeplex Drop (at this time, in the non-Silverlight zip files under /Samples/CompositionDiagnostics).
For demo purposes I’ve placed this (and Microsoft.ComponentModel.Composition.Diagnostics.dll) in C:\Tools.
Step 2 – Register MEFX.EXE as an External Tool
In Visual Studio, select the Tools > External Tools menu item. This will bring up a dialog like the following:
Here you’ll need to click Add and enter the information above. Importantly, select the Use Output Window option.
Note the /causes and /verbose switches. This tells mefx to find parts with missing dependencies that aren’t simply the result of ‘cascading’ failures.
Step 3 – Run Composition Diagnostics
Now that the tooling is set up, finding those composition problems is a breeze!
In my example application, I’m unable to resolve instances of Extensions.Abc:
The exception message tells me that no instances of Abc are available, but I know that it is there in my catalog, so something else must be wrong…
In Solution Explorer, I select the executable project:
Then, under the Tools menu, I click the Debug Composition item that we added in Step 2:
This will analyze all of the assemblies in the output directory of the application, to find the root cause of the composition failure.
NOTE: Currently, only .DLL files are searched, so parts in .EXE files won’t be included in analysis. In a future version of MEFX this will change, but for now, I recommend keeping all parts in .DLL files.
The output of the tool is piped to the Output window:
Let’s break down this output line-by-line.
First, the name of the problematic part is displayed:
[Part] Extensions.Def from: DirectoryCatalog (Path="c:\Workspace\ExampleExtensibleApp\Extensions.dll\bin\Debug\")
[Primary Rejection]
The text Primary Rejection indicates that the analysis identified this as a root cause.
We then see a bit more information about the part, and the status of each of its imports. The problematic import is shown here:
[Import] Extensions.Def.Ghi (ContractName="c")
[Exception] System.ComponentModel.Composition.ImportCardinalityMismatchException: No valid exports were found that match the constraint '(((exportDefinition.ContractName == "c") AndAlso (exportDefinition.Metadata.ContainsKey("ExportTypeIdentity") AndAlso "Extensions.Ghi".Equals(exportDefinition.Metadata.get_Item("ExportTypeIdentity")))) AndAlso ((Not(exportDefinition.Metadata.ContainsKey("System.ComponentModel.Composition.CreationPolicy")) OrElse Any.Equals(exportDefinition.Metadata.get_Item("System.ComponentModel.Composition.CreationPolicy"))) OrElse Shared.Equals(exportDefinition.Metadata.get_Item("System.ComponentModel.Composition.CreationPolicy"))))', invalid exports may have been rejected.
at System.ComponentModel.Composition.Hosting.ExportProvider.GetExports(ImportDefinition definition, AtomicComposition atomicComposition)
at Microsoft.ComponentModel.Composition.Diagnostics.CompositionInfo.AnalyzeImportDefinition(ExportProvider host, IEnumerable`1 availableParts, ImportDefinition id) in C:\Users\niblumha\Desktop\Microsoft.ComponentModel.Composition.Diagnostics\CompositionInfo.cs:line 157
There’s a lot of information here, but the important thing to note is that the import is for property Ghi, which imports contract “c”.
We now know which import in the composition is problematic, and can possibly determine our root cause manually from this information.
More interestingly though, the tool provides some suggestions for fixing this error. Here we’re told that there is a part in the system that looks like it could satisfy the import, but has some problems:
[Unsuitable] Extensions.Ghi (ContractName="c") from: Extensions.Ghi from: DirectoryCatalog (Path="c:\Workspace\ExampleExtensibleApp\Extensions.dll\bin\Debug\")
[Because] TypeIdentity, The export is a 'System.Object', but the import requires 'Extensions.Ghi'. These types must match exactly (conversions are not supported.)
[Because] CreationPolicy, The import requires creation policy 'Shared', but the exporting part only supports 'NonShared'.
Diagnostics in MEF are a high priority for us. The declarative nature of MEF composition gives us a lot of interesting opportunities for tooling, so expect to see more work along these lines.
As always, feedback is appreciated!
Since working on a clinical outcomes review system a couple of years ago, I’ve been aware of the gap between simple hand-coded workflows and the full-blown workflow tools.
Stateless embodies the idea that a state machine can use closures to implement workflow without taking on persistence responsibilities. So long as all of the data used to drive the state machine is external to it, a regular ORM or other persistence mechanism can deal with identity, persistence and transactional issues. This substantially reduces the technical complexity of the framework.
As a ‘fun’ project, I haven’t done much other than maintain the site since the first version was finished. The second version extends the paradigm just a little, but in doing so makes a wider range of scenarios cleanly approachable.
To illustrate the new features I’ll draw on Scott Allen’s nifty bug tracker example for Windows Workflow.
Parameterised Triggers
The triggers that drive transitions in a state machine are approximately analogous to events or commands. Like events and commands, triggers can be associated with parameters.
- When a bug is assigned, the parameter may be the assignee;
- When an order is cancelled, the parameter may be the reason;
- etc.
Modelling these details in Stateless, I adopted the some design goals and constraints:
- Retain the existing simple syntax for non-parameterised triggers;
- Execute parameter-driven logic during the transition, i.e. after the exit events for the last state have fired;
- Make it clear to the user exactly when parameter-driven logic will execute;
- Control interference between parameter-driven logic and guard conditions;
- Ensure parameter type-safety at compile time.
New APIs
To associate parameters with a trigger, StateMachine provides the SetTriggerParameters() generic methods:
SetTriggerParameters() accepts one generic parameter for each of the trigger’s parameters, so in this case the Assign trigger is being associated with a single parameter of type string.
This method is called once, when the state machine is being configured.
The return value in this case is a TriggerWithParameters<string> object that lets us invoke the Fire() method in a strongly-typed way:
The C# compiler will use inference to determine that the parameter to the trigger is of type string. Attempting to fire assignTrigger with any other parameters will be rejected at compile-time.
Now, all of this would be fairly pointless if Fire() was the only place that the parameters needed checking. However, the firing of the trigger is only half of the story.
When the machine transitions into the new state, logic based on the trigger parameters will need to run:
Because assignTrigger is provided to the OnEntryFrom() method, the compiler knows that the provided entry action accepts a single parameter of type string.
Putting everything together behind the facade of a domain object leads to a natural, understandable design:
A more complete example is in the Stateless Mercurial repository.
Alternatives
One alternative I considered but later discarded was to parameterise the states rather than the triggers, something that seems to be more established in traditional state machine models. After a good deal of unsuccessful experimentation I concluded that state parameterisation isn’t as useful as the trigger-based version.
Re-Entrant States
Stateless encourages you to attach program logic to entry and exit events for the states in your state machine.
One of the edge cases that the bug tracker example reveals is re-initialisation of an already active state. When the bug is assigned, an email might be sent to the assignee. If Assign() is called again, to reassign the bug to someone else, it makes sense to re-initialise the Assigned state by executing the exit actions then executing the entry actions again.
To enable this behaviour for a state, the PermitReentry() method is supplied:
The previous version of Stateless considered a self-transition to be the same as an ignored trigger. Version 2 requires that self-transitions are either explicitly ignored, or configured as re-entrant.
Next?
These small additions were actually quite a challenge, but Stateless is still a very small library. One idea I’m toyed with is to use it as a ‘kernel’ for higher-level state machine functionality, e.g. an XML or DSL-driven framework. If you have ideas or requests, feel free to visit the UserVoice forum!
In MEF Preview 6 we shipped a sample assembly called Microsoft.ComponentModel.Composition.Diagnostics, demonstrating the kinds of things that can be determined by (semi-) statically analyzing MEF catalogs.
With Preview 7 we added a utility that makes use of the diagnostics routines to print information about parts directly from the command-line.
C:\Users\...\CompositionDiagnostics> mefx /?
/?
Print usage.
/causes
List root causes - parts with errors not related to the rejection of other parts.
/dir:C:\MyApp\Parts
Specify directories to search for parts.
/exporters:MyContract
List exporters of the given contract.
/exports
Find exported contracts.
/file:MyParts.dll
Specify assemblies to search for parts.
/importers:MyContract
List importers of the given contract.
/imports
Find imported contracts.
/parts
List all parts found in the source assemblies.
/rejected
List all rejected parts.
/type:MyNamespace.MyType
Print details of the given part type.
/verbose
Print verbose information on each part.
The /parts switch list all parts in a composition:
C:\Users\...\CompositionDiagnostics> mefx /dir:..\MefStudio /parts
Designers.CSharp.Commands
Designers.BasicComponentFactory
Designers.CSharpFormFactory
...
While the /rejected and /causes switches will print information about rejected parts and suspected root causes respectively.
By specifying the /verbose switch, detailed information about parts can be retrieved:
C:\Users\...\CompositionDiagnostics> mefx /dir:..\MefStudio /type:Designers.BasicComponentFactory /verbose
[Part] Designers.BasicComponentFactory from: DirectoryCatalog (Path="..\MefStudio")
[Export] Designers.BasicComponentFactory (ContractName="Contracts.HostSurfaceFactory")
[Import] Contracts.HostSurfaceFactory.propertyGrid (ContractName="Contracts.IPropertyGrid")
[Actual] ToolWindows.PropertyGridWindow (ContractName="Contracts.IPropertyGrid") from: ToolWindows.PropertyGridWindow from: DirectoryCatalog (Path="..\MefStudio")
[Import] Contracts.HostSurfaceFactory.Commands (ContractName="System.Void(Contracts.HostSurface)")
[Actual] Designers.CSharp.Commands.Cut (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")
[Actual] Designers.CSharp.Commands.Copy (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")
[Actual] Designers.CSharp.Commands.Paste (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")
There are a few more goodies in there for the curious.
It is important to realise that the utility can only analyze MEF assemblies built against a compatible version of MEF; for example, mefx.exe built against the CodePlex drops will not be able to analyze assemblies built against the signed .NET Framework version of MEF, and vice-versa.
We call these “samples” right because they’re for the purpose of our own exploration. Some experience with applying these techniques will hopefully lead to some great production-quality tools in a future milestone.
One particular direction I’d like to venture is towards tooling suitable for continuous integration (CI), for example, a build task capable of validating component status.
If you have ideas for improvement or an opportunity to try mefx, we’d love to hear from you.
Disclaimer: This functionality is not shipping in .NET 4 (but is available in the recent CodePlex drops, see below for more details.)
The golden rule of using composition to simplify your architecture is to avoid calling the container directly.
Until now, MEF users have had to jump through hoops to observe this rule in some circumstances. The most common of these is dynamic part creation – creating instances of parts on-the-fly in response to application events.
To alleviate this, the latest Silverlight version of MEF in “Preview 7” introduces a Declarative Context Adapter called PartCreator<T>.
PartCreator<T>
Imagine we’re writing a pluggable text editor. The application uses a part to represent the document being edited:
Whenever the user clicks the ‘New’ button, the editor window creates a new instance:
There are a few important things to notice here:
- Every time OnNewDocument() executes, a new instance supporting IDocument is created (in this case the actual object will be of type TextDocument,)
- When MEF sees an [Import] attribute on a member of type PartCreator<T>, it will use the same rules as for Lazy<T> to determine the appropriate contract,
- The parameter T is the type of the exported value, not the type of the underlying part implementation,
- The return value from CreatePart() is a wrapper class, PartLifetimeContext<T>, that implements IDisposable and must be used to clean up the part when it is no longer required,
- PartLifetimeContext<T> has a property Value of type T, in this case T will be IDocument.
MEF supports PartCreator<T> implicitly, in a very similar way to Lazy<T>. There is no additional code required to get this behaviour.
PartCreator<T, TMetadata>
Many scenarios for dynamic instantiation need to select the appropriate part to instantiate from several different implementations.
In this example, imagine we’re building a simple MVC web framework (don’t confuse this with ASP.NET MVC; this is just a made-up exercise, not a serious MVC framework design.)
Developers create controllers to handle the various URLs that the web application responds to. Each controller exports the IController contract, and adds some metadata describing the route that the controller handles.
Here’s part of the controller for the /home page:
Down in the plumbing of our MVC framework, the request handler is going to have to decide which of the available controllers will be invoked by an incoming request.
To do this, the RequestHandler part imports an array of PartCreator<IController, IControllerMetadata>.
When a request comes in (see the HandleRequest() method) the appropriate part creator is chosen and used to create a controller:
Notice that the controller variable is used in a using block. This ensures that the controller and any other resources that were used to construct it will be cleaned up after the request is handled.
Emulating PartCreator<T> on .NET 4
PartCreator<T> is not included in the .NET 4 builds of MEF – it was developed as part of the Silverlight MEF support (where CompositionContainer is much less accessible.) However, with a little work it is possible to emulate some of the PartCreator<T> functionality.
Included with the .NET beta-compatible version of MEF is a sample that supports a limited subset of the feature, under Microsoft.ComponentModel.Composition.DynamicInstantiation.
This assembly includes versions of the part creator types, and an ExportProvider that handles requests for PartCreator<T> when added to the container.
This sample doesn’t fully support all container features, and (as you can tell by the lack of unit tests) may blow up in unexpected ways. Instantiation performance is also not guaranteed, thanks to O(n^2) time complexity on the number of exporters of the contract being instantiated.
We’re including this so that .NET 4 users can experiment with the part creator APIs; it is not yet recommended for production use.
Disclaimer: As usual, this blog post is discussing pre-release software, which may differ from the final released version.
Ayende once observed that MEF is very focused on dependency management. It’s an accurate description of the driving force that has shaped MEF as it is today.
Dependency management doesn’t end at build time with assembly references. Functional dependencies are more complex and harder to control than static compilation unit dependencies. MEF has some nifty tricks up its sleeve to help out with this task.
Imagine the example of a retail management system:
| Standard | Pro Service | Platinum |
| Service Schedule | | X | X |
| Stock Control | X | | X |
| Client List | | X | X |
| Marketing | | | X |
The AdventureWorks Store Manager application has many features. To support pay-for-play licensing, the company sells several versions (‘SKUs’) targeting different market segments, with different features enabled.
All of these versions are subsets of the same essential codebase. Each SKU, or configuration, includes the relevant pieces.
Mapping Features to Components
The implementation of each feature can involve more than one component. Part of the system might look like:
A quick description:
- PointOfSale lets a storeperson process sales
- PointOfSale uses a collection of ItemLookups representing each kind of thing that can be sold
- ProductLookup provides ItemLookup functionality for products, and requires exactly one ProductRepository to do its job
- ServiceLookup is like ProductLookup but for services that may be performed for the client
An important aspect of the diagram is the cardinality of the relationships.
PointOfSale’s one-to-many dependency on ItemLookup is a MEF [ImportMany]:
The one-to-one dependency between ProductLookup and ProductRepository correspond to MEF required imports. The same applies to ServiceLookup and ServiceRepository:
To configure the system, we need to make sure that ServiceLookup doesn’t appear in PointOfSale.ItemLookups when we’re in the “Standard” SKU.
Partitioning the System
‘Classic’ approaches to sub-setting used to revolve around conditional compilation (#ifdefs) or runtime “IsEnabled” checks. While effective, the results of these methods can be very difficult to maintain.
Plug-in systems, or selective registration of components in an IoC container, provide a more intentional, centralized way of managing the contents of a SKU.
Even here there is significant complexity and thus room for improvement. Functional dependencies usually span layers and revolve around multiple pieces of code. Some components will appear in multiple SKUs, while others will be available with different degrees of functionality.
(Note that we ignore assembly-level partitioning here since market-driven functional partitioning does not always match architecture-driven partitioning.)
Enter Stable Composition
Tucked away in the recent announcement of MEF preview 6 was a snippet on what we’ve been calling Stable Composition.
The cornerstone rule of Stable Composition is:
Parts that have missing required dependencies are ‘rejected.’ They appear in the catalog, but the container never uses them.
Now, the impact this has on a system as a whole is more interesting than it would first appear. Not only will parts with missing dependencies be rejected, but so will any parts that transitively depend on rejected parts. One missing dependency can cause a whole graph of components to be ignored.
This isn’t accidental:
Utilising Stable Composition, one can manage just the parts that define a SKU, and MEF will make sure that dependent parts are included or excluded as needed.
Instead of tracking dependency relationships manually to create a master set of components for each SKU, offload this responsibility to MEF.
Configuring AdventureWorks Store Manager Standard SKU
This SKU is characterised by the absence of service-related functionality.
Instead of analyzing all components to determine whether they play a part in service-related scenarios, we make the observation that all such functionality depends on the presence of a ServiceRepository.
When the MEF ComposablePartCatalog is being configured, excluding the ServiceRepository gives us the result we require.
MEF itself will determine which other components depend on the missing functionality and automatically ignore (‘reject’) them:
This behaviour comes out-of-the-box with MEF – there is no need to opt-in or change the way that the CompositionContainer is used.
Single Required Dependencies Only
Rejection typically applies to one-to-one dependencies. The ServiceLookup screen is rejected because it requires exactly one ServiceRepository, and by excluding it from the SKU we’ve effectively disabled the ServiceLookup screen.
The PointOfSale screen’s dependency on many ItemLookups will never cause it to be rejected, since it can effectively function when the number of available ItemLookups is zero.
The other common MEF dependency, represented by an import with AllowDefault=true, is an optional dependency. Since by declaring an optional dependency, a component guarantees that it can operate without the dependency present, optional dependencies do not trigger rejection either.
The special case to look out for is when too many implementations are present, e.g. two ServiceRepositorys. In this scenario components that depend on a single instance will be rejected.
Debugging and Testing
The last drop of MEF included a sample (Microsoft.ComponentModel.Composition.Diagnostics) capable of determining the rejection status of a part. This is useful for debugging at development time, but there’s also an opportunity to do integration-time testing of SKU configurations.
For example, if I’m testing the “Pro Service” SKU and expect ServiceLookup to be available, I might write:
Now, this is a hypothetical test case; I haven’t had an opportunity to use this in anger. It is an interesting possibility though, and worth exploring if you’re going to make heavy use of Stable Composition.
Optional Exports
Why did the title of this post include the term ‘Optional Exports*’? This is a useful way to think about how rejection works. MEF components provide exports that are optional, on the condition that their mandatory imports can be satisfied. The ServiceLookup component provides its exports on the condition that ServiceRepository is available.
You can use this way of looking at the feature to implement some other nifty tricks in the realm of ‘light up,’ but that is for another day!
(*One of the many subtle coinages of Blake Stone – Blake, where’s your blog?)
In the three months that have passed since the last release, we’ve been very busy making final adjustments to get closer to RTM.
In this post I’ve summarized the biggest changes between the Preview 5 and Preview 6 releases.
The highlights are:
- Silverlight support
- Lazy<T> replaces Export<T>
- Collection import changes
- Inheritance changes
- Export attribute is unsealed
- Stable Composition makes its debut
You can download MEF Preview 6 from the CodePlex site.
Silverlight Support
With this release comes an early preview of our Silverlight plans. The included solution MEFSL.sln can be used to build MEF binaries that target the newly-released Silverlight 3.
Those familiar with the full-framework MEF won’t see many differences in the Silverlight build as it stands today. We aim to have some exciting new features in the eventual release, but for now the APIs are the same apart from changes required because of the different environment.
Silverlight Catalog
DirectoryCatalog is not available in the Silverlight version. Instead, this is replaced by PackageCatalog.
This API is tentative and will very probably change in a future preview.
Silverlight Picture Viewer
There’s a new sample called PictureViewer that demonstrates some aspects composition in a Silverlight application.
Lazy<T>
One of the first things you’ll notice when moving to the new build is that the System.ComponentModel.Composition.Export<T> and Export<T, TMetadata> types are gone.
In their place, MEF now recognizes the System.Lazy<T> and Lazy<T, TMetadta> types.
Functionally these types match the old ones, however:
- The GetExportedObject() method is replaced by a Value property
- The raw metadata dictionary is gone (if you truly require this, you can use the IDictionary<string, object> type as a metadata view interface)
Collection Import Changes
The System.ComponentModel.Composition.ExportCollection<T> type has also been removed. In its place, use IEnumerable<Lazy<T>>, or Lazy<T>[].
ImportManyAttribute is now required for all collection imports.
Inheritance Changes
PartExportsInheritedAttribute has been removed. The new mechanism separates inheritable exports from non-inheritable exports.
Exports declared using the ExportAttribute are never inherited.
Exports declared using the InheritedExportAttribute will be exposed by sub-classes of the part type.
Custom Export Attributes
In previous releases, ExportAttribute was sealed.
It is now possible to subclass ExportAttribute, and this can be combined with the existing MetadataAttribute functionality.
This means that instead of:
It is possible to define a custom attribute that completely describes the export:
Thus users can declare both the exported contract and its metadata using only one attribute:
We expect this will be very useful for authors of extensible frameworks.
Note: We have also unsealed ImportAttribute, ImportManyAttribute and ImportingConstructor thus allowing these to be extended as well.
Stable Composition
As an extensibility framework, it is important that MEF applications start and execute reliably even when some extensions lack required dependencies.
Stable Composition contributes to this goal by validating dependencies in advance.
Part Definition Rejection
In earlier releases, MEF would hand out lazy exports from parts with missing dependencies. Later, when the export was used an exception would be thrown because of problems creating the part.
There were two major issues with this:
- Side-effects of failures during composition could not always be cleaned up
- Light-up could only be supported via optional dependencies, which led to awkward component designs
The solution to this problem is:
Parts that have missing required dependencies are ‘rejected.’ They appear in the catalog, but the container never uses them.
MEF remains dynamic – as parts are added and removed from the composition, the state of part definitions can change. Parts that may have been rejected will become available when their dependencies can be satisfied.
Atomic Changes
The container now treats lazy references as promises. Once the container hands out a Lazy<T> export, the value is guaranteed to be available, and to remain available for the life of the part that imports it.
The parts available in a MEF container can change, either by adding or removing to the a ComposablePartCatalog, or directly via CompositionContainer.ComposeBatch().
In order to keep promises, changes like these are examined carefully and verified not to break anything already instantiated.
If such a change would cause an existing promise to be broken, the change is rejected by means of a CompositionException.
Diagnosing Composition Problems
One of the implications of Stable Composition is that the rejected parts will simply never show up.
Because parts are interdependent, one broken part can cause a chain of other dependent parts to be rejected as well.
Finding the root cause of a ‘cascading rejection’ like this can be tricky.
Included in the samples under /Samples/CompositionDiagnostics is a prototype diagnostic library that can be used to track composition problems down.
The two basic functions that are implemented allow the rejection state of a part to be inspected, and the contents of an entire catalog to be dumped along with status and root cause analysis information.
Dump Composition State
For comprehensive diagnostics, the complete composition can be dumped in text format:
The output contains many interesting things, including ‘primary rejection’ guesses and analysis of common problems like mismatched type identity, mismatched creation policy, and missing required metadata:
There’s enough information here to correctly diagnose most common issues.
Find Likely Root Causes
The dump technique above is comprehensive but verbose, and if you have access to the running process in a debugger, the following is more likely to be convenient:
The return value of CompositionInfo.GetPartDefinitionInfo() is an object that gives quick access to all of the same analytical information as the text dump, but relating to the part Foo. The API exposes:
- The part’s rejection state (IsRejected)
- Whether it is a primary cause of rejection, or if it is rejected because of other cascading rejections (IsPrimaryRejection)
- Which parts are likely to be the root causes of the part’s rejection (PossibleRootCauses)
- The state of all imports (ImportDefinitions)
- For each import, which exports would satisfy the imports (ImportDefinitions..Actuals)
- For each import, which other exports with the same contract name were not matched, and the reason for each (ImportDefinitions..UnsuitableExportDefinitions)
Implementing Export Providers
The ExportProvider.GetExportsCore() method has gained a parameter to support Stable Composition. ExportProvider also has a new event ExportsChanging for the same purpose.
Simple ExportProviders that hand out the same values and do not recursively call into the container can ignore the parameter and event.
If you implement a custom ExportProvider that recursively calls into the container to satisfy dependencies of the exports it hands out, then you should participate in Stable Composition.
Likewise, if the set of available exports in an ExportProvider can change, you’ll need to fire the ExportsChanging and ExportsChanged events.
See the API documentation for these types for more details.
Other API Changes
A number of other supporting API changes have been made, and a few obsolete or problematic items removed:
- CompositionContainer.GetExportedObject() and related overloads have been renamed to GetExportedValue()
- CompositionEngine has been renamed ImportEngine
- AttributedModelServices
- AddExportedObject<T>() renamed to AddExportedValue<T>()
- ComposeExportedObject<T>() renamed to ComposeExportedValue<T>()
- New GetMetadataView<TMetadataView>() method
- New SatisfyIImportsOnce() method
- ICompositionService changes
- SatisfyImports() renamed SatisfyImportsOnce() and no longer registers the part for recomposition
- UnregisterForRecomposition() removed
- CompositionServiceExtensions removed
- ContractTypeAttribute removed since exports on interfaces are now inherited
- ComposablePartCatalogChangedEventArgs renamed to ComposablePartCatalogChangeEventArgs
- New AtomicComposition class supports Stable Composition
- Contract adapters have been removed
Help and Feedback
Enjoy the new release, and remember that the MEF discussion forum on CodePlex is a great place to get help if you find yourself stuck.
The MEF Team is very grateful to everyone who’s provided feedback and input into the new release. I hope we’ve hit the right note, but as always your comments are welcome.
This week I took some time out to talk to Richard and Carl on .NET Rocks! about Autofac, MEF and component-oriented software in general.
If you have any questions about material from the show, please feel free to post them in the comments.
I was reminded today of Stateless, a little project that I’m quite fond of.
Stateless is a hierarchical state machine framework based on Simple State Machine for Boo, but configured using C# 3.0.
When I announced Stateless last year, I hardly even explained its purpose, let alone its tongue-in-cheek name. I think I owe it a better start in life!
If you’re doing heavy duty state-machine based programming (writing parsers, radiotherapy machines or flight control systems) then Stateless is probably not what you’re looking for.
If you’re doing domain-driven design, and anxious about the ugly nested ‘if’ and ‘switch’ statements building up around _state variables, Stateless can help.
State-based behaviour is awkward because despite careful programming, it is difficult to see how the states relate to each other. Adding and removing states is error-prone, repetition creeps in, and refactoring gets tricky.
There’s more than one way out. The State pattern can be one very elegant solution.
Another solution that works nicely is to create a declarative model of the states, transitions and associated actions, and have a state machine framework ‘run’ it for you. This is the approach enabled by Stateless.
The Telephone Call state chart is broken down into the following states and triggers:
You can use any types to represent states and triggers, but enumerations are convenient.
After creating an instance of StateMachine, each state is configured independently. Configuration for a state revolves around the triggers that the state can accept, the transitions that these triggers will cause (to new states) and the actions that will be performed when entering or leaving a state.
Once the state machine has been configured, the triggers can be ‘fired’. The side-effects from firing triggers drive the program.
You might wonder how this fits into a domain model. StateMachine certainly doesn’t belong on the public surface area of your domain model classes. It’s an implementation detail – like, for example, StringBuilder or Regex.
Users of the class interact with the state machine indirectly, by calling public methods on the domain object.
The state machine is configured to call two methods when entering and leaving the Connected state (see the configuration above.)
Stateless does all of the heavy lifting. For example, the state machine understands that because OnHold is a sub-state of Connected, the Connected entry/exit actions aren’t called when moving between these two states.
Now for a justification of the silly name…
Notice the way that the _state field belongs to the PhoneCall object, rather than the state machine? This allows the field to be easily mapped to a database column by NHibernate or your ORM of choice. The state machine reads and writes the _state value using the pair of lambdas provided to its constructor. In that sense you can almost say that the state machine itself is ‘stateless’. Almost.
There’s some more basic documentation and a source download at the site. I hope you’ll try Stateless and be pleasantly surprised by how expressive it can make your code. Search your domain model for “State” or “Status” and see what Stateless can do!
This post also comes with a challenge: Stateless is fairly simple and very hackable - if you’re a fluent-interface aficionado and think you can improve the configuration API, join the project!
Start to schematically represent any component system and you’re likely to come up with a diagram like:
So what do the dependency and the service actually mean?
In most implementations, each is associated with a key:
Here the Screen Renderer component needs the Typesetter service, which the Fast Typesetter component can provide.
Dependency resolution is a done by matching keys – resolving the Screen Renderer’s dependency boils down to doing a dictionary lookup with Typesetter as the key, to find the Fast Typesetter implementation.
This is the case whether the dependencies are expressed as strings, types, or some combination of the two.
While this model is very powerful and can be taken a long way, ‘open’ systems can benefit from an alternative approach.
Imagine a system in which multiple renderers and typesetters exist, each with distinct capabilities:
The dependencies above are no longer evaluated using simple equality comparisons.
On the right, the capabilities of each component are represented as structured data: the service provided, plus a collection of key-value pairs bearing more detailed information. Together these are a service definition.
On the left, the dependencies of each component are represented as predicates over the possible service definitions. The predicate evaluates to true if the service definition can satisfy the dependencies.
So, the Print Renderer’s requirements, { Quality == High }, are true when evaluated against the Accurate Typesetter’s service definition, and false when executed against the Fast Typesetter’s.
In effect, components express their dependencies as queries over the entire set of available services.
To get an idea of where the power of this technique comes from, consider the way the example will compose: the Screen Renderer gets a fast Typesetter and the Print Renderer gets an accurate one. In a system with a better Typesetter – one that is both fast and accurate – a single Typesetter implementation could fulfill both dependencies.
Constraints aren’t just limited to equality comparisons either – if speed is expressed in characters per second, the Screen Renderer could specify { Speed > 500 }.
If you haven’t guessed already, this is the model that the MEF Primitives use. The service definitions are exposed with the type ExportDefinition. The predicate for testing ExportDefinitions for suitability is encoded in ImportDefinition.Constraint.
One of the constraints in the example might be expressed as:
The system is elegant, but there are a few things to be aware of. The first that comes to mind is how the constraint is Boolean, so ‘falling back’ to a slow Typesetter when no fast one is available means expressing two separate constraints
Because ImportDefinition.Constraint is a Linq expression, and thanks to some special-case logic, MEF is able to resolve many dependencies without doing the linear scan that the query implies. This is only the case when constraints take the typical forms expressible in MEF’s Attributed Programming Model. Arbitrary constraints can result in a linear scan (although the way is clear to optimizing these in the future.)
One other interesting note – it is technically possible to transform an import constraint into a format that could be evaluated by a database-backed Linq provider… If for some reason you’d like to do that :)
You might be wondering why code snippets like the predicate above don’t appear in the MEF examples you typically see. The answer is that this is the key to understanding programming models. A programming model, in the MEF sense, translates some easy-to-type format like the Import and Export attributes, into constraints under-the-hood.
Constraint-based dependency resolution is one of the foundations that future versions of MEF will build upon.
There has been a lot of discussion among IoC container users about the similarities between MEF and IoC containers. Most of this has been addressing the question - “should MEF and an IoC container be used in the same app, or are they exclusive?”
One possible answer to this question is outlined below. It isn’t by any means the definitive answer, but if these are technologies you find interesting, hopefully this article will give you plenty of food for thought.
An IoC container is not required in order to use MEF. Unless you’re building or using an IoC container, this article probably won’t apply to you :).
Defining Extensibility Points
The Managed Extensibility Framework (MEF) in .NET 4.0 introduces a standard model for defining and consuming application extensibility points.
Central to this model is the ComposablePartCatalog type and its subclasses:
AssemblyCatalog and DirectoryCatalog can read set of attributes for defining extensions:
Here Export marks the Square class as an extension providing the IShape contract.
.NET 4.0 also introduces a class for assembling extensions into complete object graphs. This class is called CompositionContainer:
The role that CompositionContainer plays in a .NET 4.0 application is very similar to the role and IoC container might play in a .NET application today.
This has raised a lot of interest among IoC container users, who want to know how they can take advantage of MEF in their applications. Should CompositionContainer, for instance, replace their current IoC container, or can the two containers work together?
The answer to this question is trickier than it seems, because there are substantial problems associated with having more than one container in an IoC-driven application:
- How do the containers mutually decide that an instance’s lifetime is over?
- How is context maintained, so that the correct type gets its correct dependencies even when they’re provided by the other container?
- If the graph building operation moves backwards and forwards between two containers, how can circular dependencies be detected (without StackOverflowException!)
- How can diagnostic messages provide the ‘full picture’ when each container only knows about a portion of the graph being constructed?
(Some of this is a general problem with composing frameworks in general, and is felt today by IoC container users integrating with UI frameworks in particular. It might be called ‘competing for control’.)
The good news is that there is at least one way to get some benefits of MEF in an application that uses an IoC container without using two containers.
MEF/IoC Container Roles
Although similar in many respects, the goals of MEF and IoC containers are different, and this gives each technology unique strengths.
MEF is built for open systems – scenarios in which the complete set of components that make up an application is defined at execution-time.
This means that MEF:
- supports self-describing components that carry all of the information required to use them
- makes strong guarantees about how components will be loaded and manipulated, regardless of the execution environment
- includes robust tools for finding and loading components in different media
- allows components to be queried and inspected without necessarily loading or executing them
MEF is also part of the .NET Framework, so developers can learn how to use it once and then apply these skills in all MEF-enabled applications.
IoC containers, on the other hand, have focused on highly-decoupled yet primarily closed systems. I take the definition of ‘closed’ to mean that all application components are present during integration and testing.
This makes typical IoC containers:
- highly customizable to suit the internal architecture of a specific application
- extremely flexible in the criteria for what can be used as a component
- easy to wrap around existing frameworks and legacy code
These requirements lead in different directions when designing composition technologies, but appear together in some applications.
Both MEF and typical IoC containers are flexible enough to fit to most scenarios; however, their ideal roles might be:
- define third-party extension points using MEF
- locate and load these extensions using MEF
- structure and manage the host application’s fixed architecture using an IoC container
Hosting MEF Catalogs
There are several approaches to integrating MEF and IoC containers. The one described here is probably the most powerful/complete/complex, those interested in other perspectives might start with this recent article by Patrik Hägne.
Most IoC containers, and MEF, use a layered architecture:
MEF’s composition functionality is wrapped up in CompositionContainer, and its component model in ComposablePartDefinition and related types like ComposablePartCatalog.
Autofac, an open-source IoC container [disclaimer: written by the author] follows the same typical pattern, using different types: Container and IComponentRegistration. (Funq, Linfu, Ninject, Windsor, Spring.NET, StructureMap and Unity use similar abstractions.)
Autofac and MEF used in the same application, without any integration, look like:
The crossed-out arrow in the centre reflects the barrier that we’re trying to cross: the Autofac composition process won’t include components that are composed by MEF, and vice-versa.
This kind of cross-over is frequently desirable, e.g.:
- Application components invoke extensions
- Extensions need to access services provided by the host application
The diagram below shows how this issue can be addressed without introducing the ‘two container’ problem:
Rather than hosting the MEF components in a separate container, an adapter is used so that the MEF components are presented to the Autofac container as Autofac components.
The adapter allows MEF and Autofac components to participate in the composition process at the same time – each can have dependencies satisfied by the other.
The IoC container is chosen as the ‘host’ because:
- The application components are the ones most likely to integrate deeply into the container, and since they’re IoC container components it makes sense that they are hosted in the IoC container
- IoC containers don’t provide as robust a component mode as MEF does, so hosting components from any particular container in MEF is difficult
So how does this look in practice?
Example Application: IoC and MEF
You can download a very contrived example that demonstrates many of the moving parts here. This is not production quality design, so please don’t flame me for it :)
The example is a task scheduler – perhaps you can imagine it running as a Windows service. It has two extension points: the tasks that will be run, and an output device to which notification messages can be sent.
The extension points are regular MEF parts.
The tasks export an interface and specify the interval at which they should be invoked via metadata attributes:
Notification services are similar, exporting the IMessageNotifier interface:
The container is created and Autofac services registered as usual:
An extension method, RegisterCatalog(), allows a MEF DirectoryCatalog to be supplied to the container:
Note the list of services that will be imported from the catalog into the application. Parts can still export and import other contracts, but these won’t be available to Autofac components. This keeps the extensibility points of the application clearly defined.
Similarly, Autofac services have to be explicitly marked when they will be provided to MEF components:
There’s an example of an Autofac component consuming a mix of Autofac and MEF services:
As well as MEF components consuming Autofac services:
Everything feels natural, although there are a few awkward issues surrounding the consumption of MEF metadata in Autofac services. These should go away once the MEF Export type is a framework type (it won’t feel so leaky to inject exports into Autofac components.)
Limitations
MEF defines how individual components will be manipulated, not how they will be assembled into complete object graphs.
This makes sense for open systems, because regardless of how components are packaged, they should not make assumptions about their host environment beyond the contracts that their immediate dependencies supply.
When designing components that can be used in multiple applications, each component needs to be treated independently. MEF discourages thinking about catalogs of components as subsystems with a fixed configuration.
The biggest side-effect of these decisions is that while MEF components behave consistently whether hosted in MEF or another container, groups of components will probably behave differently.
MEF’s container also offers a different set of features from the typical IoC container – these may be sorely missed in highly-extensible applications, so if high extensibility is the goal the MEF container alone is likely a better choice.
Status
It will be some time before there is much empirical data on the benefits and pitfalls of this technique – YMMV, so be sure to carefully evaluate your needs before starting down this path. Experimental is probably the appropriate tag!
.NET 4.0 and MEF are not yet released, so these techniques may not even apply to the production version.
There is a whitepaper on the MEF site describing some of the technical requirements of the approach.
Some notes on the Autofac adapter are available on the Autofac wiki.
We had a great little open discussion on building IoC-driven apps today at ALT.NET Seattle.
A handful of good points came up:
- Building aggregate object graphs for the UI layer is giving people headaches
- Dynamic instantiation patterns like 'injected context' and 'generated context adapter' are starting to gain more recognition as basic buildling blocks
- Service locators can be a useful step in the process of refactoring-to-IoC (seems like there is some work to be done in developing a body of knowledge in this area)
- The time is right for some better tooling, e.g. dependency graph exploration
Thanks everyone who showed up and got involved. (Extra thanks to Glenn Block for setting up the session - kudos!)
A number of IoC containers have Silverlight versions - Ninject and Unity especially seem to have healthy Silverlight offerings. Silverlight 2.0 is a variant of the .NET runtime, so this isn't too surprising.
Thanks to Tyson Stolarski and Rinat Abdullin, Autofac recently joined their ranks with a Silverlight-compatible build. (This one is hot off the press, so test it thoroughly before you set out to build anything mission-critical :))
MEF hasn't released any concrete plans for Silverlight, but experimenters can probably coerce the Codeplex source into a compatible build by hacking the .csproj file.
If you're reading this blog and use IoC on Silverlight in one form or another:
- What have your experiences been like?
- Do you use IoC in the UI, the 'back-end' or both?
- Does loose coupling/runtime composition get in the way of XAML-based designers?
I'd love to hear your thoughts!
The first post in this series introduced the problem of accessing IoC container features dynamically.
We brushed over two common patterns:
- Global Container (or Static Service Locator)
- Injected Context
Before we move on from this topic, I'd like to look at one more pattern in this theme that may not be in common use, but deserves some attention anyway.
This pattern I've labeled Declarative Context Adapter, and it builds on the strengths of Injected Context while moving from imperative implementation to declarative configuration.
Problem
After composition, a component requires dynamic access to features of the container that hosts it (the context.)
Commonly, this involves dynamically creating or locating instances from the container (e.g. see ControllerProvider in this article.)
Solution
- Provide a domain-specific interface to the required functionality.
- Describe how this interface should interact with the container using metadata or configuration.
- A compliant implementation is supplied based on the metadata.
Example
One example of a Declarative Context Adapter is the generated factories feature of Autofac.
This feature uses .NET delegate types as the 'domain-specific interfaces'. The Shareholding.Factory delegate type below plays this role:
In this example, we want invocations of the Factory delegate to return instances of the Shareholding class created and wired up by the container. This example is a bit contrived, since usually there is some abstraction involved, but hey, it is just an example :)
The ContainerBuilder's method-chaining API allows the mapping between the delegate to the container's Resolve() method to be specified:
This is specified via the RegisterGeneratedFactory() method.
The only declarative configuration in this example apart from the delegate type itself, is the TypedService parameter that tells Autofac which service from the container should be returned whenever the delegate is invoked.
(Additional configuration options can describe parameter mappings for the delegate parameters, however these aren't available in the current release builds.)
Other components that need to instantiate Shareholdings can now have instances of Shareholding.Factory injected into them.
Discussion
To call this technique a 'pattern' is a bit premature, since the Autofac feature is the only implementation you can put your hands on.
The same functionality could be implemented on different containers, perhaps via AOP. It would also be preferable to support interfaces as well as delegate types.
While the examples have been related to instantiation or service lookup, context adapters could be defined for other container features like lifetime management or even component registration. Anywhere that Injected Context is used, it should be possible to generate a configuration-driven alternative.
Source Code
The tiny example from above can be downloaded here if you'd like to experiment with it.
As a follow up from my last post about Global Container vs. Injected Context, I would like to share this snippet from Component Software, which casts the difference between the two approaches in another light:
"A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. ..."
Under this definition, the ControllerProvider based upon an Injected Context is a component, because it publishes its (admittedly broad) context dependency explicitly, via its constructor parameter.
BadControllerProvider, based upon a Global Container, is not a component under this definition because its dependency on the global container is not explicit (you need to have source code in order to find it.)
In my opinion, the distinction is significant because "components" and "wiring" are a higher-level abstraction than "classes" and "references".
In composite applications, an architecture will be more robust and easier to understand if these layers of abstraction are respected, and not tangled up in classes like BadControllerProvider.
(Component Software is a very worthwhile read and contains a lot of relevant material for those interested in IoC containers and other composition technologies. Clemens Szyperski is a mentor and highly influential voice for the MEF team.)
