Nicholas Blumhardt

Back at Microsoft, new blog location...

Nicholas Blumhardt — Wed, 05 Oct 2011 17:37:51 GMT

I've moved back to Redmond and again work on the .NET framework.

I don't currently plan on reviving this blog. You can find me online at my personal blog or keep up with our team via the BCL team blog.

Thanks for dropping by!

Homeward Bound

niblumha — Wed, 30 Sep 2009 00:01:00 GMT

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

Debug Composition from within Visual Studio

niblumha — Thu, 24 Sep 2009 22:12:24 GMT

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!

Parameterised Triggers and Re-Entrant States in Stateless v2

niblumha — Sun, 30 Aug 2009 04:34:51 GMT

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!

Analyze MEF Assemblies from the Command Line

niblumha — Fri, 28 Aug 2009 20:45:26 GMT

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.

Dynamic Part Instantiation in MEF

niblumha — Fri, 28 Aug 2009 03:57:25 GMT

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.

Implementing Optional Exports with MEF Stable Composition

niblumha — Fri, 17 Jul 2009 20:59:29 GMT

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?)

MEF Preview 6 Available

niblumha — Thu, 09 Jul 2009 19:29:00 GMT

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.

Appearance on .NET Rocks!

niblumha — Fri, 29 May 2009 20:55:00 GMT

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.

State Machines in Domain Models

niblumha — Thu, 16 Apr 2009 09:52:37 GMT

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!

MEF: Dependencies are Queries?

niblumha — Thu, 16 Apr 2009 02:01:25 GMT

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.

Hosting MEF Extensions in an IoC Container

niblumha — Tue, 17 Mar 2009 01:14:32 GMT

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.

IoC Open Space at ALT.NET Seattle

niblumha — Sun, 01 Mar 2009 03:08:00 GMT

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!)

IoC on Silverlight

niblumha — Sun, 04 Jan 2009 20:48:33 GMT

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!

Declarative Context Adapters

niblumha — Sun, 04 Jan 2009 19:59:42 GMT

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.

Explicit Context Dependencies

niblumha — Mon, 29 Dec 2008 21:34:12 GMT

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.)

Container-Managed Application Design, Prelude: Where does the Container Belong?

niblumha — Sat, 27 Dec 2008 03:32:00 GMT

There is surprisingly little information out there in cyberspace on how IoC containers should fit into application architectures.

In parallel with my MEF/Ruby series, I'm going to discuss some of the principles that I believe should be applied to "container-managed" application design.

The Enigmatic Ideal

In the world of systems built using dependency injection, you hear plenty of mysterious statements like:

“Except for when bootstrapping, don’t access the container directly!”

This kind of thing caused me to scratch my head for the best part of a year before I finally caught on to what was meant.

Basic Mental Models

When confronted with the task of designing an application around an IoC container, the place that the container sits in that architecture usually seems to be influenced by the designer's mental model of what, exactly, an IoC container is.

Model 1: a Dictionary of Services

The dictionary or associative array is one of the first constructs we learn about in software engineering. It is easy to see the analogy between a dictionary and an IoC container that composes objects using dependency injection:

Maps to:

All that appears to differ is:

Some fancy new terms ‘register’ and ‘resolve’ are used, instead of indexer access
The logger is created via reflection, saving some typing and configuration code in the case of inter-dependencies

If you come onto a project with established usage of a dependency injection container and had to figure out how to write the code you need to interact with the rest of the system, chances are this is the first mental model you’ll apply.

Model 2: an Abstract new() Operator

Dependency injection containers are often praised for eliminating implementation type dependencies. Going back to our example, we’ve made our request for an ILogger independent of the implementation type that provides it (ConsoleLogger in this case.)

Web frameworks like Monorail and ASP.NET MVC use our dependency injection container to create Controller instances in a similar way.

Perhaps it makes more sense to think of the container as an abstract new() operator?

Becomes:

Here our container usage has not only abstracted away the concrete type of our MailTransport but also taken care of configuring its Host property. (Configuration must be a feature of our abstract new() operator since the configuration parameters on an instance depend on its concrete type rather than the service it provides.)

Design Outcome: the Global Container

