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!

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

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!

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:

1. Retain the existing simple syntax for non-parameterised triggers;
2. Execute parameter-driven logic during the transition, i.e. after the exit events for the last state have fired;
3. Make it clear to the user exactly when parameter-driven logic will execute;
4. Control interference between parameter-driven logic and guard conditions;
5. 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!

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.

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.

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:

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

If you have any questions about material from the show, please feel free to post them in the comments.

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!