Following either of these mental models encourages you to think about the container as something you retrieve things from. Even the name 'container' pushes us in this direction.

From this perspective, there isn't much of a challenge in the application architecture design assignment!

We'll just create a static property Container on a class, say, Global and get instances from it using Global.Container.Resolve<MyService>().

Easy!

This snippet should be familiar as a pattern with another name: the static Service Locator.

Problems with the Global Container as a Service Locator

There are good reasons why this pattern can rightly be called an anti-pattern:

Fragility. The container acts like a bucket of global variables. All of the robustness that is achieved by forcing components to publicly declare dependencies is lost. Unexpected dependencies can appear between seemingly unrelated parts of an application, complicating maintenance.

Reduced Composability. When dependencies are injected, the container can be configured to provide different implementations to different consumers. This is often necessary when combining components that were built independently. When dependencies are retrieved from a global container, the container does not know the identity of the requestor, and is forced to return the same implementation every time.

Limited Reuse. Where the global container resides can limit the reusability of components that depend on it. Migrating components to a WPF application will require code changes if they depend on the global container attached to the HttpApplication class.

Implementation Issues. Concurrency, re-entrancy, circular reference detection, and component lifetime management are much harder/messier in a global container based solution.

Resumption of Control: Generally speaking, these issues arise because calling directly into a global container is a resumption of control. In a container-managed application, the container is given the responsibility of getting the right instances into the right places in order for work to be done. Calling into a global container takes over some of this responsibility in a much less manageable way.

Sometimes, because of the design decisions made in many current-generation frameworks, the Global Container is a necessity, but in order to advance the state of software engineering we need to look beyond this.

Thinking Inside the Box

The mental models listed earlier should have rung some alarm bells:

The container is a dictionary of services? Hang on! If I ask for the same service twice, why do I sometimes get different instances?

Good question. It is easy to configure a dependency injection container to return a new instance of the ConsoleLogger each time one is resolved. Not very dictionary-like, is it?

So the container is really an abstract new operator? Wait! If I sometimes get the same shared instance back, when can I Dispose() it?

These two models aren't even compatible. Sometimes the container hands out new instances, but sometimes what comes back from a call to resolve is a singleton, or an instance that will be shared within some kind of context like the current transaction.

So things are now confusing: who owns these instances, and where do they ‘live’?

Revised Mental Model: An Interconnected System of Objects

Here’s the problem: look at the example on the Autofac homepage. It shows how Register() and Resolve() are used in Autofac. This is a pretty common kind of introductory example to dependency injection. Notice what’s missing?

The most important classes in this example are not ContainerBuilder or Container. From an application architecture perspective, we need to see the Straight6TwinTurbo and Car classes!

The resolve operation is just a way of finding an entry point into a self-contained system.

The entire application resides within the container. There is no ‘outside’ except for whatever entry point gets the ball rolling. An understanding of IoC from this perspective does not revolve around its external APIs like Register() and Resolve().

Using this model, the container to gets component instances to the right place at the right time, and application design re-focuses on the implementation of the components themselves.

Design Outcome: Injected Context

This new perspective on the world leaves us with a challenge when implementing our revised IControllerProvider. This service needs to return (potentially) new, parameterised instances of the Controller type.

The solution, commonly implemented in applications today, is to allow the container to provide context to our controller provider:

We assume here that ControllerProvider is itself hosted within the container. IContext is an interface that Autofac automatically provides to any components that require it. You can create and use an equivalent interface in any other popular IoC container (there's a MEF example linked from below.)

IContext provides the instance resolution features of the container to the application, but in a controlled manner. The object implementing IContext provides the container's services, but may not be the container itself.

Because this pattern gives the container or application developer an opportunity to customise or proxy the IContext implementation handed out to any particular component, most of the problems associated with a Global Container are mitigated.

Container-Managed Application Design

If you feel like this article and its explanations are somewhat incomplete, you're right. As the title of this post suggests, it is an introduction to a series on the topic. I don't have all the answers, and I don't even have all the questions, so the installments may come in fits and starts. Nevertheless, if you're out to design robust architectures that make use of an component-based composition technology there should be something of interest for you.

I hope this article has whet your appetite!

Sample Code

The sample code, based on MEF preview 3, is very, very rough, and is really only worth consulting if you need to step through some running code in order to clarify the concepts in this article.

Ruby on MEF: Hybrid Application

niblumha — Tue, 23 Dec 2008 03:20:00 GMT

Since the last installment in this little series, I've started to consider how Ruby/C# hybrid MEF applications might look.

The result is yet another component-based calculator:

Besides the Radiohead arithmetic, there is one reason to get excited...

Ruby parts! (I bet you hadn't guessed.)

The Ruby-based export and import features are heading towards a fairly natural syntax. IOperation, for example, is a regular .NET interface type:

Let's take a look at how the Ruby implementation is woven into the app.

Configuration

This is still a work-in-progress, so configuration is basic. All of the Ruby parts are loaded from a single file that is fed into the RubyCatalog:

The calculator_ops.rb file contains part definitions like Multiply from above.

An additional catalog adds all of the C# parts to the composition as well:

Main Window

The main window is a typical WPF Window that Imports a list of operations:

Because the MainWindow is instantiated and composed by MEF, all known exporters of IOperation will be provided, regardless of the language they're implemented in.

Bi-Directional Composition

You'll notice that the MainWindow class implements the IErrorLog contract. This allows messages from the parts to be presented to the user:

Parts that wish to access the IErrorLog service from Ruby can import it:

The integration (and IronRuby in general) treats interface contracts as Ruby Module objects, so the IErrorLog used by the Divide part could be implemented by a Ruby object, although I haven't tested that case.

Fanatics take note: I did attempt to use IronRuby's case-transforming features to allow Symbol and Apply() to be specified in their natural Ruby forms (symbol and apply()) but had no success. Hopefully I'll resolve this in a future version.

Monkeypatching the Export Type

I can't say whether this will turn out to be a good move or not, but right now it seems reasonable.

Notice this method call:

In order to support MEF's lazy-instantiation feature, the @error_log attribute needs to be of type System::ComponentModel::Composition::Export, which will supply the actual instance when it is required through the get_exported_object() method. Calling @error_log.get_exported_object.add_message felt decidedly unnatural, so I've added method forwarding to the Ruby version of the Export class:

I've had to do some type aliasing to disambiguate Export from Export<T>, but otherwise this is straightforward. Rubyists, please weigh in and let me know if this implementation is less-than-desirable :)

Source Code

Once again you can download the full source code for this article from SkyDrive.

Ruby on MEF: Imports and Exports

niblumha — Sun, 14 Dec 2008 04:18:33 GMT

Well, the "Ruby Parts" implementation is slowly taking shape. If you haven't read the first article you probably should before you read on.

Exports

An export is an object that a part will hand to the outside world to fulfil a contract. Sometimes, this is the part itself. Other times, the part will expose a property or a method as an export.

MEF requires us to publish the information about what exports are available (our ComposablePartDefinition) before any object that provides the export has been created.

We can achieve this in Ruby because class definitions are executed. The export* methods can run arbitrary code and have access to the class definition that they're running within.

Without any syntactic sugar, a part definition that exports the 'answer' contract looks like:

Other parts that import the 'answer' contract will get the integer value 42.

Our technique is:

Keep a global table of 'part definitions' that can be updated as a Ruby script executes
When a static export* method executes, create a function that can retrieve the export from a part instance (the 'export accessor')
Store the export accessor along with the part's class in the table of part definitions

Each part definition ends up mapping a Ruby class to a table of contract name/function pairs.

When an export is requested from our part, the value returned is the result of executing the function that we stored for that export in the part definition.

The function can return either the object itself, an attribute, or a Proc object representing a method, which seems like a good generic foundation to build our different kinds of exports on top of.

Because self or a Proc can be returned from a property, we'll implement property exports first.

In the example, to get things started the export accessor function is explicitly specified in a block argument to the export_attr method.

The export_attr Method

This method is defined as a class method on PartDefinition.

So, while the MyPart class is being defined in the Ruby runtime, export_attr will create an export accessor that runs the provided block in the context of the part instance.

RubyCatalog

The meat of the add_export method creates or finds a RubyPartDefinition instance and adds an export definition to it.

The mysterious MefPartsCollection variable that appears in the above code is a named instance provided by the MEF RubyCatalog to the IronRuby runtime.

public class RubyCatalog : ComposablePartCatalog
{
    readonly ScriptRuntime _runtime;
    readonly ScriptEngine _ruby;
    readonly IQueryable<ComposablePartDefinition> _parts;

    public RubyCatalog(string script)
    {
        if (script == null)
            throw new ArgumentNullException("script");

        var rubySetup = new LanguageSetup(typeof(RubyContext).AssemblyQualifiedName);
        rubySetup.FileExtensions.Add("rb");
        rubySetup.Names.Add("IronRuby");

        var setup = new ScriptRuntimeSetup();
        setup.LanguageSetups.Add(rubySetup);

        _runtime = new ScriptRuntime(setup);
        _runtime.LoadAssembly(typeof(RubyPartDefinition).Assembly);
        _runtime.LoadAssembly(typeof(ExportDefinition).Assembly);
        _runtime.LoadAssembly(typeof(IEnumerable<int>).Assembly);

        _ruby = _runtime.GetEngine("IronRuby");

        var parts = new Hashtable();
        _runtime.Globals.SetVariable("MefPartsCollection", parts);
        _ruby.Execute(Script.PartDefinition);
        _ruby.Execute(script);

        _parts = parts.Values.Cast<ComposablePartDefinition>().AsQueryable();
    }

    public override IQueryable<ComposablePartDefinition> Parts
    {
        get { return _parts; }
    }
}

You can see how the "MefPartsCollection" variable is being set to a Hashtable before the script executes, and afterwards the values are retrieved as a list of ComposablePartDefinition instances.

The DLR setup in the catalog is a bit tentative. We'll refactor and extend it to be a little more user-friendly in the future.

(This catalog design assumes a single catalog per IronRuby runtime. This probably isn't going to be the best outcome for pure-Ruby applications, but for C# applications hosting Ruby parts this will work for now.)

Ruby Programming Model

The items in the MefPartsCollection are instances of the RubyPartDefinition class, indexed by Ruby part class.

RubyPartDefinition collaborates with RubyPart, RubyExportDefinition and RubyImportDefinition to create what MEF terms a 'programming model'.

I've implemented the programming model classes in C#, but they should be able to be implemented equally well in Ruby. Porting them might be an interesting exercise for the reader :)

Imports

Imports are defined using a similar technique. You can see how they work in the example code.

The Unit Tests

The solution you'll find attached to this article doesn't include an application - just a meagre selection of unit tests for the catalog.

The most interesting is this one:

[TestMethod]
public void ImportsValues()
{
    var script = @"
        class MyPart < PartDefinition
            import 'input_value' do |input|
                @input_value = input
            end

            export_attr 'output_value' do
                @input_value.get_exported_object
            end
        end
    ";

    ComposablePart part = CreateMyPart(script).CreatePart();
    Assert.AreEqual(1, part.ImportDefinitions.Count());

    var inputImport = part.ImportDefinitions.Single(
        i => ((ContractBasedImportDefinition)i).ContractName == "input_value");
    Assert.AreEqual(1, part.ExportDefinitions.Count());

    var outputExport = part.ExportDefinitions.Single();
    var testValue = "Hello, world";
    part.SetImport(inputImport, new[] { new Export(
        new ExportDefinition("input_value", null),
        () => testValue)});
    var output = part.GetExportedObject(outputExport);
    Assert.AreEqual(testValue, output);
}

Here you can see a complete roundtrip from import to export. Not groundbreaking, but I think this puts us on the right track.

Coming up...

We'll implement the basics of metadata, tidy up the syntax (I'm considering Dave's post a challenge ;)), and start to look at a hybrid application. Stay tuned!

Files

MefDlr-2008-12-13.zip

Hosting Ruby Parts in MEF

niblumha — Tue, 09 Dec 2008 22:29:35 GMT

MEF is fascinating because of the way some initial assumptions led to a different flavor of composition technology from the ones we've seen for .NET to date.

In my opinion, the most exciting ‘parameter variation’ in the design process for MEF was the idea that ‘parts’ should support the full range of .NET languages. The recent popularity of IronPython and IronRuby, and the inclusion of the DLR in .NET 4.0, meant that dynamic language support got first-class consideration.

As readers of my other blog may know, I’m a fan of Ruby in particular. For that reason I’m going to spend some time exploring how Ruby can fit into a MEF application.

Disclaimer:

I'm by no means a Ruby expert. Let me know if you seem me off course!

The Role of Parts

MEF’s unit of composition is the ComposablePart, or just ‘part’. Each part is self-contained and opaque to the outside world. The MEF CompositionContainer wires parts together according to the primitive Exports that each part exposes and consumes.

The independence of the part implementation behind these abstractions makes it possible to build a part just about any way you please.

The goal of the MEF/Ruby integration is to allow parts to be written in Ruby.

C# and the Attributed Part

In the default programming model, parts are defined in C# as classes, with attributes to describe their exports and imports:

This example is from the MEF Programming Guide, which describes these and some other interesting export and import capabilities (like method exports, which we'll look at later in this series.)

We call this the attributed programming model because MEF is agnostic about how parts are defined. A good example of an alternative programming model for an earlier version of MEF is Jason Olson's fluent version.

Translating Part Definitions into Ruby

I'm going to assume that if you are interested enough to read this far, you probably have at least a basic familiarity with the Ruby language, or the motivation to learn it.

Just as there are multiple ways of defining MEF parts in C#, there are endless ways that MEF parts could be defined in Ruby. There are two obvious ways that I can see Ruby interacting with other .NET languages via MEF:

Ruby snippets fulfil a specific role in a C# application (e.g. as command macros); or,
Composite applications are built using a mixture of Ruby and C#

Ruby Parts as 'Macros' (1)

The first approach would point towards supporting a minimal subset of MEF in order to supply Ruby snippets, probably as functions, to C# components:

For this imaginary example, a MEF integration would expose all similar functions from a script as Action<Document> delegates that could be imported by other parts. Export metadata could be used in order to describe the command as "delete selection" and this would be sufficient for including the command into user-defined toolbar buttons.

A simple technique like this is appealing for the first kind of Ruby/MEF integration, and I'm sure it is going to be implemented widely (I've already seen something similar done in Python.)

Full-Fledged Ruby Parts (2)

The second approach - building composite applications - requires that Ruby parts support most of the key MEF programming model features. It makes more sense in this case to use Ruby classes as the primary definition of a Part, and to require that the Ruby programmer has some knowledge of MEF itself.

This is the approach that I'm going to take in this series of posts.

Defining Ruby Parts

One of the wonderful things about Ruby is its flexibility. It is entirely possible to take a syntax-first approach and to work back from there towards an implementation.

My 'ideal' translation of the C# sample above would look something like:

It should be possible to interchange the Ruby Configuration part for the C# one in this example without changing any further code in the application. This is a really exciting possibility enabled by the DLR and MEF, and we'll try to push our implementation as far as possible in that direction.

Identifying Parts

I'm going to attempt to avoid a 'Part' base class, and instead regard any class that contains export statements as representing a part.

One thing this seems to imply is that the helper methods will be on Kernel. This might not be a good thing (it's like adding extension methods to System.Object in C#) so the base class might appear in the future.

Exports

There are three kinds of exports we need to account for: exporting the entire 'part object', exporting a property value, and exporting a method. All three of these are going to appear in the body of our Ruby class definition.

We'll need to use separate methods for each export type, so that we can differentiate between them. This is especially relevant in the case of properties/methods, which are the same under the hood in Ruby, but which need to be exported differently. A method export will be a delegate type, while a property export will be a value that is the result of invoking the property. Using export_attr and export_method would help to disambiguate this case clearly.

Imports

Imports are a bit simpler. I think that a single mechanism for importing values will suffice, and some hash parameters will allow the value to be imported into an attribute, an attribute writer (property) or perhaps via an optional block.

Where to Next?

There's no source code with this article today. I have a few unit tests working but things are a bit haphazard and not packaged up to distribute. I'm still experimenting with syntax so expect some significant changes of direction :)

I'll try to keep installments in this series short - perhaps a single unit test each. We'll work from there towards an example application that pulls everything together.