@@ -134,7 +133,7 @@

Favor Build Policies over Fancy Runtime Decision Making

- Previous: Diagnostics + Previous: StructureMap.AutoFactory diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index d736e6c..f127753 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -31,7 +31,7 @@

@@ -88,48 +88,37 @@

Build Plans - - -

StructureMap 3.0 introduced the concept of the "Build Plan." The build plan is a textual representation of exactly how StructureMap will build a given Instance, including:

What constructor function, if any, StructureMap is going to use for a concrete type
How it is resolving the constructor dependencies in a recursive fashion
Which setter properties for a concrete type receive dependencies and how those setter dependencies are built
The lifecycle used for the Instance
All interceptors applied to the Instance
Explicitly configured inline dependencies
Description of any Lambda or Func<T> that is used to construct the Instance object

To retrieve the build plan for a configured Instance, use the queryable Container.Model to find the configured Instance and call DescribeBuildPlan(int maxDepth) to get the textual report as shown in this sample below:


-            var container = Container.For<VisualizationRegistry>();
-
-            var description = container.Model.For<IDevice>().Default
-                .DescribeBuildPlan();
-
-            Debug.WriteLine(description);
-

The result of the code above is this textual representation of how StructureMap will build and/or resolve the default of the IDevice plugin type:

-PluginType: StructureMap.Testing.Diagnostics.IDevice
-Lifecycle: Transient
-Decorator --> FuncInterceptor of StructureMap.Testing.Diagnostics.IDevice: new DeviceDecorator(IDevice)
-Decorator --> Decorator of type StructureMap.Testing.Diagnostics.CrazyDecorator
-    new CrazyDecorator(IDevice, IEngine, IFoo)
-      ┣ IDevice = The inner IDevice
-      ┃ ┗ new DefaultDevice()
-      ┣ IEngine = **Default**
-      ┗ IFoo = **Default**
-

For another example, you can retrieve the build plan for a named instance of a certain build plan with this code:


-            var description = theContainer.Model.For<IDevice>()
-                .Find("A")
-                .DescribeBuildPlan();
-

See Using the Container Model for more information on using Container.Model.

You can find many more examples of finding the build plan description from Container.Model from the unit tests in the StructureMap codebase.

- + + +

StructureMap 3.0 introduced the concept of the "Build Plan." The build plan is a textual representation of exactly how StructureMap will build a given Instance, including:

What constructor function, if any, StructureMap is going to use for a concrete type
How it is resolving the constructor dependencies in a recursive fashion
Which setter properties for a concrete type receive dependencies and how those setter dependencies are built
The lifecycle used for the Instance
All interceptors applied to the Instance
Explicitly configured inline dependencies
Description of any Lambda or Func<T> that is used to construct the Instance object


var container = Container.For<VisualizationRegistry>();

var description = container.Model.For<IDevice>().Default
    .DescribeBuildPlan();

Debug.WriteLine(description);

The result of the code above is this textual representation of how StructureMap will build and/or resolve the default of the IDevice plugin type:

+PluginType: StructureMap.Testing.Diagnostics.IDevice
+Lifecycle: Transient
+Decorator --> FuncInterceptor of StructureMap.Testing.Diagnostics.IDevice: new DeviceDecorator(IDevice)
+Decorator --> Decorator of type StructureMap.Testing.Diagnostics.CrazyDecorator
+    new CrazyDecorator(IDevice, IEngine, IFoo)
+      ┣ IDevice = The inner IDevice
+      ┃ ┗ new DefaultDevice()
+      ┣ IEngine = **Default**
+      ┗ IFoo = **Default**
+      
+

For another example, you can retrieve the build plan for a named instance of a certain build plan with this code:


var description = theContainer.Model.For<IDevice>()
    .Find("A")
    .DescribeBuildPlan();

See Using the Container Model for more information on using Container.Model.

You can find many more examples of finding the build plan description from Container.Model from the unit tests in the StructureMap codebase.

@@ -88,32 +88,18 @@

Environment Tests - - -

Years ago I worked with a legacy system that was particularly fragile in its deployment. While my team at the time and I made some serious improvements in the reliability of the automated deployment, the best thing we did was to add a set of environment tests to the deployment that verified that basic elements of the system were working like:

Could our code access the configured database?
Was a certain COM object registered on the server? (I hated COM then and the years haven't changed my mind)
Could we connect via remoting to another deployed application?

The deployments still frequently failed, but we were able to spot and diagnose the underlying problems much faster with our new environment tests than we could before by trying to run and debug the not-quite-valid application.

One of the mechanisms we used for these environment tests was StructureMap's ability to mark methods on configured types as environment tests with the [ValidationMethod] attribute as shown below:


-        public class Database : IDatabase
-        {
-            [ValidationMethod]
-            public void TryToConnect()
-            {
-                // try to open a connection to the configured
-                // database connection string
-
-                // throw an exception if the database cannot
-                // be reached
-            }
-        }
-

Used in conjunction with StructureMap's ability to validate a container, you can use this technique to quickly support environment tests embedded into your system code.

- + + +

Could our code access the configured database?
Was a certain COM object registered on the server? (I hated COM then and the years haven't changed my mind)
Could we connect via remoting to another deployed application?

One of the mechanisms we used for these environment tests was StructureMap's ability to mark methods on configured types as environment tests with the [ValidationMethod] attribute as shown below:


public class Database : IDatabase
{
    [ValidationMethod]
    public void TryToConnect()
    {
        // try to open a connection to the configured
        // database connection string

        // throw an exception if the database cannot
        // be reached
    }
}

Used in conjunction with StructureMap's ability to validate a container, you can use this technique to quickly support environment tests embedded into your system code.

@@ -88,11 +88,10 @@

Diagnostics - -
Improving StructureMap's ability to diagnose and explain both configuration and runtime problems was a very big goal -for the big 3.0 release and improved with additional type scanning diagnostics for 4.0.
-
WhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
- + +
Improving StructureMap's ability to diagnose and explain both configuration and runtime problems was a very big goal +for the big 3.0 release and improved with additional type scanning diagnostics for 4.0.
+
WhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics

@@ -74,8 +74,8 @@

@@ -91,75 +91,17 @@

Type Scanning Diagnostics This functionality was introduced in StructureMap 4.0.

Type scanning and conventional auto-registration is a very powerful feature in StructureMap, but it has been frequently troublesome to users when things go wrong. To try to alleviate problems, StructureMap 4.0 introduces some new functionality for detecting and diagnosing problems with type scanning, mostly related to Assembly's being missing.

Assert for Assembly Loading Failures

At its root, most type scanning and auto-registration schemes in .Net frameworks rely on the Assembly.GetExportedTypes() method. Unfortunately, that method can be brittle and fail whenever any dependency of that Assembly cannot be loaded into the current process, even if your application has no need for that dependency. In StructureMap 3.* and before, that loading exception was essentially swallowed and lost. In StructureMap 4 and above, you can use this method to assert the presence of any assembly load exceptions during type scanning:


-            TypeRepository.AssertNoTypeScanningFailures();
-


TypeRepository.AssertNoTypeScanningFailures();

The method above will throw an exception listing all the Assembly's that failed during the call to GetExportedTypes() only if there were any failures. Use this method during your application bootstrapping if you want it to fail fast with any type scanning problems.

What did StructureMap scan?

Confusion of type scanning has been a constant problem with StructureMap usage over the years -- especially if users are trying to dynamically load assemblies from the file system for extensibility. In order to see into what StructureMap has done with type scanning, 4.0 introduces the Container.WhatDidIScan() method.

Let's say that you have a Container that is set up with at least two different scanning operations like this sample from the StructureMap unit tests:


-            var container = new Container(_ =>
-            {
-                _.Scan(x =>
-                {
-                    x.TheCallingAssembly();
-
-                    x.WithDefaultConventions();
-                    x.RegisterConcreteTypesAgainstTheFirstInterface();
-                    x.SingleImplementationsOfInterface();
-                });
-
-                _.Scan(x =>
-                {
-                    // Give your scanning operation a descriptive name
-                    // to help the diagnostics to be more useful
-                    x.Description = "Second Scanner";
-
-                    x.AssembliesFromApplicationBaseDirectory(assem => assem.FullName.Contains("Widget"));
-                    x.ConnectImplementationsToTypesClosing(typeof(IService<>));
-                    x.AddAllTypesOf<IWidget>();
-                });
-            });
-
-            Debug.WriteLine(container.WhatDidIScan());
-


var container = new Container(_ =>
{
    _.Scan(x =>
    {
        x.TheCallingAssembly();

        x.WithDefaultConventions();
        x.RegisterConcreteTypesAgainstTheFirstInterface();
        x.SingleImplementationsOfInterface();
    });

    _.Scan(x =>
    {
        // Give your scanning operation a descriptive name
        // to help the diagnostics to be more useful
        x.Description = "Second Scanner";

        x.AssembliesFromApplicationBaseDirectory(assem => assem.FullName.Contains("Widget"));
        x.ConnectImplementationsToTypesClosing(typeof(IService<>));
        x.AddAllTypesOf<IWidget>();
    });
});

Debug.WriteLine(container.WhatDidIScan());

The resulting textual report is shown below:

Sorry for the formatting and color of the text, but the markdown engine does not like the textual report


-    /*
-    All Scanners
-    ================================================================
-    Scanner #1
-    Assemblies
-    ----------
-    * StructureMap.Testing, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-
-    Conventions
-    --------
-    * Default I[Name]/[Name] registration convention
-    * Register all concrete types against the first interface (if any) that they implement
-    * Register any single implementation of any interface against that interface
-
-    Second Scanner
-    Assemblies
-    ----------
-    * StructureMap.Testing.GenericWidgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
-    * StructureMap.Testing.Widget, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-    * StructureMap.Testing.Widget2, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-    * StructureMap.Testing.Widget3, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-    * StructureMap.Testing.Widget4, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-    * StructureMap.Testing.Widget5, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-
-    Conventions
-    --------
-    * Connect all implementations of open generic type IService<T>
-    * Find and register all types implementing StructureMap.Testing.Widget.IWidget
-
-    */
-


/*
All Scanners
================================================================
Scanner #1
Assemblies
----------
* StructureMap.Testing, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null

Conventions
--------
* Default I[Name]/[Name] registration convention
* Register all concrete types against the first interface (if any) that they implement
* Register any single implementation of any interface against that interface

Second Scanner
Assemblies
----------
* StructureMap.Testing.GenericWidgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
* StructureMap.Testing.Widget, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
* StructureMap.Testing.Widget2, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
* StructureMap.Testing.Widget3, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
* StructureMap.Testing.Widget4, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
* StructureMap.Testing.Widget5, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null

Conventions
--------
* Connect all implementations of open generic type IService<T>
* Find and register all types implementing StructureMap.Testing.Widget.IWidget

*/

The textual report will show:

All the scanning operations (calls to Registry.Scan()) with a descriptive name, either one supplied by you or the Registry type and an order number.

What did StructureMap scan?

WhatDidIScan() does not at this time show any type filters or exclusions that may be part of the assembly scanner.

@@ -181,7 +122,7 @@

What did StructureMap scan?

- Next: Best Practices + Next: Aspect Oriented Programming with StructureMap.DynamicInterception

diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index 0f4876e..0a731e3 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -31,7 +31,7 @@

@@ -88,125 +88,45 @@

Using the Container Model - - -

The queryable Container.Model is a power facility to look into your StructureMap Container and even to eject previously built services from the Container. The Container.Model represents a static view of what a Container already has, and does not account for policies that may allow StructureMap to validly discover types that it may encounter later at runtime.

Querying for Plugin Types

The WhatDoIHave() mechanism works by just iterating over the Container.Model.PluginTypes collection as shown below:


-            container.Model.PluginTypes.Where(x => x.PluginType.Assembly == Assembly.GetExecutingAssembly())
-                .Each(pluginType => Debug.WriteLine(pluginType.PluginType));
-

Working with a Plugin Type

The IPluginTypeConfiguration interface allows you to query and manipulate all the configured Instance's for a given plugin type.

See the entire IPluginTypeConfiguration interface here.

Finding the Default for a Plugin Type

To simply find out what the default concrete type would be for a requested plugin type, use one of these two methods:


-            // Finding the concrete type of the default
-            // IDevice service
-            container.Model.DefaultTypeFor<IDevice>()
-                .ShouldBe(typeof(DefaultDevice));
-
-            // Find the configuration model for the default
-            // IDevice service
-            container.Model.For<IDevice>().Default
-                .ReturnedType.ShouldBe(typeof(DefaultDevice));
-

Finding an Instance by Type and Name

Use this syntax to find information about an Instance in a given plugin type and name:


-            var redRule = container.Model.Find<Rule>("Red");
-

All Instances for a Plugin Type

This sample shows how you could iterate or query over all the registered instances for a single plugin type:


-            container.Model.For<Rule>().Instances.Each(i =>
-            {
-                Debug.WriteLine(i.Instance.Description);
-            });
-

Ejecting Services and/or Configuration

It's possible to remove singleton scoped objects from a running Container to force a new one to be built or even to completely remove configured instance objects and configuration permanently from a Container. This is typically only used in automated testing to flush static state between tests.

To remove and dispose previously built singleton scoped objects from a Container, use this code:


-            // ONLY ejects any built object for this Instance from the SingletonThing
-            // cache
-            container.Model.For<IDevice>().Default.EjectObject();
-

To completely eject any singletons and permanently remove all related configuration, use this code:


-            // Removes all configurations and objects already built as singletons
-            // related to types in the current Assembly
-            container.Model.EjectAndRemoveTypes(type => type.Assembly == Assembly.GetExecutingAssembly());
-
-            // Removes all configurations and objects already built as singletons
-            // that were registered to IDevice
-            container.Model.EjectAndRemove(typeof(IDevice));
-

Testing for Registrations

To troubleshoot or automate testing of Container configuration, you can use code like the sample below to -test for the presence of expected configurations:


-            // Is there a default instance for IDevice?
-            container.Model.HasDefaultImplementationFor<IDevice>().ShouldBeTrue();
-
-            // Are there any configured instances for IDevice?
-            container.Model.HasImplementationsFor<IDevice>().ShouldBeTrue();
-

Finding all Possible Implementors of an Interface

Forget about what types are registered for whatever plugin types and consider this, what if you have an interface called -IStartable that just denotes objects that will need to be activated after the container is bootstrapped?

If our interface is this below:


-    public interface IStartable
-    {
-        bool WasStarted { get; }
-
-        void Start();
-    }
-
-

We could walk through the entire StructureMap model and find every registered instance that implements this interface, create each, and call the Start() method like in this code below:


-            var allStartables = container.Model.GetAllPossible<IStartable>();
-            allStartables.ToArray()
-                .Each(x => x.Start());
-

I've also used this mechanism in automated testing to reach out to all singleton services that may have state to clear out their data between tests.

Working with Individual Instances

You can manipulate an individual instance in several ways:


-            // First, find the model for a single Instance
-            var instance = container.Model.For<IDevice>().Default;
-
-            // build or resolve an object for this Instance cast to
-            // the type specified to the Get() method
-            instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>();
-
-            // if the instance is configured as a SingletonThing, test
-            // if the SingletonThing object has already been created
-            var hasSingletonBeenCreated = instance.ObjectHasBeenCreated();
-
-            if (hasSingletonBeenCreated)
-            {
-                // remove the SingletonThing object from the cache so that
-                // StructureMap will be forced to rebuild this object
-                instance.EjectObject();
-            }
-
-            // test the lifecycle of this instance
-            instance.Lifecycle.ShouldBeOfType<SingletonLifecycle>();
-
-            // Visualize the build plan no more than 3 levels deep
-            Debug.WriteLine(instance.DescribeBuildPlan(3));
-
-            // Get at the underlying Instance model that StructureMap itself
-            // uses. Be cautious using this.
-            var rawModel = instance.Instance;
-
-

- + + +

Querying for Plugin Types

The WhatDoIHave() mechanism works by just iterating over the Container.Model.PluginTypes collection as shown below:


container.Model.PluginTypes.Where(x => x.PluginType.Assembly == Assembly.GetExecutingAssembly())
    .Each(pluginType => Debug.WriteLine(pluginType.PluginType));

Working with a Plugin Type

The IPluginTypeConfiguration interface allows you to query and manipulate all the configured Instance's for a given plugin type.

See the entire IPluginTypeConfiguration interface here.

Finding the Default for a Plugin Type

To simply find out what the default concrete type would be for a requested plugin type, use one of these two methods:


// Finding the concrete type of the default
// IDevice service
container.Model.DefaultTypeFor<IDevice>()
    .ShouldBe(typeof(DefaultDevice));

// Find the configuration model for the default
// IDevice service
container.Model.For<IDevice>().Default
    .ReturnedType.ShouldBe(typeof(DefaultDevice));

Finding an Instance by Type and Name

Use this syntax to find information about an Instance in a given plugin type and name:


var redRule = container.Model.Find<Rule>("Red");

All Instances for a Plugin Type

This sample shows how you could iterate or query over all the registered instances for a single plugin type:


container.Model.For<Rule>().Instances.Each(i =>
{
    Debug.WriteLine(i.Instance.Description);
});

Ejecting Services and/or Configuration

To remove and dispose previously built singleton scoped objects from a Container, use this code:


// ONLY ejects any built object for this Instance from the SingletonThing
// cache
container.Model.For<IDevice>().Default.EjectObject();

To completely eject any singletons and permanently remove all related configuration, use this code:


// Removes all configurations and objects already built as singletons
// related to types in the current Assembly
container.Model.EjectAndRemoveTypes(type => type.Assembly == Assembly.GetExecutingAssembly());

// Removes all configurations and objects already built as singletons
// that were registered to IDevice
container.Model.EjectAndRemove(typeof(IDevice));

Testing for Registrations

To troubleshoot or automate testing of Container configuration, you can use code like the sample below to +test for the presence of expected configurations:


// Is there a default instance for IDevice?
container.Model.HasDefaultImplementationFor<IDevice>().ShouldBeTrue();

// Are there any configured instances for IDevice?
container.Model.HasImplementationsFor<IDevice>().ShouldBeTrue();

Finding all Possible Implementors of an Interface

Forget about what types are registered for whatever plugin types and consider this, what if you have an interface called +IStartable that just denotes objects that will need to be activated after the container is bootstrapped?

If our interface is this below:


public interface IStartable
{
    bool WasStarted { get; }

    void Start();
}

We could walk through the entire StructureMap model and find every registered instance that implements this interface, create each, and call the Start() method like in this code below:


var allStartables = container.Model.GetAllPossible<IStartable>();
allStartables.ToArray()
    .Each(x => x.Start());

I've also used this mechanism in automated testing to reach out to all singleton services that may have state to clear out their data between tests.

Working with Individual Instances

You can manipulate an individual instance in several ways:


// First, find the model for a single Instance
var instance = container.Model.For<IDevice>().Default;

// build or resolve an object for this Instance cast to
// the type specified to the Get() method
instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>();

// if the instance is configured as a SingletonThing, test
// if the SingletonThing object has already been created
var hasSingletonBeenCreated = instance.ObjectHasBeenCreated();

if (hasSingletonBeenCreated)
{
    // remove the SingletonThing object from the cache so that
    // StructureMap will be forced to rebuild this object
    instance.EjectObject();
}

// test the lifecycle of this instance
instance.Lifecycle.ShouldBeOfType<SingletonLifecycle>();

// Visualize the build plan no more than 3 levels deep
Debug.WriteLine(instance.DescribeBuildPlan(3));

// Get at the underlying Instance model that StructureMap itself
// uses. Be cautious using this.
var rawModel = instance.Instance;

@@ -88,37 +88,35 @@

Validating Container Configuration - - -

To find any potential holes in your StructureMap configuration like missing dependencies, unclear defaults of plugin types, validation errors, or just plain build errors, you can use this method below:


-            container.AssertConfigurationIsValid();
-

Running this method will walk over every single registration in your Container and:

Try to create a build plan for that Instance that will flush out any problems with missing dependencies or invalid inline configuration

Try to build every single configured Instance

Call any methods on built objects decorated with the [ValidationMethod] attribute to perform environment tests. See Environment Tests for more information on this usage.

If StructureMap encounters any errors of any kind during this method, it will throw an exception summarizing all of the problems that it encountered. That output will look something like:

-StructureMap.StructureMapConfigurationException
-StructureMap Failures:  1 Build/Configuration Failures and 0 Validation Errors
-
-Profile 'DEFAULT'
-
------------------------------------------------------------------------------------------------------
-Build Error on Instance 'StructureMap.Testing.Diagnostics.NamedWidget'
-    for PluginType StructureMap.Testing.Diagnostics.IWidget
-
-Unable to create a build plan for concrete type StructureMap.Testing.Diagnostics.NamedWidget
-new NamedWidget(String name)
-  ┗ String name = Required primitive dependency is not explicitly defined
-
-

Standin Dependencies for Runtime Dependencies

If you take advantage of StructureMap's ability to supply arguments at runtime, you may need to add fake or stubbed stand in services to StructureMap just to satisfy dependencies while calling Container.AssertConfigurationIsValid(). For example, in FubuMVC we supply several services representing an HTTP request as explicit arguments. In order to use the container validation, we have to register stand in services in the main container.

- + + +


container.AssertConfigurationIsValid();

Running this method will walk over every single registration in your Container and:

Try to create a build plan for that Instance that will flush out any problems with missing dependencies or invalid inline configuration
Try to build every single configured Instance
Call any methods on built objects decorated with the [ValidationMethod] attribute to perform environment tests. See Environment Tests for more information on this usage.

If StructureMap encounters any errors of any kind during this method, it will throw an exception summarizing all of the problems that it encountered. That output will look something like:

+
+	StructureMap.StructureMapConfigurationException
+	StructureMap Failures:  1 Build/Configuration Failures and 0 Validation Errors
+	
+	Profile 'DEFAULT'
+	
+	-----------------------------------------------------------------------------------------------------
+	Build Error on Instance 'StructureMap.Testing.Diagnostics.NamedWidget'
+	    for PluginType StructureMap.Testing.Diagnostics.IWidget
+	
+	Unable to create a build plan for concrete type StructureMap.Testing.Diagnostics.NamedWidget
+	new NamedWidget(String name)
+	  ┗ String name = Required primitive dependency is not explicitly defined
+
+

Standin Dependencies for Runtime Dependencies

@@ -88,62 +88,21 @@

WhatDoIHave() - - -

The IContainer.WhatDoIHave() method can give you a quick textual report of the current configuration of a running Container:


-            var container = new Container();
-            var report = container.WhatDoIHave();
-
-            Debug.WriteLine(report);
-

If you're familiar with WhatDoIHave() from earlier versions of StructureMap, the usage has been enhanced for 3.0 to allow you -to filter the results for easier usage. The format was also tweaked extensively to (hopefully) improve the usability of this feature.

Enough talk, say you have a Container with this configuration:


-            var container = new Container(x =>
-            {
-                x.For<IEngine>().Use<Hemi>().Named("The Hemi");
-
-                x.For<IEngine>().Add<VEight>().Singleton().Named("V8");
-                x.For<IEngine>().Add<FourFiftyFour>().AlwaysUnique();
-                x.For<IEngine>().Add<StraightSix>().LifecycleIs<ThreadLocalStorageLifecycle>();
-
-                x.For<IEngine>().Add(() => new Rotary()).Named("Rotary");
-                x.For<IEngine>().Add(c => c.GetInstance<PluginElectric>());
-
-                x.For<IEngine>().Add(new InlineFour());
-
-                x.For<IEngine>().UseIfNone<VTwelve>();
-                x.For<IEngine>().MissingNamedInstanceIs.ConstructedBy(c => new NamedEngine(c.RequestedName));
-            });
-

If you were to run the code below against this Container:


-            Debug.WriteLine(container.WhatDoIHave());
-

you would get the output shown in this gist.

If you're curious, all the raw code for this example is in here.

Filtering WhatDoIHave()

Filtering the WhatDoIHave() results can be done in these ways:


-            var container = new Container();
-
-            // Filter by the Assembly of the Plugin Type
-            var byAssembly = container.WhatDoIHave(assembly: typeof(IWidget).GetAssembly());
-
-            // Only report on the specified Plugin Type
-            var byPluginType = container.WhatDoIHave(typeof(IWidget));
-
-            // Filter to Plugin Type's in the named namespace
-            // The 'IsInNamespace' test will include child namespaces
-            var byNamespace = container.WhatDoIHave(@namespace: "StructureMap.Testing.Widget");
-
-            // Filter by a case insensitive string.Contains() match
-            // against the Plugin Type name
-            var byType = container.WhatDoIHave(typeName: "Widget");
-

- + + +

The IContainer.WhatDoIHave() method can give you a quick textual report of the current configuration of a running Container:


var container = new Container();
var report = container.WhatDoIHave();

Debug.WriteLine(report);

If you're familiar with WhatDoIHave() from earlier versions of StructureMap, the usage has been enhanced for 3.0 to allow you +to filter the results for easier usage. The format was also tweaked extensively to (hopefully) improve the usability of this feature.

Enough talk, say you have a Container with this configuration:


var container = new Container(x =>
{
    x.For<IEngine>().Use<Hemi>().Named("The Hemi");

    x.For<IEngine>().Add<VEight>().Singleton().Named("V8");
    x.For<IEngine>().Add<FourFiftyFour>().AlwaysUnique();
    x.For<IEngine>().Add<StraightSix>().LifecycleIs<ThreadLocalStorageLifecycle>();

    x.For<IEngine>().Add(() => new Rotary()).Named("Rotary");
    x.For<IEngine>().Add(c => c.GetInstance<PluginElectric>());

    x.For<IEngine>().Add(new InlineFour());

    x.For<IEngine>().UseIfNone<VTwelve>();
    x.For<IEngine>().MissingNamedInstanceIs.ConstructedBy(c => new NamedEngine(c.RequestedName));
});

If you were to run the code below against this Container:


Debug.WriteLine(container.WhatDoIHave());

you would get the output shown in this gist.

If you're curious, all the raw code for this example is in here.

Filtering WhatDoIHave()

Filtering the WhatDoIHave() results can be done in these ways:


var container = new Container();

// Filter by the Assembly of the Plugin Type
var byAssembly = container.WhatDoIHave(assembly: typeof(IWidget).GetAssembly());

// Only report on the specified Plugin Type
var byPluginType = container.WhatDoIHave(typeof(IWidget));

// Filter to Plugin Type's in the named namespace
// The 'IsInNamespace' test will include child namespaces
var byNamespace = container.WhatDoIHave(@namespace: "StructureMap.Testing.Widget");

// Filter by a case insensitive string.Contains() match
// against the Plugin Type name
var byType = container.WhatDoIHave(typeName: "Widget");

- - - - - - - - - - - - - - - - - - diff --git a/features/index.html b/features/index.html index 4cb6dba..179a9c0 100644 --- a/features/index.html +++ b/features/index.html @@ -31,7 +31,7 @@

@@ -88,45 +88,44 @@

Features - - -
Note! The StructureMap team will accept pull requests if there's something missing from this list that you'd like to add. -
-
-
Programmatic Configuration
-
Conventional "Auto" Registration
-
Modular configuration
-
Constructor and Setter Injection
-
Configurable constructor selection
-
Customizable setter injection policies
-
Auto wiring of dependencies
-
Inline dependency configuration
-
Service Location
-
Strategies for registering and utilizing open generic types
-
Lifecycle management and custom lifecycles
-
ASP.Net centric lifecycles with StructureMap.Web
-
Interception and Configurable Decorators
-
Lazy, Func, and Func<string, T> dependencies
-
Auto resolution of enumerable types
-
Auto resolution of concrete types
-
"Profile's" for multi-tenancy or optional modes
-
Diagnostics
-
Auto resolution conventions
-
"Auto Mocking*
-
Simple Auto Factory support
-
Nested and Child Containers
-
-

Things StructureMap does not have

The following things are features that are not uncommon in other IoC tools or were present in previous versions of StructureMap.

Xml configuration was removed for the 3.0 release.
Comprehensive attribute based configuration was also removed for the 3.0 release, but there is some very rudimentary support for attibute based -configuration
Complex Auto Factory support (this feature may be part of the StructureMap 4.0 release)

Note! The StructureMap team strongly feels that Xml configuration is both undesirable and unnecessary. Please feel free to use the Google user group to ask for advice on how to move away from Xml configuration in existing applications. -

- + + +

Note! The StructureMap team will accept pull requests if there's something missing from this list that you'd like to add. +

Programmatic Configuration
Conventional "Auto" Registration
Modular configuration
Constructor and Setter Injection
Configurable constructor selection
Customizable setter injection policies
Auto wiring of dependencies
Inline dependency configuration
Service Location
Strategies for registering and utilizing open generic types
Lifecycle management and custom lifecycles
ASP.Net centric lifecycles with StructureMap.Web
Interception and Configurable Decorators
Lazy, Func, and Func<string, T> dependencies
Auto resolution of enumerable types
Auto resolution of concrete types
"Profile's" for multi-tenancy or optional modes
Diagnostics
Auto resolution conventions
"Auto Mocking*
Simple Auto Factory support
Nested and Child Containers

Things StructureMap does not have

The following things are features that are not uncommon in other IoC tools or were present in previous versions of StructureMap.

Xml configuration was removed for the 3.0 release.
Comprehensive attribute based configuration was also removed for the 3.0 release, but there is some very rudimentary support for attibute based +configuration
Complex Auto Factory support (this feature may be part of the StructureMap 4.0 release)

@@ -91,100 +91,32 @@

Generic Types open generic types in .Net for extensibility and flexible handling within your system.
-

Example 1: Visualizing an Activity Log

I worked years ago on a system that could be used to record and resolve customer support problems. Since it was very workflow heavy in its logic, we tracked user and system activity as an event stream of small objects that reflected all the different actions or state changes that could happen to an issue. To render and visualize the activity log to HTML, we used many of the open generic type capabilities shown in this topic to find and apply the correct HTML rendering strategy for each type of log object in an activity stream.

Given a log object, we wanted to look up the right visualizer strategy to render that type of log object to html on the server side.

To start, we had an interface like this one that we were going to use to get the HTML for each log object:


-    public interface ILogVisualizer
-    {
-        // If we already know what the type of log we have
-        string ToHtml<TLog>(TLog log);
-
-        // If we only know that we have a log object
-        string ToHtml(object log);
-    }
-


public interface ILogVisualizer
{
    // If we already know what the type of log we have
    string ToHtml<TLog>(TLog log);

    // If we only know that we have a log object
    string ToHtml(object log);
}

So for an example, if we already knew that we had an IssueCreated object, we should be able to use StructureMap like this:


-            // Just setting up a Container and ILogVisualizer
-            var container = Container.For<VisualizationRegistry>();
-            var visualizer = container.GetInstance<ILogVisualizer>();
-
-            // If I have an IssueCreated lob object...
-            var created = new IssueCreated();
-
-            // I can get the html representation:
-            var html = visualizer.ToHtml(created);
-


// Just setting up a Container and ILogVisualizer
var container = Container.For<VisualizationRegistry>();
var visualizer = container.GetInstance<ILogVisualizer>();

// If I have an IssueCreated lob object...
var created = new IssueCreated();

// I can get the html representation:
var html = visualizer.ToHtml(created);

If we had an array of log objects, but we do not already know the specific types, we can still use the more generic ToHtml(object) method like this:


-            var logs = new object[]
-            {
-                new IssueCreated(),
-                new TaskAssigned(),
-                new Comment(),
-                new IssueResolved()
-            };
-
-            // SAMPLE: using-visualizer-knowning-the-type
-            // Just setting up a Container and ILogVisualizer
-            var container = Container.For<VisualizationRegistry>();
-            var visualizer = container.GetInstance<ILogVisualizer>();
-
-            var items = logs.Select(visualizer.ToHtml);
-            var html = string.Join("<hr />", items);
-


var logs = new object[]
{
    new IssueCreated(),
    new TaskAssigned(),
    new Comment(),
    new IssueResolved()
};

// SAMPLE: using-visualizer-knowning-the-type
// Just setting up a Container and ILogVisualizer
var container = Container.For<VisualizationRegistry>();
var visualizer = container.GetInstance<ILogVisualizer>();

var items = logs.Select(visualizer.ToHtml);
var html = string.Join("<hr />", items);

The next step is to create a way to identify the visualization strategy for a single type of log object. We certainly could have done this with a giant switch statement, but we wanted some extensibility for new types of activity log objects and even customer specific log types that would never, ever be in the main codebase. We settled on an interface like the one shown below that would be responsible for rendering a particular type of log object ("T" in the type):


-    public interface IVisualizer<TLog>
-    {
-        string ToHtml(TLog log);
-    }
-


public interface IVisualizer<TLog>
{
    string ToHtml(TLog log);
}

Inside of the concrete implementation of ILogVisualizer we need to be able to pull out and use the correct IVisualizer<T> strategy for a log type. We of course used a StructureMap Container to do the resolution and lookup, so now we also need to be able to register all the log visualization strategies in some easy way. On top of that, many of the log types were simple and could just as easily be rendered with a simple html strategy like this class:


-    public class DefaultVisualizer<TLog> : IVisualizer<TLog>
-    {
-        public string ToHtml(TLog log)
-        {
-            return string.Format("<div>{0}</div>", log);
-        }
-    }
-


public class DefaultVisualizer<TLog> : IVisualizer<TLog>
{
    public string ToHtml(TLog log)
    {
        return string.Format("<div>{0}</div>", log);
    }
}

Inside of our StructureMap usage, if we don't have a specific visualizer for a given log type, we'd just like to fallback to the default visualizer and proceed.

Alright, now that we have a real world problem, let's proceed to the mechanics of the solution.

Registering Open Generic Types

Let's say to begin with all we want to do is to always use the DefaultVisualizer for each log type. We can do that with code like this below:


-        [Fact]
-        public void register_open_generic_type()
-        {
-            var container = new Container(_ =>
-            {
-                _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));
-            });
-
-            Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));
-
-            container.GetInstance<IVisualizer<IssueCreated>>()
-                .ShouldBeOfType<DefaultVisualizer<IssueCreated>>();
-
-            Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));
-
-            container.GetInstance<IVisualizer<IssueResolved>>()
-                .ShouldBeOfType<DefaultVisualizer<IssueResolved>>();
-        }
-
-


[Fact]
public void register_open_generic_type()
{
    var container = new Container(_ =>
    {
        _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));
    });

    Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));

    container.GetInstance<IVisualizer<IssueCreated>>()
        .ShouldBeOfType<DefaultVisualizer<IssueCreated>>();

    Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));

    container.GetInstance<IVisualizer<IssueResolved>>()
        .ShouldBeOfType<DefaultVisualizer<IssueResolved>>();
}

With the configuration above, there are no specific registrations for IVisualizer<IssueCreated>. At the first request for that interface, StructureMap will run through its "missing family policies", one of which is to try to find registrations for an open generic type that could be closed to make a valid registration for the requested type. In the case above, @@ -207,86 +139,28 @@

Registering Open Generic Types

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ IVisualizer<TLog> StructureMap.Testing.Acceptance.Visualization Transient DefaultVisualizer<TLog> (Default) ==================================================================================================================================================================================== + + -

Generic Registrations and Default Fallbacks

A powerful feature of generic type support in StructureMap is the ability to register specific handlers for some types, but allow users to register a "fallback" registration otherwise. In the case of the visualization, some types of log objects may justify some special HTML rendering while others can happily be rendered with the default visualization strategy. This behavior is demonstrated by the following code sample:


-        [Fact]
-        public void generic_defaults()
-        {
-            var container = new Container(_ =>
-            {
-                // The default visualizer just like we did above
-                _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));
-
-                // Register a specific visualizer for IssueCreated
-                _.For<IVisualizer<IssueCreated>>().Use<IssueCreatedVisualizer>();
-            });
-
-            // We have a specific visualizer for IssueCreated
-            container.GetInstance<IVisualizer<IssueCreated>>()
-                .ShouldBeOfType<IssueCreatedVisualizer>();
-
-            // We do not have any special visualizer for TaskAssigned,
-            // so fall back to the DefaultVisualizer<T>
-            container.GetInstance<IVisualizer<TaskAssigned>>()
-                .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>();
-        }
-
-

Connecting Generic Implementations with Type Scanning


[Fact]
public void generic_defaults()
{
    var container = new Container(_ =>
    {
        // The default visualizer just like we did above
        _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));

        // Register a specific visualizer for IssueCreated
        _.For<IVisualizer<IssueCreated>>().Use<IssueCreatedVisualizer>();
    });

    // We have a specific visualizer for IssueCreated
    container.GetInstance<IVisualizer<IssueCreated>>()
        .ShouldBeOfType<IssueCreatedVisualizer>();

    // We do not have any special visualizer for TaskAssigned,
    // so fall back to the DefaultVisualizer<T>
    container.GetInstance<IVisualizer<TaskAssigned>>()
        .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>();
}

Connecting Generic Implementations with Type Scanning

It's generally harmful in software projects to have a single code file that has to be frequently edited to for unrelated changes, and StructureMap Registry classes that explicitly configure services can easily fall into that category. Using type scanning registration can help teams avoid that problem altogether by eliminating the need to make any explict registrations as new providers are added to the codebase.

For this example, I have two special visualizers for the IssueCreated and IssueResolved log types:


-    public class IssueCreatedVisualizer : IVisualizer<IssueCreated>
-    {
-        public string ToHtml(IssueCreated log)
-        {
-            return "special html for an issue being created";
-        }
-    }
-
-    public class IssueResolvedVisualizer : IVisualizer<IssueResolved>
-    {
-        public string ToHtml(IssueResolved log)
-        {
-            return "special html for issue resolved";
-        }
-    }
-


public class IssueCreatedVisualizer : IVisualizer<IssueCreated>
{
    public string ToHtml(IssueCreated log)
    {
        return "special html for an issue being created";
    }
}

public class IssueResolvedVisualizer : IVisualizer<IssueResolved>
{
    public string ToHtml(IssueResolved log)
    {
        return "special html for issue resolved";
    }
}

In the real project that inspired this example, we had many, many more types of log visualizer strategies and it could have easily been very tedious to manually register all the different little IVisualizer<T> strategy types in a Registry class by hand. Fortunately, part of StructureMap's type scanning support is the ConnectImplementationsToTypesClosing() auto-registration mechanism via generic templates for exactly this kind of scenario.

In the sample below, I've set up a type scanning operation that will register any concrete type in the Assembly that contains the VisualizationRegistry that closes IVisualizer<T> against the proper interface:


-    public class VisualizationRegistry : Registry
-    {
-        public VisualizationRegistry()
-        {
-            // The main ILogVisualizer service
-            For<ILogVisualizer>().Use<LogVisualizer>();
-
-            // A default, fallback visualizer
-            For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));
-
-            // Auto-register all concrete types that "close"
-            // IVisualizer<TLog>
-            Scan(x =>
-            {
-                x.TheCallingAssembly();
-                x.ConnectImplementationsToTypesClosing(typeof(IVisualizer<>));
-            });
-
-        }
-    }
-


public class VisualizationRegistry : Registry
{
    public VisualizationRegistry()
    {
        // The main ILogVisualizer service
        For<ILogVisualizer>().Use<LogVisualizer>();

        // A default, fallback visualizer
        For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));

        // Auto-register all concrete types that "close"
        // IVisualizer<TLog>
        Scan(x =>
        {
            x.TheCallingAssembly();
            x.ConnectImplementationsToTypesClosing(typeof(IVisualizer<>));
        });

    }
}

If we create a Container based on the configuration above, we can see that the type scanning operation picks up the specific visualizers for IssueCreated and IssueResolved as shown in the diagnostic view below:

@@ -305,228 +179,46 @@ Connecting Generic Implementations with Type Scanning
 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 IVisualizer<TLog>              StructureMap.Testing.Acceptance.Visualization     Transient     DefaultVisualizer<TLog>                                                   (Default)
 ==================================================================================================================================================================================
+

The following sample shows the VisualizationRegistry in action to combine the type scanning registration plus the default fallback behavior for log types that do not have any special visualization logic:


-        [Fact]
-        public void visualization_registry()
-        {
-            var container = Container.For<VisualizationRegistry>();
-
-            Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));
-
-            container.GetInstance<IVisualizer<IssueCreated>>()
-                .ShouldBeOfType<IssueCreatedVisualizer>();
-
-            container.GetInstance<IVisualizer<IssueResolved>>()
-                .ShouldBeOfType<IssueResolvedVisualizer>();
-
-            // We have no special registration for TaskAssigned,
-            // so fallback to the default visualizer
-            container.GetInstance<IVisualizer<TaskAssigned>>()
-                .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>();
-        }
-
-

Building Closed Types with ForGenericType() and ForObject()


[Fact]
public void visualization_registry()
{
    var container = Container.For<VisualizationRegistry>();

    Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));

    container.GetInstance<IVisualizer<IssueCreated>>()
        .ShouldBeOfType<IssueCreatedVisualizer>();

    container.GetInstance<IVisualizer<IssueResolved>>()
        .ShouldBeOfType<IssueResolvedVisualizer>();

    // We have no special registration for TaskAssigned,
    // so fallback to the default visualizer
    container.GetInstance<IVisualizer<TaskAssigned>>()
        .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>();
}

Building Closed Types with ForGenericType() and ForObject()

Working with generic types and the common IHandler<T> pattern can be a little bit tricky if all you have is an object that is declared as an object. Fortunately, StructureMap has a couple helper methods and mechanisms to help you bridge the gap between DoSomething(object something) and DoSomething<T>(T something).

If you remember the full ILogVisualizer interface from above:


-    public interface ILogVisualizer
-    {
-        // If we already know what the type of log we have
-        string ToHtml<TLog>(TLog log);
-
-        // If we only know that we have a log object
-        string ToHtml(object log);
-    }
-


public interface ILogVisualizer
{
    // If we already know what the type of log we have
    string ToHtml<TLog>(TLog log);

    // If we only know that we have a log object
    string ToHtml(object log);
}

The method ToHtml(object log) somehow needs to be able to find the right IVisualizer<T> and execute it to get the HTML representation for a log object. The StructureMap IContainer provides two different methods called ForObject() and ForGenericType() for exactly this case, as shown below in a possible implementation of ILogVisualizer:


-    public class LogVisualizer : ILogVisualizer
-    {
-        private readonly IContainer _container;
-
-        // Take in the IContainer directly so that
-        // yes, you can use it as a service locator
-        public LogVisualizer(IContainer container)
-        {
-            _container = container;
-        }
-
-        // It's easy if you already know what the log
-        // type is
-        public string ToHtml<TLog>(TLog log)
-        {
-            return _container.GetInstance<IVisualizer<TLog>>()
-                .ToHtml(log);
-        }
-
-        public string ToHtml(object log)
-        {
-            // The ForObject() method uses the 
-            // log.GetType() as the parameter to the open
-            // type Writer<T>, and then resolves that
-            // closed type from the container and
-            // casts it to IWriter for you
-            return _container.ForObject(log)
-                .GetClosedTypeOf(typeof (Writer<>))
-                .As<IWriter>()
-                .Write(log);
-        }
-
-        public string ToHtml2(object log)
-        {
-            // The ForGenericType() method is again creating
-            // a closed type of Writer<T> from the Container
-            // and casting it to IWriter
-            return _container.ForGenericType(typeof (Writer<>))
-                .WithParameters(log.GetType())
-                .GetInstanceAs<IWriter>()
-                .Write(log);
-        }
-
-        // The IWriter and Writer<T> class below are
-        // adapters to go from "object" to <T>() signatures
-        public interface IWriter
-        {
-            string Write(object log);
-        }
-
-        public class Writer<T> : IWriter
-        {
-            private readonly IVisualizer<T> _visualizer;
-
-            public Writer(IVisualizer<T> visualizer)
-            {
-                _visualizer = visualizer;
-            }
-
-            public string Write(object log)
-            {
-                return _visualizer.ToHtml((T) log);
-            }
-        }
-    }
-


public class LogVisualizer : ILogVisualizer
{
    private readonly IContainer _container;

    // Take in the IContainer directly so that
    // yes, you can use it as a service locator
    public LogVisualizer(IContainer container)
    {
        _container = container;
    }

    // It's easy if you already know what the log
    // type is
    public string ToHtml<TLog>(TLog log)
    {
        return _container.GetInstance<IVisualizer<TLog>>()
            .ToHtml(log);
    }

    public string ToHtml(object log)
    {
        // The ForObject() method uses the 
        // log.GetType() as the parameter to the open
        // type Writer<T>, and then resolves that
        // closed type from the container and
        // casts it to IWriter for you
        return _container.ForObject(log)
            .GetClosedTypeOf(typeof (Writer<>))
            .As<IWriter>()
            .Write(log);
    }

    public string ToHtml2(object log)
    {
        // The ForGenericType() method is again creating
        // a closed type of Writer<T> from the Container
        // and casting it to IWriter
        return _container.ForGenericType(typeof (Writer<>))
            .WithParameters(log.GetType())
            .GetInstanceAs<IWriter>()
            .Write(log);
    }

    // The IWriter and Writer<T> class below are
    // adapters to go from "object" to <T>() signatures
    public interface IWriter
    {
        string Write(object log);
    }

    public class Writer<T> : IWriter
    {
        private readonly IVisualizer<T> _visualizer;

        public Writer(IVisualizer<T> visualizer)
        {
            _visualizer = visualizer;
        }

        public string Write(object log)
        {
            return _visualizer.ToHtml((T) log);
        }
    }
}

The two methods are almost identical in result with some slight differences:

ForObject(object subject) can only work with open types that have only one generic type parameter, and it will pass the argument subject to the underlying Container as an explicit argument so that you can inject that subject object into the object graph being created.
ForGenericType(Type openType) is a little clumsier to use, but can handle any number of generic type parameters

Example #2: Generic Instance Builder

As I recall, the following example was inspired by a question about how to use StructureMap to build out MongoDB MongoCollection objects from some sort of static builder or factory -- but I can't find the discussion on the mailing list as I write this today. This has come up often enough to justify its inclusion in the documentation.

Say that you have some sort of persistence tooling that you primarily interact with through an interface like this one below, where TDocument and TQuery are classes in your persistent domain:


-    public interface IRepository<TDocument, TQuery>
-    {
-    }
-
-


public interface IRepository<TDocument, TQuery>
{
}

Great, StructureMap handles generic types just fine, so you can just register the various closed types and off you go. Except you can't because the way that your persistence tooling works requires you to create the IRepository<,> objects with a static builder class like this one below:


-    public static class RepositoryBuilder
-    {
-        public static IRepository<TDocument, TQuery> Build<TDocument, TQuery>()
-        {
-            return new Repository<TDocument, TQuery>();
-        }
-    }
-
-


public static class RepositoryBuilder
{
    public static IRepository<TDocument, TQuery> Build<TDocument, TQuery>()
    {
        return new Repository<TDocument, TQuery>();
    }
}

StructureMap has an admittedly non-obvious way to handle this situation by creating a new subclass of Instance that will "know" how to create the real Instance for a closed type of IRepository<,>.

First off, let's create a new Instance type that knows how to build a specific type of IRepository<,> by subclassing the LambdaInstance type and providing a Func to build our repository type with the static RepositoryBuilder class:


-    public class RepositoryInstance<TDocument, TQuery> : LambdaInstance<IRepository<TDocument, TQuery>>
-    {
-        public RepositoryInstance() : base(() => RepositoryBuilder.Build<TDocument, TQuery>())
-        {
-        }
-
-        // This is purely to make the diagnostic views prettier
-        public override string Description
-        {
-            get
-            {
-                return "RepositoryBuilder.Build<{0}, {1}>()"
-                    .ToFormat(typeof(TDocument).Name, typeof(TQuery).Name);
-            }
-        }
-    }
-
-


public class RepositoryInstance<TDocument, TQuery> : LambdaInstance<IRepository<TDocument, TQuery>>
{
    public RepositoryInstance() : base(() => RepositoryBuilder.Build<TDocument, TQuery>())
    {
    }

    // This is purely to make the diagnostic views prettier
    public override string Description
    {
        get
        {
            return "RepositoryBuilder.Build<{0}, {1}>()"
                .ToFormat(typeof(TDocument).Name, typeof(TQuery).Name);
        }
    }
}

As you've probably surmised, the custom RepositoryInstance above is itself an open generic type and cannot be used directly until it has been closed. You could use this class directly if you have a very few document types like this:


-            var container = new Container(_ =>
-            {
-                _.For<IRepository<string, int>>().UseInstance(new RepositoryInstance<string, int>());
-
-                // or skip the custom Instance with:
-
-                _.For<IRepository<string, int>>().Use(() => RepositoryBuilder.Build<string, int>());
-            });
-


var container = new Container(_ =>
{
    _.For<IRepository<string, int>>().UseInstance(new RepositoryInstance<string, int>());

    // or skip the custom Instance with:

    _.For<IRepository<string, int>>().Use(() => RepositoryBuilder.Build<string, int>());
});

To handle the problem in a more generic way, we can create a second custom subclass of Instance for the open type IRepository<,> that will help StructureMap understand how to build the specific closed types of IRepository<,> at runtime:


-    public class RepositoryInstanceFactory : Instance
-    {
-        // This is the key part here. This method is called by
-        // StructureMap to "find" an Instance for a closed
-        // type of IRepository<,>
-        public override Instance CloseType(Type[] types)
-        {
-            // StructureMap will cache the object built out of this,
-            // so the expensive Reflection hit only happens
-            // once
-            var instanceType = typeof(RepositoryInstance<,>).MakeGenericType(types);
-            return Activator.CreateInstance(instanceType).As<Instance>();
-        }
-
-        // Don't worry about this one, never gets called
-        public override IDependencySource ToDependencySource(Type pluginType)
-        {
-            throw new NotSupportedException();
-        }
-
-        public override string Description
-        {
-            get { return "Build Repository<T, T1>() with RepositoryBuilder"; }
-        }
-
-        public override Type ReturnedType
-        {
-            get { return typeof(Repository<,>); }
-        }
-    }
-
-


public class RepositoryInstanceFactory : Instance
{
    // This is the key part here. This method is called by
    // StructureMap to "find" an Instance for a closed
    // type of IRepository<,>
    public override Instance CloseType(Type[] types)
    {
        // StructureMap will cache the object built out of this,
        // so the expensive Reflection hit only happens
        // once
        var instanceType = typeof(RepositoryInstance<,>).MakeGenericType(types);
        return Activator.CreateInstance(instanceType).As<Instance>();
    }

    // Don't worry about this one, never gets called
    public override IDependencySource ToDependencySource(Type pluginType)
    {
        throw new NotSupportedException();
    }

    public override string Description
    {
        get { return "Build Repository<T, T1>() with RepositoryBuilder"; }
    }

    public override Type ReturnedType
    {
        get { return typeof(Repository<,>); }
    }
}

The key part of the class above is the CloseType(Type[] types) method. At that point, we can determine the right type of RepositoryInstance<,> to build the requested type of IRepository<,>, then use some reflection to create and return that custom Instance.

Here's a unit test that exercises and demonstrates this functionality from end to end:


-        [Fact]
-        public void show_the_workaround_for_generic_builders()
-        {
-            var container = new Container(_ =>
-            {
-                _.For(typeof(IRepository<,>)).Use(new RepositoryInstanceFactory());
-            });
-
-            container.GetInstance<IRepository<string, int>>()
-                .ShouldBeOfType<Repository<string, int>>();
-
-            Debug.WriteLine(container.WhatDoIHave(assembly: GetType().GetAssembly()));
-        }
-
-


[Fact]
public void show_the_workaround_for_generic_builders()
{
    var container = new Container(_ =>
    {
        _.For(typeof(IRepository<,>)).Use(new RepositoryInstanceFactory());
    });

    container.GetInstance<IRepository<string, int>>()
        .ShouldBeOfType<Repository<string, int>>();

    Debug.WriteLine(container.WhatDoIHave(assembly: GetType().GetAssembly()));
}

After requesting IRepository<string, int> for the first time, the container configuration from Container.WhatDoIHave() is:

 ===================================================================================================================================================
@@ -537,82 +229,22 @@ Example #2: Generic Instance Builder
 IRepository<TDocument, TQuery>     StructureMap.Testing.Acceptance     Transient     Build Repository<T, T1>() with RepositoryBuilder     (Default)
 ===================================================================================================================================================

Example 3: Interception Policy against Generic Types

Several years ago I described an approach for using an Event Aggregator in a WPF application that relied on StructureMap interception to register any object that StructureMap built with the active EventAggregator for the system if that object was recognized as a listener to the event aggregator. I thought that approach worked out quite well, so let's talk about how you could implement that same design with the improved interception model introduced by StructureMap 3.0 (the event aggregator and StructureMap interception worked out well, but I'm very happy now that I ditched the old WPF client and replaced it with a web application using React.js instead).

First off, let's say that we're going to have this interface for our event aggregator:


-    public interface IEventAggregator
-    {
-        // Sending messages
-        void SendMessage<T>(T message);
-
-        void SendMessage<T>() where T : new();
-
-        // Explicit registration
-        void AddListener(object listener);
-
-        void RemoveListener(object listener);
-    }
-
-


public interface IEventAggregator
{
    // Sending messages
    void SendMessage<T>(T message);

    void SendMessage<T>() where T : new();

    // Explicit registration
    void AddListener(object listener);

    void RemoveListener(object listener);
}

To register a listener for a particular type of event notification, you would implement an interface called IListener<T> shown below and directly add that object to the IEventAggregator:


-    public interface IListener<T>
-    {
-        void Handle(T message);
-    }
-
-


public interface IListener<T>
{
    void Handle(T message);
}

In the application I'm describing, all of the listener objects were presenters or screen controls that were created by StructureMap, so it was convenient to allow StructureMap to register newly created objects with the IEventAggregator in an activation interceptor.

What we want to do though is have an interception policy that only applies to any concrete type that implements some interface that closes IListener<T>:


-    public class EventListenerRegistration : IInterceptorPolicy
-    {
-        public string Description
-        {
-            get { return "Adds the constructed object to the EventAggregator"; }
-        }
-
-        public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance)
-        {
-            if (instance.ReturnedType.FindInterfacesThatClose(typeof(IListener<>)).Any())
-            {
-                Expression<Action<IContext, object>> register =
-                    (c, o) => c.GetInstance<IEventAggregator>().AddListener(o);
-                yield return new ActivatorInterceptor<object>(register);
-            }
-        }
-    }
-
-


public class EventListenerRegistration : IInterceptorPolicy
{
    public string Description
    {
        get { return "Adds the constructed object to the EventAggregator"; }
    }

    public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance)
    {
        if (instance.ReturnedType.FindInterfacesThatClose(typeof(IListener<>)).Any())
        {
            Expression<Action<IContext, object>> register =
                (c, o) => c.GetInstance<IEventAggregator>().AddListener(o);
            yield return new ActivatorInterceptor<object>(register);
        }
    }
}

To see our new interception policy in action, see this unit test from GitHub:


-        [Fact]
-        public void use_the_event_listener_registration()
-        {
-            var container = new Container(x =>
-            {
-                x.Policies.Interceptors(new EventListenerRegistration());
-                x.For<IEventAggregator>().Use<EventAggregator>().Singleton();
-            });
-
-            var events = container.GetInstance<IEventAggregator>();
-            var listener = container.GetInstance<BooMessageListener>();
-
-            var message = new BooMessage();
-
-            events.SendMessage(message);
-
-            listener.Messages.Single().ShouldBeTheSameAs(message);
-        }
-
-

- +


[Fact]
public void use_the_event_listener_registration()
{
    var container = new Container(x =>
    {
        x.Policies.Interceptors(new EventListenerRegistration());
        x.For<IEventAggregator>().Use<EventAggregator>().Singleton();
    });

    var events = container.GetInstance<IEventAggregator>();
    var listener = container.GetInstance<BooMessageListener>();

    var message = new BooMessage();

    events.SendMessage(message);

    listener.Messages.Single().ShouldBeTheSameAs(message);
}

@@ -88,25 +88,24 @@

Get StructureMap - - -
Current Release
-
The current version of StructureMap will always be available on Nuget. See the Release Notes for more information.
-

Supported Platforms

The original StructureMap.dll has been broken up into a couple pieces. The main assembly will be targeting PCL compliance thanks to the diligent efforts of Frank Quednau, and that means that anything to do with ASP.Net or falls outside of the PCL core has been devolved into separate assemblies and eventually into different Nuget packages. This means that StructureMap 3.* will theoretically support WP8 and other versions of .Net for the very first time.

At this point StructureMap 3.* has been used on .Net 4, 4.5, WP8, and WP8.1. Nobody in the core StructureMap team is currently working with Xamarin mobile runtimes, but we are interested in verifying StructureMap on new platforms if any volunteers are interested in helping us out.

Binaries

Binaries of StructureMap are available via NuGet:

PM> Install-Package StructureMap
-

or if you need a strong named version of StructureMap:

PM> Install-Package structuremap-signed
-

The StructureMap team believes strong naming to be a blight upon the .Net land and we really wish folks would quit using it, but we understand that some circumstances absolutely require it.

Source

StructureMap's source is hosted on GitHub. If you want to fix a bug or just want to tinker with an idea, we love receiving pull requests! Start by creating your own fork on Github.

The StructureMap build tooling has recently changed. See the GitHub README for more information on how to build and work with the StructureMap codebase.

- + + +

Current Release

The current version of StructureMap will always be available on Nuget. See the Release Notes for more information.

Supported Platforms

Binaries

Binaries of StructureMap are available via NuGet:

PM> Install-Package StructureMap
+

or if you need a strong named version of StructureMap:

PM> Install-Package structuremap-signed
+

The StructureMap team believes strong naming to be a blight upon the .Net land and we really wish folks would quit using it, but we understand that some circumstances absolutely require it.

Source

StructureMap's source is hosted on GitHub. If you want to fix a bug or just want to tinker with an idea, we love receiving pull requests! Start by creating your own fork on Github.

The StructureMap build tooling has recently changed. See the GitHub README for more information on how to build and work with the StructureMap codebase.

@@ -88,197 +88,72 @@

Glossary - -

There are some terms that reoccur throughout the documentation and show up in the StructureMap API. Understanding these terms and how they relate to StructureMap isn't a prerequisite to using StructureMap, but it helps.

Container

Tools like StructureMap are generally known as Inversion of Control (IoC) Containers or Dependency Injection (DI) Containers. In the Java world they are also known as Lightweight Containers to differentiate them from the older EJB Containers.

A container is a tool that can help you composing object graphs and managing their scope (lifecycle). Altough you can do Inversion of Control and Dependecy Injection manually, using tools like StructureMap makes you far more productive and succesfull in doing so.

Obviously there is more to a container then resolving services and managing their scope, but in the core that's just what it is. Before you can do so you need to tell StructureMap, the container, how it must compose those objects graphs and what their lifecycle is. This is called registration and can be done in various mixed ways. The strongly recommend way would be using the Registry DSL. In your registration your basicaly mapping abstractions to concrete types and define their lifecycle.

A simple example of a container using the Registry DSL:


-    public class FooBarRegistry : Registry
-    {
-        public FooBarRegistry()
-        {
-            For<IFoo>().Use<Foo>();
-            For<IBar>().Use<Bar>();
-        }
-    }
-
-


-            var container = new Container(c => { c.AddRegistry<FooBarRegistry>(); });
-

Because we didn't specify the lifecycle for both registrations, the default Transient lifecycle will be used. This will instruct the container to create a new instance for every request for a plugin type IFoo or IBar.

More advanced features that the container can do are things like: Interception, Auto-Wiring, Forwarding Types.

Nested Container

A nested container is used to mark the scope of short lived transactions or web requests and track and clean up objects implementing the IDisposable interface for that operation.

You can ask a existing container to create a nested container for you like in the following example:


-            using (var nested = someExistingContainer.GetNestedContainer())
-            {
-                // pull other objects from the nested container and do work with those services
-                var service = nested.GetInstance<IService>();
-                service.DoSomething();
-            }
-

For more detailed information about nested containers and their special properties you can read the <linkto:the-container/nested-containers]> topic.

PluginType and PluggedType

The term plugin type is used throughout the code and documentation to mean the type that you want to register or resolve. More generally this type is known as the service type. This type can be a concrete class or in most cases, it will be a form of abstraction like an abstract class or interface.

The term plugged type means the actual concrete type that you get when you request the plugin type. This type must obviously implement the plugin type contract.

In your registration you could have something like this:


-    public class FooRegistry : Registry
-    {
-        public FooRegistry()
-        {
-            For<IFoo>().Use<Foo>();
-        }
-    }
-
-


-//For<PLUGINTYPE>().Use<PLUGGEDTYPE>()
-
-            var container = new Container(c => { c.AddRegistry<FooRegistry>(); });
-
-            container.GetInstance<IFoo>();
-
-//container.GetInstance<PLUGINTYPE>()
-

If you request an object of IFoo, you'll get an instance of the Foo class. In this case, IFoo is the plugin type (what you're asking for) and Foo is the plugged type (the concrete class you'll get that fulfills, implements the plugin type contract).

PluginFamily

This term you will not see so often because it's mostly used by StructureMap itself. A PluginFamily represents a CLR type (the plugin type) that StructureMap can build, and all of the possible plugged types that implement the CLR type.

In the following code StructureMap internally creates one PluginFamily of the plugin type IFoo with two instances Foo and SomeOtherFoo, where Foo is the default instance because it's registered through For<PLUGIN_TYPE>().Use<PLUGGED_TYPE>().


-            var container = new Container(c =>
-            {
-                c.For<IFoo>().Use<Foo>();
-                c.For<IFoo>().Add<SomeOtherFoo>();
-            });
-

Before StructureMap 3.0 you have probably seen the term used in an exception message when you request a plugin type that doesn't have a default instance defined.

StructureMap Exception Code:  202
-No Default Instance defined for PluginFamily [plugin type]
-

This specific exception message is gone in 3.0 because the exception messages were modernized in version 3.0 and.

Plugin Graph

A PluginGraph is the configuration model of the runtime configuration of a StructureMap container. The PluginGraph model can be manipulated directly in StructureMap 3.0 for -any kind of special convention that doesn't fit into the existing conventional support.

Instance

In StructureMap terms, an "Instance" is a configured and named strategy to build or locate a named object instance for a requested Plugin Type. An "Instance" does not automatically equate to a concrete type. For example, let's say that we're building a system to automate a warehouse. Our system might consume an interface called IShippingService that acts as a Gateway to various ways of shipping boxes out of our warehouse.


-    public interface IShippingService
-    {
-        void ShipIt();
-    }
-
-

Our warehouse system might have to interact with three types of shipping: domestic, international, and intra-company or internal shipments. The internal shipping service runs in process with the warehouse application, but domestic and international shipping is done by invoking external web services. The registration of the IShippingService Instances might look like this:


-    public class ShippingRegistry : Registry
-    {
-        public ShippingRegistry()
-        {
-            For<IShippingService>().AddInstances(x =>
-            {
-                x.Type<ShippingWebService>()
-                    .Ctor<string>("url").Is("a url")
-                    .Named("Domestic");
-
-                x.Type<ShippingWebService>()
-                    .Ctor<string>("url").Is("a different url")
-                    .Named("International");
-
-                x.Type<InternalShippingService>().Named("Internal");
-            });
-        }
-    }
-
-

In the registration code above, there are three "Instance's." You can access the various IShippingService Instance's by name:


-            var container = new Container(new ShippingRegistry());
-
-            // Accessing the IShippingService Instance's by name
-            var internationalService = container.GetInstance<IShippingService>("International");
-            var domesticService = container.GetInstance<IShippingService>("Domestic");
-            var internalService = container.GetInstance<IShippingService>("Internal");
-
-

Asking for the "International" or the "Domestic" instance of IShippingService will both return an object of type ShippingWebService, but the two objects will be differently configured with unique Url's.

There is an actual class in StructureMap that represents an "Instance."

When you call Container.GetInstance<T>("the instance that I want") or Container.GetInstance<T>(), the internal Container object is locating the correct Instance object and then using the Instance's internal build plan to resolve or construct the actual object.

A StructureMap "Instance" is a close analogue for what many other IoC tools call a "Component."

Lifecycle (or Scope)

The power of an IoC container isn't just in building object graphs for you, it's also about scoping an object graph to what StructureMap calls a lifecycle. Think of it this way, -when you ask StructureMap for a service or much more commonly when StructureMap is filling a dependency behind the scenes, do you want:

A brand new, unique object each time?
The exact same object as the rest of the graph is using?
The exact same object every single time throughout the application?

Registry

A Registry or a sub class of Registry is a class that let's you create reusable configuration for StructureMap containers.

Profile

StructureMap 3.0 features a complete rewrite of the ancient Profile functionality where you can create your base Container configuration with additional Profile -configuration that overrides one or more of the parent Container defaults. The Profile functionality was originally meant to handle difference between -development, testing, and production environments but has been more commonly used for multi-tenancy situations. Think of a Profile as an application or tenant mode.

Auto wiring

You'd never get anything done if you had to tell StructureMap how to build each and every constructor or setter dependency on every concrete class. Fortunately, StructureMap like -most IoC container tools, supports the concept of auto-wiring -- meaning that StructureMap can happily infer dependency requirements from constructor functions and setter -rules and fill those dependencies with the default configuration for the declared dependency type.

Let's just see it in action:


-    public interface Xman
-    {
-    }
-
-    public class Cyclops : Xman
-    {
-    }
-
-    public interface Avenger
-    {
-    }
-
-    public class IronMan : Avenger
-    {
-    }
-
-    public class CrossoverEvent
-    {
-        public Xman Xman { get; set; }
-        public Avenger Avenger { get; set; }
-
-        public CrossoverEvent(Xman xman, Avenger avenger)
-        {
-            Xman = xman;
-            Avenger = avenger;
-        }
-    }
-
-    public class UsingCrossover
-    {
-        [Fact]
-        public void showing_auto_wiring()
-        {
-            var container = new Container(x =>
-            {
-                x.For<Xman>().Use<Cyclops>();
-                x.For<Avenger>().Use<IronMan>();
-            });
-
-            // Notice that at no point did we define how to
-            // build CrossoverEvent.
-            var @event = container.GetInstance<CrossoverEvent>();
-            @event.Avenger.ShouldBeOfType<IronMan>();
-            @event.Xman.ShouldBeOfType<Cyclops>();
-        }
-    }
-
-

- + +

Container

Obviously there is more to a container then resolving services and managing their scope, but in the core that's just what it is. Before you can do so you need to tell StructureMap, the container, how it must compose those objects graphs and what their lifecycle is. This is called registration and can be done in various mixed ways. The strongly recommend way would be using the Registry DSL. In your registration you're basically mapping abstractions to concrete types and defining their lifecycle.

A simple example of a container using the Registry DSL:


public class FooBarRegistry : Registry
{
    public FooBarRegistry()
    {
        For<IFoo>().Use<Foo>();
        For<IBar>().Use<Bar>();
    }
}


var container = new Container(c => { c.AddRegistry<FooBarRegistry>(); });

More advanced features that the container can do are things like: Interception, Auto-Wiring, Forwarding Types.

Nested Container

A nested container is used to mark the scope of short lived transactions or web requests and track and clean up objects implementing the IDisposable interface for that operation.

You can ask an existing container to create a nested container for you like in the following example:


using (var nested = someExistingContainer.GetNestedContainer())
{
    // pull other objects from the nested container and do work with those services
    var service = nested.GetInstance<IService>();
    service.DoSomething();
}

For more detailed information about nested containers and their special properties you can read the Nested Containers (Per Request/Transaction) topic.

PluginType and PluggedType

The term plugged type means the actual concrete type that you get when you request the plugin type. This type must obviously implement the plugin type contract.

In your registration you could have something like this:


public class FooRegistry : Registry
{
    public FooRegistry()
    {
        For<IFoo>().Use<Foo>();
    }
}


//For<PLUGINTYPE>().Use<PLUGGEDTYPE>()

            var container = new Container(c => { c.AddRegistry<FooRegistry>(); });

            container.GetInstance<IFoo>();

//container.GetInstance<PLUGINTYPE>()

PluginFamily


var container = new Container(c =>
{
    c.For<IFoo>().Use<Foo>();
    c.For<IFoo>().Add<SomeOtherFoo>();
});

Before StructureMap 3.0 you have probably seen the term used in an exception message when you request a plugin type that doesn't have a default instance defined.

StructureMap Exception Code:  202
+No Default Instance defined for PluginFamily [plugin type]
+

This specific exception message is gone in 3.0 because the exception messages were modernized.

Plugin Graph

A PluginGraph is the configuration model of the runtime configuration of a StructureMap container. The PluginGraph model can be manipulated directly in StructureMap 3.0 for +any kind of special convention that doesn't fit into the existing conventional support.

Instance


public interface IShippingService
{
    void ShipIt();
}


public class ShippingRegistry : Registry
{
    public ShippingRegistry()
    {
        For<IShippingService>().AddInstances(x =>
        {
            x.Type<ShippingWebService>()
                .Ctor<string>("url").Is("a url")
                .Named("Domestic");

            x.Type<ShippingWebService>()
                .Ctor<string>("url").Is("a different url")
                .Named("International");

            x.Type<InternalShippingService>().Named("Internal");
        });
    }
}

In the registration code above, there are three "Instances." You can access the various IShippingService Instance's by name:


var container = new Container(new ShippingRegistry());

// Accessing the IShippingService Instance's by name
var internationalService = container.GetInstance<IShippingService>("International");
var domesticService = container.GetInstance<IShippingService>("Domestic");
var internalService = container.GetInstance<IShippingService>("Internal");

There is an actual class in StructureMap that represents an "Instance."

A StructureMap "Instance" is a close analogue for what many other IoC tools call a "Component."

Lifecycle (or Scope)

The power of an IoC container isn't just in building object graphs for you, it's also about scoping an object graph to what StructureMap calls a lifecycle. Think of it this way: +when you ask StructureMap for a service or (much more commonly) when StructureMap is filling a dependency behind the scenes, do you want:

A brand new, unique object each time?
The exact same object as the rest of the graph is using?
The exact same object every single time throughout the application?

Registry

A Registry or a sub class of Registry is a class that let's you create reusable configuration for StructureMap containers.

Profile

StructureMap 3.0 features a complete rewrite of the ancient Profile functionality where you can create your base Container configuration with additional Profile +configuration that overrides one or more of the parent Container defaults. The Profile functionality was originally meant to handle differences between +development, testing, and production environments but has been more commonly used for multi-tenancy situations. Think of a Profile as an application or tenant mode.

Auto wiring

You'd never get anything done if you had to tell StructureMap how to build each and every constructor or setter dependency on every concrete class. Fortunately, StructureMap like +most IoC container tools, supports the concept of auto-wiring -- meaning that StructureMap can happily infer dependency requirements from constructor functions and setter +rules and fill those dependencies with the default configuration for the declared dependency type.

Let's just see it in action:


public interface Xman
{
}

public class Cyclops : Xman
{
}

public interface Avenger
{
}

public class IronMan : Avenger
{
}

public class CrossoverEvent
{
    public Xman Xman { get; set; }
    public Avenger Avenger { get; set; }

    public CrossoverEvent(Xman xman, Avenger avenger)
    {
        Xman = xman;
        Avenger = avenger;
    }
}

public class UsingCrossover
{
    [Fact]
    public void showing_auto_wiring()
    {
        var container = new Container(x =>
        {
            x.For<Xman>().Use<Cyclops>();
            x.For<Avenger>().Use<IronMan>();
        });

        // Notice that at no point did we define how to
        // build CrossoverEvent.
        var @event = container.GetInstance<CrossoverEvent>();
        @event.Avenger.ShouldBeOfType<IronMan>();
        @event.Xman.ShouldBeOfType<Cyclops>();
    }
}

@@ -88,19 +88,18 @@

History - - -
StructureMap was originally conceived in 2002 as the world's greatest object/relational mapping tool (and frankly a way for me to -prove to prospective employers that I could actually code so I could move on from my non-coding architect position at that time). -What exists today is the descendent of the overly grandiose configuration subsystem for that failed ORM concept (hence the name "StructureMap").
-
StructureMap was resurrected in the spring of 2004 as an "Inversion of Control" tool after I read about the http://picocontainer.codehaus.org IoC tool written in Java by several folks at my company at that time. In June of 2004 StructureMap went into its first production application and was also publicly -released on the old Sourceforge.net website. As such, StructureMap is the oldest, continuously used IoC tool for .Net development.
-
The current release (3.) represents the lessons learned from over 10 years of usage and other than a handful of class names bears very little -internal resemblance to the original codebase.
-
StructureMap moved to GitHub in 2010 and is now distributed via Nuget.
-
To learn more about the StructureMap journey, see the Joys and Pains of a Long Lived Codebase on InfoQ from QCon 2008, or check out -Jeremy Miller's updated retrospective talk at CodeMash 2015.
- + + +
StructureMap was originally conceived in 2002 as the world's greatest object/relational mapping tool (and frankly a way for me to +prove to prospective employers that I could actually code so I could move on from my non-coding architect position at that time). +What exists today is the descendent of the overly grandiose configuration subsystem for that failed ORM concept (hence the name "StructureMap").
+
StructureMap was resurrected in the spring of 2004 as an "Inversion of Control" tool after I read about the http://picocontainer.codehaus.org IoC tool written in Java by several folks at my company at that time. In June of 2004 StructureMap went into its first production application and was also publicly +released on the old Sourceforge.net website. As such, StructureMap is the oldest, continuously used IoC tool for .Net development.
+
The current release (3.) represents the lessons learned from over 10 years of usage and other than a handful of class names bears very little +internal resemblance to the original codebase.
+
StructureMap moved to GitHub in 2010 and is now distributed via Nuget.
+
To learn more about the StructureMap journey, see the Joys and Pains of a Long Lived Codebase on InfoQ from QCon 2008, or check out +Jeremy Miller's updated retrospective talk at CodeMash 2015.

@@ -91,34 +91,16 @@

Custom Instance Types - public class FuncInstance<T> : LambdaInstance<Func<T>> - { - // Pass a Func<IContext, T> into the base constructor - // Use a static method for cleaner syntax to avoid the - // nasty Lambda syntax formatting as needed - public FuncInstance() : base(s => s.GetInstance<IContainer>().GetInstance<T>) - { - } - - public override string Description - { - get { return "Constructor for Func<{0}>".ToFormat(typeof (T).Name); } - } - } - +


public class FuncInstance<T> : LambdaInstance<Func<T>>
{
    // Pass a Func<IContext, T> into the base constructor
    // Use a static method for cleaner syntax to avoid the 
    // nasty Lambda syntax formatting as needed
    public FuncInstance() : base(s => s.GetInstance<IContainer>().GetInstance<T>)
    {
    }

    public override string Description
    {
        get { return "Constructor for Func<{0}>".ToFormat(typeof (T).Name); }
    }
}

The other common customization is as a generic builder template

If neither of these approaches will easily work for your custom Instance, you may want to contact the StructureMap team via the gitter link above and we can help walk you through a custom subclass of Instance -- or more likely, talk you out of it somehow.

Missing Name Instance Template

New to StructureMap 4.0 is the Instance.ToNamedClone(name) method that is used behind the scenes by the Handling Missing Named Instances feature.


-        public virtual Instance ToNamedClone(string name)
-


public virtual Instance ToNamedClone(string name)

Custom Instance types can override this method to provide a brand new Instance for a name. This functionality may be useful for multi-tenancy situations.

@@ -88,33 +88,32 @@

Integrating StructureMap into Common .Net Frameworks - -
Want to see more integrations or samples of how to integrate StructureMap with various .Net development tools? Let us know in Gitter or Github, or better yet, we take pull requests for documentation.
-
ASP.Net MVC 5
-
The StructureMap team recommends the StructureMap.MVC5 nuget for integrating -StructureMap into pre-DNX ASP.Net MVC. The design is necessarily odd to work around ASP.Net limitations, but you do get the all -important "nested container per HTTP request" pattern that we recommend.
-

Web API (pre-DNX)

The StructureMap team recommends the StructureMap.WebApi2 nuget package. -The IoC integration in Web API is somewhat better designed than ASP.Net MVC's bolt on mechanism and the StructureMap integration -is quite a bit cleaner.

DNX

See the StructureMap.DNX project and Nuget for an early version of integration with DNX.

NServiceBus

Use the NServiceBus StructureMap nuget for integrating StructureMap 3 into -NServiceBus.

NancyFx

NancyFx provides the Nancy.BootStrappers.StructureMap nuget package. The early -versions of the NancyFx integration with StructureMap were deeply flawed but improved in later versions, so do make sure that you are using the latest version of the bootstrapper.

MassTransit

Use the MassTransit.StructureMap nuget package. Unfortunately, this package -depends on the signed version of StructureMap, so prepare yourself for version conflicts, -binding redirects, and the fusion log viewer. See the MassTransit documentation on using StructureMap for more information.

Entity Framework

The best example is this blog post from Jimmy Bogard.

AutoMapper

See My AutoMapper setup for StructureMap from Martijn Burgers.

- + +

Want to see more integrations or samples of how to integrate StructureMap with various .Net development tools? Let us know in Gitter or Github, or better yet, we take pull requests for documentation.

ASP.NET MVC 5

The StructureMap team recommends the StructureMap.MVC5 NuGet package for integrating +StructureMap into ASP.NET MVC. The design is necessarily odd to work around ASP.NET limitations, but you do get the all +important "nested container per HTTP request" pattern that we recommend.

ASP.NET Web API

The StructureMap team recommends the StructureMap.WebApi2 NuGet package. +The IoC integration in Web API is somewhat better designed than ASP.NET MVC's bolt on mechanism and the StructureMap integration +is quite a bit cleaner.

ASP.NET Core

See the StructureMap.Microsoft.DependencyInjection project and NuGet package for integration with ASP.NET Core.

NServiceBus

Use the NServiceBus StructureMap NuGet package for integrating StructureMap 3 into +NServiceBus.

NancyFx

NancyFx provides the Nancy.Bootstrappers.StructureMap NuGet package. The early +versions of the NancyFx integration with StructureMap were deeply flawed but improved in later versions, so do make sure that you are using the latest version of the bootstrapper.

MassTransit

Use the MassTransit.StructureMap NuGet package. Unfortunately, this package +depends on the signed version of StructureMap, so prepare yourself for version conflicts, +binding redirects, and the fusion log viewer. See the MassTransit documentation on using StructureMap for more information.

Entity Framework

The best example is this blog post from Jimmy Bogard.

AutoMapper

See My AutoMapper setup for StructureMap from Martijn Burgers.

@@ -88,347 +88,101 @@

Interception and Decorators - - -
All of the samples from this topic are part of the user acceptance tests in the main codebase. There is also another example of using an interception policy with -open generic types at the bottom of Generic Types
-
Improving the interception facilities and the means of applying decorators during object construction was one of the primary -goals of the big 3.0 release and is significantly different than the older 2.5/2.6 model.
-
Interception in StructureMap really comes -in two basic flavors:
-
-
Activates - Do some action on or with an object just created or resolved by StructureMap
-
Decorates - Wrap (or optionally replace) an object just created with either a dynamic proxy or some sort of decorator
-
-
Interceptors can be configured explicitly on a single `Instance` registration, on all registrations to a `PluginFamily`, or conventionally -to any concrete type implementing an interface, inheriting from a certain base class, or by some sort of user-supplied -criteria.
-
Any type of `Instance` can be intercepted, meaning that even object literal values supplied to StructureMap at registration can be -intercepted when they are resolved as dependencies or through service location calls.
-
See the Glossary for a refresher on terms like `Instance` and `PluginFamily`.
-
Also see Working with the IContext at Build Time for more information about using the `Container` state within interception.
-

Activation Interceptors

For right now, all activation interceptors are either using or subclassing the ActivatorInterceptor<T> class.

This class has two constructor functions that interest us:

To create an activator interceptor that acts on an object that can be cast to type T:


-        public ActivatorInterceptor(Expression<Action<T>> action, string description = null)
-

To create an activator interceptor that acts on an object that can be cast to type T and -also uses the IContext service supplied by StructureMap itself.


-        public ActivatorInterceptor(Expression<Action<IContext, T>> action, string description = null)
-        {
-            _action = action;
-            _description = description;
-        }
-

In both cases, the description is optional and is only used for diagnostic purposes in the build plan visualization. If -omitted, StructureMap tries to do a ToString() on the Expression for the description and that frequently suffices to understand what's going on in the build plan.

Please note that the Lambda supplied to ActivatorInterceptor<T> must be a .Net Expression so cannot be a multi-line Lambda. -You can get around this limitation for more complex activation needs by simply making a wrapping method and using that -to express the activation.

Decorators

To demonstrate a decorator in action, say that we have an interface called IWidget, and when we build any instance -of IWidget we want those objects decorated by another type of IWidget that I clumsily named WidgetHolder in the -acceptance tests:


-    public class WidgetHolder : IWidget
-    {
-        private readonly IWidget _inner;
-
-        public WidgetHolder(IWidget inner)
-        {
-            _inner = inner;
-        }
-
-        public IWidget Inner
-        {
-            get { return _inner; }
-        }
-    }
-
-

Now, to see the decorator mechanism in action:


-        [Fact]
-        public void decorator_example()
-        {
-            var container = new Container(_ =>
-            {
-                // This usage adds the WidgetHolder as a decorator
-                // on all IWidget registrations and makes AWidget
-                // the default
-                _.For<IWidget>().DecorateAllWith<WidgetHolder>();
-                _.For<IWidget>().Use<AWidget>();
-            });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<WidgetHolder>()
-                .Inner.ShouldBeOfType<AWidget>();
-        }
-
-

In effect, doing a decorator this way has the same effect (and build plan) as:


-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Use<WidgetHolder>()
-                    .Ctor<IWidget>().Is<AWidget>();
-            });
-

Custom Decorator Interceptors

The simplest usage is to just declare a type that will be the decorating type like we did above, but if you need some -other mechanism for decorators like runtime AOP interception or you want to build the decorating object yourself, StructureMap -provides the FuncInterceptor<T> type where T is the type you want to decorate.

These objects can be created in two ways, by a user-supplied Expression<Func<T, T>> and optional description:


-        public FuncInterceptor(Expression<Func<T, T>> expression, string description = null)
-

and by a user-supplied Expression<Func<IContext, T, T>> and optional description.


-        public FuncInterceptor(Expression<Func<IContext, T, T>> expression, string description = null)
-

In both cases, the description field is only used for diagnostic purposes.

Interception Policies

The Registry DSL includes shorthand methods for the most common ways of configuring decorators -and activators by an individual Instance or by matching on implementing types. For more customized interception policies -that don't fit these mechanisms, StructureMap allows you to directly define an interception policy with a class -implementing this interface below:


-    /// <summary>
-    /// User defined policy to conventionally attach interceptors
-    /// to any pluginType/instance combination in a StructureMap
-    /// container
-    /// </summary>
-    public interface IInterceptorPolicy : IDescribed
-    {
-        /// <summary>
-        /// Determine what (if any) interceptors should be attached to the
-        /// given instance and pluginType
-        /// </summary>
-        /// <param name="pluginType">The Type that is being requested</param>
-        /// <param name="instance">The Instance being built</param>
-        /// <returns></returns>
-        IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance);
-    }
-

For a simple example, let's say that we want to decorate any IWidget object with the -WidgetHolder class from earlier. We could build a small custom interceptor policy -like this one:


-    public class CustomInterception : IInterceptorPolicy
-    {
-        public string Description
-        {
-            get { return "good interception policy"; }
-        }
-
-        public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance)
-        {
-            if (pluginType == typeof(IWidget))
-            {
-                // DecoratorInterceptor is the simple case of wrapping one type with another
-                // concrete type that takes the first as a dependency
-                yield return new DecoratorInterceptor(typeof(IWidget), typeof(WidgetHolder));
-            }
-        }
-    }
-
-

To use this custom interception policy, use the Policies.Interceptor() methods like this example:


-        [Fact]
-        public void use_a_custom_interception_policy()
-        {
-            var container = new Container(x =>
-            {
-                x.Policies.Interceptors(new CustomInterception());
-
-                x.For<IWidget>().Use<AWidget>();
-            });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<WidgetHolder>()
-                .Inner.ShouldBeOfType<AWidget>();
-        }
-
-

As a helper for creating your own interception policies, you can also use the InterceptorPolicy<T> base class -to conventionally apply some sort of IInterceptor to any number of Instance's:


-        public InterceptorPolicy(IInterceptor interceptor, Func<Instance, bool> filter = null)
-

Here's an example of InterceptorPolicy<T> in usage from the acceptance tests:


-        [Fact]
-        public void apply_policy_selectively_with_a_func()
-        {
-            var activator1 = new ActivatorInterceptor<ITarget>(x => x.Activate());
-            var policy = new InterceptorPolicy<ITarget>(activator1, i => i.Name.StartsWith("A"));
-
-            var container = new Container(x =>
-            {
-                x.Policies.Interceptors(policy);
-                x.For<ITarget>().AddInstances(targets =>
-                {
-                    targets.Type<ATarget>().Named("A");
-                    targets.Type<ATarget>().Named("A1");
-                    targets.Type<ATarget>().Named("A2");
-                    targets.Type<ATarget>().Named("B");
-                    targets.Type<ATarget>().Named("C");
-                    targets.Type<ATarget>().Named("D");
-                });
-            });
-
-            container.GetInstance<ITarget>("A").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
-            container.GetInstance<ITarget>("A1").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
-            container.GetInstance<ITarget>("A2").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
-            container.GetInstance<ITarget>("B").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
-            container.GetInstance<ITarget>("C").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
-            container.GetInstance<ITarget>("D").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
-        }
-
-        public class ATarget : ITarget
-        {
-            public void Activate()
-            {
-                WasActivated = true;
-            }
-
-            public bool WasActivated { get; set; }
-
-            public void Debug()
-            {
-                throw new NotImplementedException();
-            }
-        }
-
-

Some quick things to note:

For decorator interceptors, InterceptorPolicy<T> will only apply if the pluginType matches T
For activation interceptors, InterceptorPolicy<T> will apply to any concrete type returned by an Instance that can be -cast to T

Apply Activation Interception by Type

Let's say that in your system you have a marker interface or in this case an abstract class that exposes a single -Activate() method to start up stateful, long-running services created within your container:


-    public abstract class Activateable
-    {
-        public bool Activated { get; set; }
-
-        public void Activate()
-        {
-            Activated = true;
-        }
-    }
-
-

An implementation of Activateable from StructureMap's unit tests is shown below:


-    public class AWidget : Activateable, IWidget
-    {
-    }
-
-

If you decide that you'd like StructureMap to call the Activate() method on any object it creates as -part of its object creation and resolution process, we can register an interception policy in a Registry -like this:


-        [Fact]
-        public void activate_by_action()
-        {
-            var container = new Container(x =>
-            {
-                x.For<IWidget>().Use<AWidget>();
-                x.For<Activateable>()
-                    .OnCreationForAll("Mark the object as activated", o => o.Activated = true);
-            });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<AWidget>()
-                .Activated.ShouldBeTrue();
-        }
-
-

There are several overloads of OnCreationForAll() covering cases with and without IContext

Apply Decoration across a Plugin Type

As shown above, you can use the Registry.For<T>().DecorateAllWith<TDecorator>() to apply decorators to all Instance's -registered to a Plugin Type:


-        [Fact]
-        public void decorate_with_type()
-        {
-            var container = new Container(x =>
-            {
-                x.For<IWidget>().DecorateAllWith<WidgetHolder>();
-                x.For<IWidget>().Use<AWidget>();
-            });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<WidgetHolder>()
-                .Inner
-                .ShouldBeOfType<AWidget>();
-        }
-
-

There are also several other overloads of DecorateAllWith() for user supplied expressions, filters, and descriptions. See the -acceptance tests for interception in the StructureMap codebase for many more sample usages.

Add Interception to a Single Instance

You can also define interceptors directly to individual Instance's inside of a StructureMap Registry using the -OnCreation() and DecorateWith methods or the more generic Instance.AddInterceptor() method. Here is some sample -usage from StructureMap's unit tests on interception:


-            _container = new Container(r =>
-            {
-                r.For<ContextRecorder>().Use(recorder);
-
-                r.For<IService>().AddInstances(x =>
-                {
-                    x.Type<ColorService>()
-                        // Registers an activation action on this Instance
-                        .OnCreation("last service", s => _lastService = s)
-                        .Named("Intercepted")
-                        .Ctor<string>("color").Is("Red");
-
-                    x.Type<ColorService>()
-                        // Activation using IContext
-                        .OnCreation("last touched", (c, s) => c.GetInstance<ContextRecorder>().WasTouched = true)
-                        .Named("InterceptedWithContext")
-                        .Ctor<string>("color").Is("Red");
-
-                    x.Type<ColorService>()
-                        .Named("NotIntercepted")
-                        .Ctor<string>("color").Is("Blue");
-
-                    x.Object(new ColorService("Yellow"))
-                        .Named("Yellow")
-                        .OnCreation("set the last service", s => _lastService = s);
-
-                    x.ConstructedBy(() => new ColorService("Purple")).Named("Purple")
-                        // Applies a decorator to this instance. Not sure *why*
-                        // you'd want to do it this way
-                        .DecorateWith(s => new DecoratorService(s));
-
-                    x.ConstructedBy(() => new ColorService("Purple")).Named("DecoratedWithContext")
-                        // Fancier decorator
-                        .DecorateWith("decorated with context", (c, s) =>
-                        {
-                            c.GetInstance<ContextRecorder>().WasTouched = true;
-                            return new DecoratorService(s);
-                        });
-
-                    x.Type<ColorService>().Named("Decorated").DecorateWith(
-                        s => new DecoratorService(s))
-                        .Ctor<string>("color").Is("Orange");
-
-                    x.Object(new ColorService("Yellow")).Named("Bad")
-                        .OnCreation("throw exception", obj => { throw new Exception("Bad!"); });
-                });
-

- + + +

All of the samples from this topic are part of the user acceptance tests in the main codebase. There is also another example of using an interception policy with +open generic types at the bottom of Generic Types

Improving the interception facilities and the means of applying decorators during object construction was one of the primary +goals of the big 3.0 release and is significantly different than the older 2.5/2.6 model.

Interception in StructureMap really comes +in two basic flavors:

Activates - Do some action on or with an object just created or resolved by StructureMap
Decorates - Wrap (or optionally replace) an object just created with either a dynamic proxy or some sort of decorator

Interceptors can be configured explicitly on a single Instance registration, on all registrations to a PluginFamily, or conventionally +to any concrete type implementing an interface, inheriting from a certain base class, or by some sort of user-supplied +criteria.

Any type of Instance can be intercepted, meaning that even object literal values supplied to StructureMap at registration can be +intercepted when they are resolved as dependencies or through service location calls.

See the Glossary for a refresher on terms like Instance and PluginFamily.

Also see Working with the IContext at Build Time for more information about using the Container state within interception.

Activation Interceptors

For right now, all activation interceptors are either using or subclassing the ActivatorInterceptor<T> class.

This class has two constructor functions that interest us:

To create an activator interceptor that acts on an object that can be cast to type T:


public ActivatorInterceptor(Expression<Action<T>> action, string description = null)

To create an activator interceptor that acts on an object that can be cast to type T and +also uses the IContext service supplied by StructureMap itself.


public ActivatorInterceptor(Expression<Action<IContext, T>> action, string description = null)
{
    _action = action;
    _description = description;
}

In both cases, the description is optional and is only used for diagnostic purposes in the build plan visualization. If +omitted, StructureMap tries to do a ToString() on the Expression for the description and that frequently suffices to understand what's going on in the build plan.

Please note that the Lambda supplied to ActivatorInterceptor<T> must be a .Net Expression so cannot be a multi-line Lambda. +You can get around this limitation for more complex activation needs by simply making a wrapping method and using that +to express the activation.

Decorators

To demonstrate a decorator in action, say that we have an interface called IWidget, and when we build any instance +of IWidget we want those objects decorated by another type of IWidget that I clumsily named WidgetHolder in the +acceptance tests:


public class WidgetHolder : IWidget
{
    private readonly IWidget _inner;

    public WidgetHolder(IWidget inner)
    {
        _inner = inner;
    }

    public IWidget Inner
    {
        get { return _inner; }
    }
}

Now, to see the decorator mechanism in action:


[Fact]
public void decorator_example()
{
    var container = new Container(_ =>
    {
        // This usage adds the WidgetHolder as a decorator
        // on all IWidget registrations and makes AWidget
        // the default
        _.For<IWidget>().DecorateAllWith<WidgetHolder>();
        _.For<IWidget>().Use<AWidget>();
    });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<WidgetHolder>()
        .Inner.ShouldBeOfType<AWidget>();
}

In effect, doing a decorator this way has the same effect (and build plan) as:


var container = new Container(_ =>
{
    _.For<IWidget>().Use<WidgetHolder>()
        .Ctor<IWidget>().Is<AWidget>();
});

Custom Decorator Interceptors

The simplest usage is to just declare a type that will be the decorating type like we did above, but if you need some +other mechanism for decorators like runtime AOP interception or you want to build the decorating object yourself, StructureMap +provides the FuncInterceptor<T> type where T is the type you want to decorate.

These objects can be created in two ways, by a user-supplied Expression<Func<T, T>> and optional description:


public FuncInterceptor(Expression<Func<T, T>> expression, string description = null)

and by a user-supplied Expression<Func<IContext, T, T>> and optional description.


public FuncInterceptor(Expression<Func<IContext, T, T>> expression, string description = null)

In both cases, the description field is only used for diagnostic purposes.

Interception Policies

The Registry DSL includes shorthand methods for the most common ways of configuring decorators +and activators by an individual Instance or by matching on implementing types. For more customized interception policies +that don't fit these mechanisms, StructureMap allows you to directly define an interception policy with a class +implementing this interface below:


/// <summary>
/// User defined policy to conventionally attach interceptors
/// to any pluginType/instance combination in a StructureMap
/// container
/// </summary>
public interface IInterceptorPolicy : IDescribed
{
    /// <summary>
    /// Determine what (if any) interceptors should be attached to the
    /// given instance and pluginType
    /// </summary>
    /// <param name="pluginType">The Type that is being requested</param>
    /// <param name="instance">The Instance being built</param>
    /// <returns></returns>
    IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance);
}

For a simple example, let's say that we want to decorate any IWidget object with the +WidgetHolder class from earlier. We could build a small custom interceptor policy +like this one:


public class CustomInterception : IInterceptorPolicy
{
    public string Description
    {
        get { return "good interception policy"; }
    }

    public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance)
    {
        if (pluginType == typeof(IWidget))
        {
            // DecoratorInterceptor is the simple case of wrapping one type with another
            // concrete type that takes the first as a dependency
            yield return new DecoratorInterceptor(typeof(IWidget), typeof(WidgetHolder));
        }
    }
}

To use this custom interception policy, use the Policies.Interceptor() methods like this example:


[Fact]
public void use_a_custom_interception_policy()
{
    var container = new Container(x =>
    {
        x.Policies.Interceptors(new CustomInterception());

        x.For<IWidget>().Use<AWidget>();
    });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<WidgetHolder>()
        .Inner.ShouldBeOfType<AWidget>();
}

As a helper for creating your own interception policies, you can also use the InterceptorPolicy<T> base class +to conventionally apply some sort of IInterceptor to any number of Instance's:


public InterceptorPolicy(IInterceptor interceptor, Func<Instance, bool> filter = null)

Here's an example of InterceptorPolicy<T> in usage from the acceptance tests:


[Fact]
public void apply_policy_selectively_with_a_func()
{
    var activator1 = new ActivatorInterceptor<ITarget>(x => x.Activate());
    var policy = new InterceptorPolicy<ITarget>(activator1, i => i.Name.StartsWith("A"));

    var container = new Container(x =>
    {
        x.Policies.Interceptors(policy);
        x.For<ITarget>().AddInstances(targets =>
        {
            targets.Type<ATarget>().Named("A");
            targets.Type<ATarget>().Named("A1");
            targets.Type<ATarget>().Named("A2");
            targets.Type<ATarget>().Named("B");
            targets.Type<ATarget>().Named("C");
            targets.Type<ATarget>().Named("D");
        });
    });

    container.GetInstance<ITarget>("A").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
    container.GetInstance<ITarget>("A1").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
    container.GetInstance<ITarget>("A2").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
    container.GetInstance<ITarget>("B").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
    container.GetInstance<ITarget>("C").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
    container.GetInstance<ITarget>("D").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
}

public class ATarget : ITarget
{
    public void Activate()
    {
        WasActivated = true;
    }

    public bool WasActivated { get; set; }

    public void Debug()
    {
        throw new NotImplementedException();
    }
}

Some quick things to note:

For decorator interceptors, InterceptorPolicy<T> will only apply if the pluginType matches T
For activation interceptors, InterceptorPolicy<T> will apply to any concrete type returned by an Instance that can be +cast to T

Apply Activation Interception by Type

Let's say that in your system you have a marker interface or in this case an abstract class that exposes a single +Activate() method to start up stateful, long-running services created within your container:


public abstract class Activateable
{
    public bool Activated { get; set; }

    public void Activate()
    {
        Activated = true;
    }
}

An implementation of Activateable from StructureMap's unit tests is shown below:


public class AWidget : Activateable, IWidget
{
}

If you decide that you'd like StructureMap to call the Activate() method on any object it creates as +part of its object creation and resolution process, we can register an interception policy in a Registry +like this:


[Fact]
public void activate_by_action()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Use<AWidget>();
        x.For<Activateable>()
            .OnCreationForAll("Mark the object as activated", o => o.Activated = true);
    });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<AWidget>()
        .Activated.ShouldBeTrue();
}

There are several overloads of OnCreationForAll() covering cases with and without IContext

Apply Decoration across a Plugin Type

As shown above, you can use the Registry.For<T>().DecorateAllWith<TDecorator>() to apply decorators to all Instance's +registered to a Plugin Type:


[Fact]
public void decorate_with_type()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().DecorateAllWith<WidgetHolder>();
        x.For<IWidget>().Use<AWidget>();
    });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<WidgetHolder>()
        .Inner
        .ShouldBeOfType<AWidget>();
}

There are also several other overloads of DecorateAllWith() for user supplied expressions, filters, and descriptions. See the +acceptance tests for interception in the StructureMap codebase for many more sample usages.

Add Interception to a Single Instance

You can also define interceptors directly to individual Instance's inside of a StructureMap Registry using the +OnCreation() and DecorateWith methods or the more generic Instance.AddInterceptor() method. Here is some sample +usage from StructureMap's unit tests on interception:


_container = new Container(r =>
{
    r.For<ContextRecorder>().Use(recorder);

    r.For<IService>().AddInstances(x =>
    {
        x.Type<ColorService>()
            // Registers an activation action on this Instance
            .OnCreation("last service", s => _lastService = s)
            .Named("Intercepted")
            .Ctor<string>("color").Is("Red");

        x.Type<ColorService>()
            // Activation using IContext
            .OnCreation("last touched", (c, s) => c.GetInstance<ContextRecorder>().WasTouched = true)
            .Named("InterceptedWithContext")
            .Ctor<string>("color").Is("Red");

        x.Type<ColorService>()
            .Named("NotIntercepted")
            .Ctor<string>("color").Is("Blue");

        x.Object(new ColorService("Yellow"))
            .Named("Yellow")
            .OnCreation("set the last service", s => _lastService = s);

        x.ConstructedBy(() => new ColorService("Purple")).Named("Purple")
            // Applies a decorator to this instance. Not sure *why*
            // you'd want to do it this way
            .DecorateWith(s => new DecoratorService(s));

        x.ConstructedBy(() => new ColorService("Purple")).Named("DecoratedWithContext")
            // Fancier decorator
            .DecorateWith("decorated with context", (c, s) =>
            {
                c.GetInstance<ContextRecorder>().WasTouched = true;
                return new DecoratorService(s);
            });

        x.Type<ColorService>().Named("Decorated").DecorateWith(
            s => new DecoratorService(s))
            .Ctor<string>("color").Is("Orange");

        x.Object(new ColorService("Yellow")).Named("Bad")
            .OnCreation("throw exception", obj => { throw new Exception("Bad!"); });
    });

@@ -88,24 +88,23 @@

Interpreting Exceptions - - -
Improving the exception messages was one of the primary goals of the big StructureMap 3.0 release. StructureMap exceptions should -show a "StructureMap-specific stacktrace" describing where in the object graph StructureMap was when an exception occurred, while -trying hard not to obscure the actual problems. In some cases, StructureMap will append diagnostic views -to the exception output. If you are still using StructureMap 2.5-2.6, the better exception messages alone are a justification for upgrading.
-
StructureMap throws a couple custom exceptions, all of which implement a base `StructureMapException` type:
-
-
`StructureMapBuildException` -- a failure was detected during an attempt to build or resolve a requested object or dependency, but outside of -StructureMap code. This exception wraps the actual exception and adds StructureMap-specific contextual information. Always check the inner -exception when this exception is thrown.
-
`StructureMapInterceptorException` -- a configured interceptor failed during object construction. See the inner exception.
-
`StructureMapBuildPlanException` -- StructureMap is missing some kind of configuration or needs more explicit registrations in order to -build an `Instance`. In a few cases, this exception will be thrown if StructureMap cannot create and compile a `Func` internally for the -`Instance.`
-
`StructureMapConfigurationException` -- thrown by the container validation mechanism
-
- + + +
Improving the exception messages was one of the primary goals of the big StructureMap 3.0 release. StructureMap exceptions should +show a "StructureMap-specific stacktrace" describing where in the object graph StructureMap was when an exception occurred, while +trying hard not to obscure the actual problems. In some cases, StructureMap will append diagnostic views +to the exception output. If you are still using StructureMap 2.5-2.6, the better exception messages alone are a justification for upgrading.
+
StructureMap throws a couple custom exceptions, all of which implement a base `StructureMapException` type:
+
+
`StructureMapBuildException` -- a failure was detected during an attempt to build or resolve a requested object or dependency, but outside of +StructureMap code. This exception wraps the actual exception and adds StructureMap-specific contextual information. Always check the inner +exception when this exception is thrown.
+
`StructureMapInterceptorException` -- a configured interceptor failed during object construction. See the inner exception.
+
`StructureMapBuildPlanException` -- StructureMap is missing some kind of configuration or needs more explicit registrations in order to +build an `Instance`. In a few cases, this exception will be thrown if StructureMap cannot create and compile a `Func` internally for the +`Instance.`
+
`StructureMapConfigurationException` -- thrown by the container validation mechanism
+

@@ -88,74 +88,24 @@

Configuring Lifecycles - - -

Unless designated otherwise, StructureMap uses Transient as the default scope for all configured Instance's.

StructureMap's default scoping to Transient is not a universal assumption across IoC containers in .Net. Be careful with this if you are coming to StructureMap from tools that choose Singleton as their default scope.

The resolution of the lifecycle for any given Instance is to check:

Use the explicitly configured lifecycle for the Instance
If no lifecycle is configured for the Instance, use the explicitly configured lifecycle for the Plugin Type
If no lifecycle is configured for either the Instance or the Plugin Type, use the default Transient lifecycle

The lifecycle precedence rules and the syntax for configuring object lifecycles are shown below:


-        [Fact]
-        public void lifecycle_precedence()
-        {
-            var container = new Container(x =>
-            {
-                x.For<IWidget>().Use<AWidget>();
-
-                // Configure the default lifecycle for
-                // a PluginType (Rule)
-                x.For<Rule>().Singleton();
-                x.For<Rule>().Add<ARule>().Named("C");
-
-                // Configure the lifecycle for a single Instance
-                x.For<Rule>().Add<ARule>().Named("A").Transient();
-                x.For<Rule>().Add<ARule>().Named("B").AlwaysUnique();
-            });
-
-            // The default lifecycle is Transient
-            container.Model.For<IWidget>().Default
-                .Lifecycle.ShouldBeOfType<TransientLifecycle>();
-
-            // Override at the Family
-            container.Model.For<Rule>().Lifecycle.ShouldBeOfType<SingletonLifecycle>();
-            container.Model.For<Rule>().Find("C").Lifecycle.ShouldBeOfType<SingletonLifecycle>();
-
-            // 'C' is the default lifecycle for Rule (SingletonThing)
-            container.GetInstance<Rule>("C")
-                .ShouldBeTheSameAs(container.GetInstance<Rule>("C"));
-
-            // 'A' is a transient
-            container.GetInstance<Rule>("A")
-                .ShouldNotBeTheSameAs(container.GetInstance<Rule>("A"));
-
-            using (var nested = container.GetNestedContainer())
-            {
-                // 'B' is always unique
-                nested.GetInstance<Rule>("B")
-                    .ShouldNotBeTheSameAs(nested.GetInstance<Rule>("B"));
-            }
-        }
-
-

Using Attributes

New in StructureMap 4.0 are some simple attributes to mark either a complete Plugin Type or a single Instance as either -a singleton or using the always unique lifecycle:

The usage is shown below:


-    [AlwaysUnique]
-    public interface IShouldBeUnique { }
-
-    [Singleton] // because the most wonderful thing about Tiggers is that I'm the only one....
-    public class Tigger { }
-
-

See Using Attributes for Configuration for information about adding your own custom attibutes for other lifecycles.

- + + +

Unless designated otherwise, StructureMap uses Transient as the default scope for all configured Instance's.

The resolution of the lifecycle for any given Instance is to check:

Use the explicitly configured lifecycle for the Instance
If no lifecycle is configured for the Instance, use the explicitly configured lifecycle for the Plugin Type
If no lifecycle is configured for either the Instance or the Plugin Type, use the default Transient lifecycle

The lifecycle precedence rules and the syntax for configuring object lifecycles are shown below:


[Fact]
public void lifecycle_precedence()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Use<AWidget>();

        // Configure the default lifecycle for
        // a PluginType (Rule)
        x.For<Rule>().Singleton();
        x.For<Rule>().Add<ARule>().Named("C");

        // Configure the lifecycle for a single Instance
        x.For<Rule>().Add<ARule>().Named("A").Transient();
        x.For<Rule>().Add<ARule>().Named("B").AlwaysUnique();
    });

    // The default lifecycle is Transient
    container.Model.For<IWidget>().Default
        .Lifecycle.ShouldBeOfType<TransientLifecycle>();

    // Override at the Family
    container.Model.For<Rule>().Lifecycle.ShouldBeOfType<SingletonLifecycle>();
    container.Model.For<Rule>().Find("C").Lifecycle.ShouldBeOfType<SingletonLifecycle>();

    // 'C' is the default lifecycle for Rule (SingletonThing)
    container.GetInstance<Rule>("C")
        .ShouldBeTheSameAs(container.GetInstance<Rule>("C"));

    // 'A' is a transient
    container.GetInstance<Rule>("A")
        .ShouldNotBeTheSameAs(container.GetInstance<Rule>("A"));

    using (var nested = container.GetNestedContainer())
    {
        // 'B' is always unique
        nested.GetInstance<Rule>("B")
            .ShouldNotBeTheSameAs(nested.GetInstance<Rule>("B"));
    }
}

Using Attributes

New in StructureMap 4.0 are some simple attributes to mark either a complete Plugin Type or a single Instance as either +a singleton or using the always unique lifecycle:

The usage is shown below:


[AlwaysUnique]
public interface IShouldBeUnique { }

[Singleton] // because the most wonderful thing about Tiggers is that I'm the only one....
public class Tigger { }

See Using Attributes for Configuration for information about adding your own custom attibutes for other lifecycles.

@@ -88,53 +88,13 @@

Custom Lifecycles - - -

Lifecycle's in StructureMap are pluggable. To create your own custom lifecycle, make an implementation of the ILifecycle interface like this one:


-    public class CustomLifecycle : ILifecycle
-    {
-        public static LifecycleObjectCache Cache = new LifecycleObjectCache();
-
-        public string Description
-        {
-            get { return "Custom"; }
-        }
-
-        public void EjectAll(ILifecycleContext context)
-        {
-            // Here you'd remove all the existing objects
-            // from the cache and call IDisposable.Dispose()
-            // as appropriate
-        }
-
-        public IObjectCache FindCache(ILifecycleContext context)
-        {
-            // using the context, "find" the appropriate
-            // IObjectCache object
-            return Cache;
-        }
-    }
-
-

Registering your custom lifecycle can be done like this:


-    public class UsingCustomLifecycle : Registry
-    {
-        public UsingCustomLifecycle()
-        {
-            // at the Plugin Type level
-            For<IService>().LifecycleIs<CustomLifecycle>();
-
-            // at the Instance level
-            For<IService>().Use<AService>()
-                .LifecycleIs<CustomLifecycle>();
-        }
-    }
-
-

Most of the built in ILifecycle implementations use LifecycleObjectCache internally, but you may also need to create your own IObjectCache implementation.

- + + +

Lifecycles in StructureMap are pluggable. To create your own custom lifecycle, make an implementation of the ILifecycle interface like this one:


public class CustomLifecycle : ILifecycle
{
    public static LifecycleObjectCache Cache = new LifecycleObjectCache();

    public string Description
    {
        get { return "Custom"; }
    }

    public void EjectAll(ILifecycleContext context)
    {
        // Here you'd remove all the existing objects
        // from the cache and call IDisposable.Dispose()
        // as appropriate
    }

    public IObjectCache FindCache(ILifecycleContext context)
    {
        // using the context, "find" the appropriate
        // IObjectCache object
        return Cache;
    }
}

Registering your custom lifecycle can be done like this:


public class UsingCustomLifecycle : Registry
{
    public UsingCustomLifecycle()
    {
        // at the Plugin Type level
        For<IService>().LifecycleIs<CustomLifecycle>();

        // at the Instance level
        For<IService>().Use<AService>()
            .LifecycleIs<CustomLifecycle>();
    }
}

Most of the built in ILifecycle implementations use LifecycleObjectCache internally, but you may also need to create your own IObjectCache implementation.

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index cf8d60f..945facd 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -31,7 +31,7 @@

@@ -88,67 +88,26 @@

Object Lifecycles - - -
One of the most valuable functions of using an IoC container tool is its ability to manage the object lifecycle (creating and disposing objects) and scoping (shared objects) -of your system's services so you can focus on the actual functionality instead of busy work.
-
Some services like data cache's and event aggregators in your system will need to be shared across requests, screens, and handlers. -Other services should be created new every time you ask the container for one. Another set of services need to be scoped to an HTTP request or a logical transaction such that -every request to the container for a service originating within the context of a single HTTP request gets the same object instance.
-
In all the cases above, StructureMap will assemble object graphs for you using the correct scoping of each dependency. Likewise, in some cases, StructureMap can help you -with object cleanup by calling `IDisposable.Dispose()` as appropriate when an object lifecyle is completed.
-
StructureMap isn't magic, you'll still need to be cognizant of the need for object cleanup. See the section on for more guidance.
-

Motivation for Container Managed Scope

In the bad old days, we used the infamous Singleton pattern -as shown below for objects that really needed to be scoped as one single instance for the entire system:


-    public class EvilSingleton
-    {
-        public static readonly EvilSingleton Instance = new EvilSingleton();
-
-        private EvilSingleton()
-        {
-        }
-
-        public void DoSomething()
-        {
-            // do something with the static data here
-        }
-    }
-
-
-    public class EvilSingletonUser
-    {
-        public void DoWork()
-        {
-            EvilSingleton.Instance.DoSomething();
-        }
-    }
-
-

The code above isn't terribly difficult to write or understand, but using a Singleton has some negative effects on your code as explained in Singletons are Evil and my own writing at Chill out on the Singleton Fetish.

Instead, let's just use StructureMap to handle the singleton scoping instead and rewrite the code sample above as:


-    public class SingletonService { }
-
-    public class SingletonUser
-    {
-        public SingletonUser(SingletonService singleton)
-        {
-        }
-    }
-
-    public class SingletonScopeRegistry : Registry
-    {
-        public SingletonScopeRegistry()
-        {
-            For<SingletonService>().Singleton();
-        }
-    }
-

The big advantage to the second, StructureMap-managed singleton scoping is that my DependencyUser class does not have to have any knowledge of -how the ISingletonDependency object is built and certainly no coupling to the hard Singleton mechanics from the first sample that was so harmful in the past.

- + + +

One of the most valuable functions of using an IoC container tool is its ability to manage the object lifecycle (creating and disposing objects) and scoping (shared objects) +of your system's services so you can focus on the actual functionality instead of busy work.

Some services like data cache's and event aggregators in your system will need to be shared across requests, screens, and handlers. +Other services should be created new every time you ask the container for one. Another set of services need to be scoped to an HTTP request or a logical transaction such that +every request to the container for a service originating within the context of a single HTTP request gets the same object instance.

In all the cases above, StructureMap will assemble object graphs for you using the correct scoping of each dependency. Likewise, in some cases, StructureMap can help you +with object cleanup by calling IDisposable.Dispose() as appropriate when an object lifecyle is completed.

StructureMap isn't magic, you'll still need to be cognizant of the need for object cleanup. See the section on Best Practices for more guidance.

+ +

Motivation for Container Managed Scope

In the bad old days, we used the infamous Singleton pattern +as shown below for objects that really needed to be scoped as one single instance for the entire system:


public class EvilSingleton
{
    public static readonly EvilSingleton Instance = new EvilSingleton();

    private EvilSingleton()
    {
    }

    public void DoSomething()
    {
        // do something with the static data here
    }
}


public class EvilSingletonUser
{
    public void DoWork()
    {
        EvilSingleton.Instance.DoSomething();
    }
}

Instead, let's just use StructureMap to handle the singleton scoping instead and rewrite the code sample above as:


public class SingletonService { }

public class SingletonUser
{
    public SingletonUser(SingletonService singleton)
    {
    }
}

public class SingletonScopeRegistry : Registry
{
    public SingletonScopeRegistry()
    {
        For<SingletonService>().Singleton();
    }
}

The big advantage to the second, StructureMap-managed singleton scoping is that my DependencyUser class does not have to have any knowledge of +how the ISingletonDependency object is built and certainly no coupling to the hard Singleton mechanics from the first sample that was so harmful in the past.

@@ -88,407 +88,63 @@

Supported Lifecycles - - -

Out of the box, the core StructureMap assembly supports these lifecycles:

Transient -- The default lifecycle. A new object is created for each logical request to resolve an object graph from the container.
Singleton -- Only one object instance will be created for the container and any children or nested containers created by that container
ContainerScoped -- Only one object instance will be created for unique root, child, or nested container
AlwaysUnique -- A new object instance is created every time, even within the same object graph
ThreadLocal -- Only one object instance will be created for the currently executing Thread

Transient

Older versions of StructureMap referred to Transient as PerRequest, which might be a more accurate reflection of how this lifecycle behaves but -causes some confusion with ASP.Net HTTP scoping. The easiest way to think of Transient is that a single object instance will be created for each top level -call to Container.GetInstance() (or any other object resolution method on the IContainer interface). Transient objects resolved from a nested container, Transient's are scoped to the lifecycle -of the nested container itself. See Nested Containers (Per Request/Transaction) for more information.

StructureMap's behavior for transient objects that implement IDisposable changed in 4.0 to introduce an "opt-in" tracking mode. Please see StructureMap and IDisposable for the details.

The following unit test demonstrates how Transient lifecycles work in both root and nested containers.


-        [Fact]
-        public void Transient()
-        {
-            var c = new Container(x => { x.For<IService>().Use<Service>().Transient(); });
-
-            // In a normal container, you get a new object
-            // instance of the Service class in subsequent
-            // requests
-            c.GetInstance<IService>()
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>())
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>());
-
-            // Within a nested container, 'Transient' now
-            // means within the Nested Container.
-            // A nested container is effectively one request
-            using (var nested = c.GetNestedContainer())
-            {
-                nested.GetInstance<IService>()
-                    .ShouldBeTheSameAs(nested.GetInstance<IService>())
-                    .ShouldBeTheSameAs(nested.GetInstance<IService>());
-            }
-        }
-
-

Also note that a transient dependency will -be created exactly once in an object graph resolved from IContainer.GetInstance(Type). Imagine that you are building an -object graph with various objects that all need to apply some work to a shared unit of work object (think NHibernate's ISession, Entity Framework's DbContext, RavenDb's IDocumentSession):


-        public interface IUnitOfWork
-        {
-        }
-
-        public class DefaultUnitOfWork : IUnitOfWork
-        {
-        }
-
-        public class Worker1
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker1(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class Worker2
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker2(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class WorkerCoordinator
-        {
-            public IUnitOfWork Uow { get; set; }
-            public Worker1 Worker1 { get; set; }
-            public Worker2 Worker2 { get; set; }
-
-            public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
-            {
-                Uow = uow;
-                Worker1 = worker1;
-                Worker2 = worker2;
-            }
-        }
-
-        [Fact]
-        public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
-        {
-            var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });
-
-            var coordinator = container.GetInstance<WorkerCoordinator>();
-
-            // The IUnitOfWork object instance is the same for
-            // all the objects in the object graph that had
-            // a constructor dependency on IUnitOfWork
-            coordinator.Uow
-                .ShouldBeTheSameAs(coordinator.Worker1.Uow);
-
-            coordinator.Uow
-                .ShouldBeTheSameAs(coordinator.Worker2.Uow);
-
-            coordinator.Worker1.Uow
-                .ShouldBeTheSameAs(coordinator.Worker2.Uow);
-        }
-
-

AlwaysUnique

Very simply, using the AlwaysUnique means that a new object instance will be created every single time a configured Instance is either requested -from a Container or as a dependency to another object. The AlwaysUnique lifecycle is a "fire and forget" operation as the object instances are neither tracked nor disposed by StructureMap.

The StructureMap team strongly feels that the default lifecycle is appropriate in most cases and that the unique -lifecycle is mostly useful for logging services as demonstrated in the StructureMap 3.1 announcement.


-        [Fact]
-        public void Always_Unique()
-        {
-            var c = new Container(x => { x.For<IService>().Use<Service>().AlwaysUnique(); });
-
-            // In a normal container, you get a new object
-            // instance of the Service class in subsequent
-            // requests
-            c.GetInstance<IService>()
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>())
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>());
-
-            // Within a nested container, 'Transient' now
-            // means within the Nested Container.
-            // A nested container is effectively one request
-            using (var nested = c.GetNestedContainer())
-            {
-                nested.GetInstance<IService>()
-                    .ShouldNotBeTheSameAs(nested.GetInstance<IService>())
-                    .ShouldNotBeTheSameAs(nested.GetInstance<IService>());
-            }
-
-            // Even in a single request,
-            var holder = c.GetInstance<ServiceUserHolder>();
-            holder.Service.ShouldNotBeTheSameAs(holder.User.Service);
-        }
-
-

Singleton

StructureMap 3.0 fixed the dreaded singletons with nested container's bug that was so problematic in 2.6.


-        [Fact]
-        public void singletons_are_disposed_when_the_container_is_disposed()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForSingletonOf<DisposableSingleton>();
-            });
-
-            // As a singleton-scoped object, every request for DisposableSingleton
-            // will return the same object
-            var singleton = container.GetInstance<DisposableSingleton>();
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-
-            singleton.WasDisposed.ShouldBeFalse();
-
-            // now, dispose the Container
-            container.Dispose();
-
-            // the SingletonThing scoped object should be disposed
-            singleton.WasDisposed.ShouldBeTrue();
-        }
-
-

Do note that objects created as the singleton scope will be disposed when the Container is disposed if they -implement the IDisposable interface:


-        public interface IUnitOfWork
-        {
-        }
-
-        public class DefaultUnitOfWork : IUnitOfWork
-        {
-        }
-
-        public class Worker1
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker1(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class Worker2
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker2(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class WorkerCoordinator
-        {
-            public IUnitOfWork Uow { get; set; }
-            public Worker1 Worker1 { get; set; }
-            public Worker2 Worker2 { get; set; }
-
-            public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
-            {
-                Uow = uow;
-                Worker1 = worker1;
-                Worker2 = worker2;
-            }
-        }
-
-        [Fact]
-        public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
-        {
-            var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });
-
-            var coordinator = container.GetInstance<WorkerCoordinator>();
-
-            // The IUnitOfWork object instance is the same for
-            // all the objects in the object graph that had
-            // a constructor dependency on IUnitOfWork
-            coordinator.Uow
-                .ShouldBeTheSameAs(coordinator.Worker1.Uow);
-
-            coordinator.Uow
-                .ShouldBeTheSameAs(coordinator.Worker2.Uow);
-
-            coordinator.Worker1.Uow
-                .ShouldBeTheSameAs(coordinator.Worker2.Uow);
-        }
-
-

ContainerScoped

New in StructureMap 4.0 is the ContainerScoped lifecycle that was designed specifically for compliance with the new ASP.Net DNX adapter model. -ContainerScoped in this case means that a registration will be built once per Container, such that the root container, any child or profile -container, and every single nested container will build its own object instance.

The acceptance test for ContainerScoped is shown below:


-        [Fact]
-        public void container_scoping_with_root_child_and_nested_container()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForConcreteType<Disposable>().Configure.ContainerScoped();
-            });
-
-            var child = container.CreateChildContainer();
-
-            var nested = container.GetNestedContainer();
-
-            // Always the same object when requested from the root container
-            var mainDisposable = container.GetInstance<Disposable>();
-            mainDisposable
-                .ShouldBeTheSameAs(container.GetInstance<Disposable>());
-
-            // Always the same object when requested from a child container
-            var childDisposable = child.GetInstance<Disposable>();
-            childDisposable
-                .ShouldBeTheSameAs(child.GetInstance<Disposable>());
-
-            // Always the same object when requested from a nested container
-            var nestedDisposable = nested.GetInstance<Disposable>();
-            nestedDisposable
-                .ShouldBeTheSameAs(nested.GetInstance<Disposable>());
-
-            // It should be a different object instance for
-            // all three containers
-            mainDisposable
-                .ShouldNotBeTheSameAs(childDisposable);
-
-            mainDisposable
-                .ShouldNotBeTheSameAs(nestedDisposable);
-
-            childDisposable
-                .ShouldNotBeTheSameAs(nestedDisposable);
-
-            // When the nested container is disposed,
-            // it should dispose all the container scoped objects,
-            // but not impact the other containers
-            nested.Dispose();
-            nestedDisposable.WasDisposed.ShouldBeTrue();
-            childDisposable.WasDisposed.ShouldBeFalse();
-            mainDisposable.WasDisposed.ShouldBeFalse();
-
-            // Same for the child container
-            child.Dispose();
-            childDisposable.WasDisposed.ShouldBeTrue();
-            mainDisposable.WasDisposed.ShouldBeFalse();
-
-            // Same for the main container
-            container.Dispose();
-            mainDisposable.WasDisposed.ShouldBeTrue();
-        }
-
-

ThreadLocal

The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test:


-
-    public class ThreadLocalStorageLifecycleTester
-    {
-        public ThreadLocalStorageLifecycleTester()
-        {
-            _lifecycle = new ThreadLocalStorageLifecycle();
-
-            container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red")));
-        }
-
-        private ThreadLocalStorageLifecycle _lifecycle;
-        private ColorRule _rule1;
-        private ColorRule _rule2;
-        private ColorRule _rule3;
-        private Container container;
-
-        private void findRule1()
-        {
-            _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-
-            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule1.ShouldBeTheSameAs(rule);
-        }
-
-        private void findRule2()
-        {
-            _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-
-            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule2.ShouldBeTheSameAs(rule);
-        }
-
-        private void findRule3()
-        {
-            _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-
-            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-
-            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-
-            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-
-            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-        }
-
-        [Fact]
-        public void object_has_been_created()
-        {
-            container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse();
-            var r1 = container.GetInstance<Rule>();
-            container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue();
-        }
-
-        [Fact]
-        public void FindUniqueInstancePerThread()
-        {
-            var t1 = new Thread(findRule1);
-            var t2 = new Thread(findRule2);
-            var t3 = new Thread(findRule3);
-
-            t1.Start();
-            t2.Start();
-            t3.Start();
-
-            t1.Join();
-            t2.Join();
-            t3.Join();
-
-            _rule1.ShouldNotBeTheSameAs(_rule2);
-            _rule1.ShouldNotBeTheSameAs(_rule3);
-            _rule2.ShouldNotBeTheSameAs(_rule3);
-            (_rule1.ID != _rule2.ID).ShouldBeTrue();
-            (_rule1.ID != _rule3.ID).ShouldBeTrue();
-            (_rule2.ID != _rule3.ID).ShouldBeTrue();
-        }
-    }
-
-

Legacy ASP.Net Lifecycles

The StructureMap team strongly recommends against using the old ASP.Net lifecycles. Most modern web frameworks in .Net will use a Nested Container per request to accomplish the same scoping in a better way.

In addition, the StructureMap.Web package adds the legacy ASP.Net related lifecycles for:

HttpContext
HttpSession (requires objects to be Serializable, not recommended but still present for legacy code
Hybrid -- uses ThreadLocalStorage in the absence of an active HttpContext
HybridSession

Missing code sample 'AspNet-Lifecycles' -- Wait for ST to catch up reading samples or CTRL+SHIFT+R to force refresh

If you do use any of the HttpContext lifecycles, make sure you also do:

Missing code sample 'clean-up-http-context' -- Wait for ST to catch up reading samples or CTRL+SHIFT+R to force refresh

at the end of your HTTP request.

- + + +

Out of the box, the core StructureMap assembly supports these lifecycles:

Transient -- The default lifecycle. A new object is created for each logical request to resolve an object graph from the container.
Singleton -- Only one object instance will be created for the container and any children or nested containers created by that container
ContainerScoped -- Only one object instance will be created for unique root, child, or nested container
AlwaysUnique -- A new object instance is created every time, even within the same object graph
ThreadLocal -- Only one object instance will be created for the currently executing Thread

Transient

Older versions of StructureMap referred to Transient as PerRequest, which might be a more accurate reflection of how this lifecycle behaves but +causes some confusion with ASP.Net HTTP scoping. The easiest way to think of Transient is that a single object instance will be created for each top level +call to Container.GetInstance() (or any other object resolution method on the IContainer interface). Transient objects resolved from a nested container, Transient's are scoped to the lifecycle +of the nested container itself. See Nested Containers (Per Request/Transaction) for more information.

StructureMap's behavior for transient objects that implement IDisposable changed in 4.0 to introduce an "opt-in" tracking mode. Please see StructureMap and IDisposable for the details.

The following unit test demonstrates how Transient lifecycles work in both root and nested containers.


[Fact]
public void Transient()
{
    var c = new Container(x => { x.For<IService>().Use<Service>().Transient(); });

    // In a normal container, you get a new object
    // instance of the Service class in subsequent
    // requests
    c.GetInstance<IService>()
        .ShouldNotBeTheSameAs(c.GetInstance<IService>())
        .ShouldNotBeTheSameAs(c.GetInstance<IService>());

    // Within a nested container, 'Transient' now
    // means within the Nested Container.
    // A nested container is effectively one request
    using (var nested = c.GetNestedContainer())
    {
        nested.GetInstance<IService>()
            .ShouldBeTheSameAs(nested.GetInstance<IService>())
            .ShouldBeTheSameAs(nested.GetInstance<IService>());
    }
}

Also note that a transient dependency will +be created exactly once in an object graph resolved from IContainer.GetInstance(Type). Imagine that you are building an +object graph with various objects that all need to apply some work to a shared unit of work object (think NHibernate's ISession, Entity Framework's DbContext, RavenDb's IDocumentSession):


public interface IUnitOfWork
{
}

public class DefaultUnitOfWork : IUnitOfWork
{
}

public class Worker1
{
    public IUnitOfWork Uow { get; set; }

    public Worker1(IUnitOfWork uow)
    {
        Uow = uow;
    }
}

public class Worker2
{
    public IUnitOfWork Uow { get; set; }

    public Worker2(IUnitOfWork uow)
    {
        Uow = uow;
    }
}

public class WorkerCoordinator
{
    public IUnitOfWork Uow { get; set; }
    public Worker1 Worker1 { get; set; }
    public Worker2 Worker2 { get; set; }

    public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
    {
        Uow = uow;
        Worker1 = worker1;
        Worker2 = worker2;
    }
}

[Fact]
public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
{
    var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });

    var coordinator = container.GetInstance<WorkerCoordinator>();

    // The IUnitOfWork object instance is the same for
    // all the objects in the object graph that had
    // a constructor dependency on IUnitOfWork
    coordinator.Uow
        .ShouldBeTheSameAs(coordinator.Worker1.Uow);

    coordinator.Uow
        .ShouldBeTheSameAs(coordinator.Worker2.Uow);

    coordinator.Worker1.Uow
        .ShouldBeTheSameAs(coordinator.Worker2.Uow);
}

AlwaysUnique

Very simply, using the AlwaysUnique means that a new object instance will be created every single time a configured Instance is either requested +from a Container or as a dependency to another object. The AlwaysUnique lifecycle is a "fire and forget" operation as the object instances are neither tracked nor disposed by StructureMap.

The StructureMap team strongly feels that the default lifecycle is appropriate in most cases and that the unique +lifecycle is mostly useful for logging services as demonstrated in the StructureMap 3.1 announcement.


[Fact]
public void Always_Unique()
{
    var c = new Container(x => { x.For<IService>().Use<Service>().AlwaysUnique(); });

    // In a normal container, you get a new object
    // instance of the Service class in subsequent
    // requests
    c.GetInstance<IService>()
        .ShouldNotBeTheSameAs(c.GetInstance<IService>())
        .ShouldNotBeTheSameAs(c.GetInstance<IService>());

    // Within a nested container, 'Transient' now
    // means within the Nested Container.
    // A nested container is effectively one request
    using (var nested = c.GetNestedContainer())
    {
        nested.GetInstance<IService>()
            .ShouldNotBeTheSameAs(nested.GetInstance<IService>())
            .ShouldNotBeTheSameAs(nested.GetInstance<IService>());
    }

    // Even in a single request,
    var holder = c.GetInstance<ServiceUserHolder>();
    holder.Service.ShouldNotBeTheSameAs(holder.User.Service);
}

Singleton

StructureMap 3.0 fixed the dreaded singletons with nested container's bug that was so problematic in 2.6.


[Fact]
public void singletons_are_disposed_when_the_container_is_disposed()
{
    var container = new Container(_ =>
    {
        _.ForSingletonOf<DisposableSingleton>();
    });

    // As a singleton-scoped object, every request for DisposableSingleton
    // will return the same object
    var singleton = container.GetInstance<DisposableSingleton>();
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());

    singleton.WasDisposed.ShouldBeFalse();

    // now, dispose the Container
    container.Dispose();

    // the SingletonThing scoped object should be disposed
    singleton.WasDisposed.ShouldBeTrue();
}

Do note that objects created as the singleton scope will be disposed when the Container is disposed if they +implement the IDisposable interface:


public interface IUnitOfWork
{
}

public class DefaultUnitOfWork : IUnitOfWork
{
}

public class Worker1
{
    public IUnitOfWork Uow { get; set; }

    public Worker1(IUnitOfWork uow)
    {
        Uow = uow;
    }
}

public class Worker2
{
    public IUnitOfWork Uow { get; set; }

    public Worker2(IUnitOfWork uow)
    {
        Uow = uow;
    }
}

public class WorkerCoordinator
{
    public IUnitOfWork Uow { get; set; }
    public Worker1 Worker1 { get; set; }
    public Worker2 Worker2 { get; set; }

    public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
    {
        Uow = uow;
        Worker1 = worker1;
        Worker2 = worker2;
    }
}

[Fact]
public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
{
    var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });

    var coordinator = container.GetInstance<WorkerCoordinator>();

    // The IUnitOfWork object instance is the same for
    // all the objects in the object graph that had
    // a constructor dependency on IUnitOfWork
    coordinator.Uow
        .ShouldBeTheSameAs(coordinator.Worker1.Uow);

    coordinator.Uow
        .ShouldBeTheSameAs(coordinator.Worker2.Uow);

    coordinator.Worker1.Uow
        .ShouldBeTheSameAs(coordinator.Worker2.Uow);
}

ContainerScoped

New in StructureMap 4.0 is the ContainerScoped lifecycle that was designed specifically for compliance with the new ASP.Net DNX adapter model. +ContainerScoped in this case means that a registration will be built once per Container, such that the root container, any child or profile +container, and every single nested container will build its own object instance.

The acceptance test for ContainerScoped is shown below:


[Fact]
public void container_scoping_with_root_child_and_nested_container()
{
    var container = new Container(_ =>
    {
        _.ForConcreteType<Disposable>().Configure.ContainerScoped();
    });

    var child = container.CreateChildContainer();

    var nested = container.GetNestedContainer();

    // Always the same object when requested from the root container
    var mainDisposable = container.GetInstance<Disposable>();
    mainDisposable
        .ShouldBeTheSameAs(container.GetInstance<Disposable>());

    // Always the same object when requested from a child container
    var childDisposable = child.GetInstance<Disposable>();
    childDisposable
        .ShouldBeTheSameAs(child.GetInstance<Disposable>());

    // Always the same object when requested from a nested container
    var nestedDisposable = nested.GetInstance<Disposable>();
    nestedDisposable
        .ShouldBeTheSameAs(nested.GetInstance<Disposable>());

    // It should be a different object instance for
    // all three containers
    mainDisposable
        .ShouldNotBeTheSameAs(childDisposable);

    mainDisposable
        .ShouldNotBeTheSameAs(nestedDisposable);

    childDisposable
        .ShouldNotBeTheSameAs(nestedDisposable);

    // When the nested container is disposed,
    // it should dispose all the container scoped objects,
    // but not impact the other containers
    nested.Dispose();
    nestedDisposable.WasDisposed.ShouldBeTrue();
    childDisposable.WasDisposed.ShouldBeFalse();
    mainDisposable.WasDisposed.ShouldBeFalse();

    // Same for the child container
    child.Dispose();
    childDisposable.WasDisposed.ShouldBeTrue();
    mainDisposable.WasDisposed.ShouldBeFalse();

    // Same for the main container
    container.Dispose();
    mainDisposable.WasDisposed.ShouldBeTrue();
}

ThreadLocal

The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test:



public class ThreadLocalStorageLifecycleTester
{
    public ThreadLocalStorageLifecycleTester()
    {
        _lifecycle = new ThreadLocalStorageLifecycle();

        container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red")));
    }

    private ThreadLocalStorageLifecycle _lifecycle;
    private ColorRule _rule1;
    private ColorRule _rule2;
    private ColorRule _rule3;
    private Container container;

    private void findRule1()
    {
        _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();

        var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
        _rule1.ShouldBeTheSameAs(rule);
    }

    private void findRule2()
    {
        _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();

        var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
        _rule2.ShouldBeTheSameAs(rule);
    }

    private void findRule3()
    {
        _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();

        var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
        _rule3.ShouldBeTheSameAs(rule);

        rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
        _rule3.ShouldBeTheSameAs(rule);

        rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
        _rule3.ShouldBeTheSameAs(rule);

        rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
        _rule3.ShouldBeTheSameAs(rule);
    }

    [Fact]
    public void object_has_been_created()
    {
        container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse();
        var r1 = container.GetInstance<Rule>();
        container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue();
    }

    [Fact]
    public void FindUniqueInstancePerThread()
    {
        var t1 = new Thread(findRule1);
        var t2 = new Thread(findRule2);
        var t3 = new Thread(findRule3);

        t1.Start();
        t2.Start();
        t3.Start();

        t1.Join();
        t2.Join();
        t3.Join();

        _rule1.ShouldNotBeTheSameAs(_rule2);
        _rule1.ShouldNotBeTheSameAs(_rule3);
        _rule2.ShouldNotBeTheSameAs(_rule3);
        (_rule1.ID != _rule2.ID).ShouldBeTrue();
        (_rule1.ID != _rule3.ID).ShouldBeTrue();
        (_rule2.ID != _rule3.ID).ShouldBeTrue();
    }
}

Legacy ASP.Net Lifecycles

+ +

In addition, the StructureMap.Web package adds the legacy ASP.Net related lifecycles for:

HttpContext
HttpSession (requires objects to be Serializable, not recommended but still present for legacy code
Hybrid -- uses ThreadLocalStorage in the absence of an active HttpContext
HybridSession

Missing code sample 'AspNet-Lifecycles' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

If you do use any of the HttpContext lifecycles, make sure you also do:

Missing code sample 'clean-up-http-context' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

at the end of your HTTP request.

@@ -88,103 +88,45 @@

A Gentle Quickstart - - -
The first thing you should know is that StructureMap (and other IoC tools like it) are designed to -make compositional and modular software designs easier to build by offloading the grubby mechanics of -resolving dependencies, reading configuration data, and assembling object graphs to the IoC tool instead -of cluttering up your application code.
-
Before you get started with StructureMap it's recommended that you first get comfortable with the Software Design Concepts -of Dependency Injection -and Inversion Of Control. -It's important that you structure and build your application with these concepts in mind to fully utilize StructureMap's abilities.
-
Assuming that you're already familiar with those concepts, or you'd really rather skip the pedantry and jump right into concrete code, the first thing to do is, go Get StructureMap and jump into usage.
-

Main Usage

By and large, you really only do two kinds of things with StructureMap:

-
Configure the container by registering the what and how StructureMap should build or find requested services based on a type and/or name.
-
-
Resolve object instances of a service or dependency built out with all of its dependencies.
-

So let's say that you have a simple object model like so:


-    public interface IBar
-    {
-    }
-
-    public class Bar : IBar
-    {
-    }
-
-    public interface IFoo
-    {
-    }
-
-    public class Foo : IFoo
-    {
-        public IBar Bar { get; private set; }
-
-        public Foo(IBar bar)
-        {
-            Bar = bar;
-        }
-    }
-
-

You could explicitly build a StructureMap Container object to build these types like this:


-// Configure and build a brand new
-// StructureMap Container object
-            var container = new Container(_ =>
-            {
-                _.For<IFoo>().Use<Foo>();
-                _.For<IBar>().Use<Bar>();
-            });
-
-// Now, resolve a new object instance of IFoo
-            container.GetInstance<IFoo>()
-                // should be type Foo
-                .ShouldBeOfType<Foo>()
-
-                // and the IBar dependency too
-                .Bar.ShouldBeOfType<Foo>();
-
-
-

or utilize StructureMap's type scanning conventions to configure the relationships and do the same thing like this:


-            var container = new Container(_ =>
-            {
-                _.Scan(x =>
-                {
-                    x.TheCallingAssembly();
-                    x.WithDefaultConventions();
-                });
-            });
-
-            container.GetInstance<IFoo>()
-                .ShouldBeOfType<Foo>()
-                .Bar.ShouldBeOfType<Foo>();
-
-

Integrating StructureMap within your application

At some point you will want to integrate StructureMap into your application. Whether you are using Windows Presentation Foundation (WPF), FubuMVC, ASP.NET WebForms, ASP.NET MVC or any other framework or technology, you will have to do some sort of plumbing and bootstrapping. Depending on the used technology or framework there can be important integration points that you will have to use to fully enable the power of StructureMap.

While StructureMap doesn't provide integration support out of the box for all of the frameworks and technologies out there, we do find it important to help you get started with integrating StructureMap into your application. That said, StructureMap does provide integration support for FubuMVC (a web framework, which is part of the same family as StructureMap).

What to do when things go wrong?

StructureMap, and any other IoC tool for that matter, is configuration intensive, which means that their will be problems in that configuration. We're all moving to more convention based type registration, so more stuff is happening off stage and out of your sight, making debugging the configuration even trickier. Not to worry (too much), StructureMap has some diagnostic abilities to help you solve configuration problems:

Interpreting Exceptions
Diagnostics

Need Help?

There is a google group for StructureMap support.
You can ask questions on StackOverflow with the tag "structuremap."

- + + +

The first thing you should know is that StructureMap (and other IoC tools like it) are designed to +make compositional and modular software designs easier to build by offloading the grubby mechanics of +resolving dependencies, reading configuration data, and assembling object graphs to the IoC tool instead +of cluttering up your application code.

Before you get started with StructureMap it's recommended that you first get comfortable with the Software Design Concepts +of Dependency Injection +and Inversion Of Control. +It's important that you structure and build your application with these concepts in mind to fully utilize StructureMap's abilities.

Assuming that you're already familiar with those concepts, or you'd really rather skip the pedantry and jump right into concrete code, the first thing to do is, go Get StructureMap and jump into usage.

Main Usage

By and large, you really only do two kinds of things with StructureMap:

Configure the container by registering the what and how StructureMap should build or find requested services based on a type and/or name.
+
Resolve object instances of a service or dependency built out with all of its dependencies.
+

So let's say that you have a simple object model like so:


public interface IBar
{
}

public class Bar : IBar
{
}

public interface IFoo
{
}

public class Foo : IFoo
{
    public IBar Bar { get; private set; }

    public Foo(IBar bar)
    {
        Bar = bar;
    }
}

You could explicitly build a StructureMap Container object to build these types like this:


// Configure and build a brand new
// StructureMap Container object
            var container = new Container(_ =>
            {
                _.For<IFoo>().Use<Foo>();
                _.For<IBar>().Use<Bar>();
            });

// Now, resolve a new object instance of IFoo
            container.GetInstance<IFoo>()
                // should be type Foo
                .ShouldBeOfType<Foo>()

                // and the IBar dependency too
                .Bar.ShouldBeOfType<Bar>();

or utilize StructureMap's type scanning conventions to configure the relationships and do the same thing like this:


var container = new Container(_ =>
{
    _.Scan(x =>
    {
        x.TheCallingAssembly();
        x.WithDefaultConventions();
    });
});

container.GetInstance<IFoo>()
    .ShouldBeOfType<Foo>()
    .Bar.ShouldBeOfType<Bar>();

Integrating StructureMap within your application

What to do when things go wrong?

Interpreting Exceptions
Diagnostics

Need Help?

There is a google group for StructureMap support.
You can ask questions on StackOverflow with the tag "structuremap."

@@ -97,48 +97,7 @@

Using Attributes for Configuration - /// <summary> - /// Base class for custom configuration attributes - /// </summary> - public abstract class StructureMapAttribute : Attribute - { - /// <summary> - /// Override this method to apply a configuration change to an entire - /// PluginFamily (every Instance of a certain PluginType) - /// </summary> - /// <param name="family"></param> - public virtual void Alter(PluginFamily family) - { - } - - /// <summary> - /// Make configuration alterations to a single IConfiguredInstance object - /// </summary> - /// <param name="instance"></param> - public virtual void Alter(IConfiguredInstance instance) - { - } - - /// <summary> - /// Apply configuration customization to a single setter property - /// </summary> - /// <param name="instance"></param> - /// <param name="property"></param> - public virtual void Alter(IConfiguredInstance instance, PropertyInfo property) - { - } - - /// <summary> - /// Apply configuration customization for a single constructor parameter - /// </summary> - /// <param name="instance"></param> - /// <param name="parameter"></param> - public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter) - { - } - } - +


/// <summary>
/// Base class for custom configuration attributes
/// </summary>
public abstract class StructureMapAttribute : Attribute
{
    /// <summary>
    /// Override this method to apply a configuration change to an entire
    /// PluginFamily (every Instance of a certain PluginType)
    /// </summary>
    /// <param name="family"></param>
    public virtual void Alter(PluginFamily family)
    {
    }

    /// <summary>
    /// Make configuration alterations to a single IConfiguredInstance object
    /// </summary>
    /// <param name="instance"></param>
    public virtual void Alter(IConfiguredInstance instance)
    {
    }

    /// <summary>
    /// Apply configuration customization to a single setter property
    /// </summary>
    /// <param name="instance"></param>
    /// <param name="property"></param>
    public virtual void Alter(IConfiguredInstance instance, PropertyInfo property)
    {
    }

    /// <summary>
    /// Apply configuration customization for a single constructor parameter
    /// </summary>
    /// <param name="instance"></param>
    /// <param name="parameter"></param>
    public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter)
    {
    }
}

There's a couple thing to note, here about this new attibute:

StructureMap internals are looking for any attribute of the base class. Attributes that affect types are read and applied early, @@ -146,112 +105,22 @@

Using Attributes for Configuration Attribute Targeting Plugin Type or Concrete Type

Take the new [Singleton] attribute shown below:


-    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface)]
-    public class SingletonAttribute : StructureMapAttribute
-    {
-        // This method will affect the configuration for the
-        // entire plugin type
-        public override void Alter(PluginFamily family)
-        {
-            family.SetLifecycleTo<SingletonLifecycle>();
-        }
-
-        // This method will affect single registrations
-        public override void Alter(IConfiguredInstance instance)
-        {
-            instance.SetLifecycleTo<SingletonLifecycle>();
-        }
-    }
-


[AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface)]
public class SingletonAttribute : StructureMapAttribute
{
    // This method will affect the configuration for the
    // entire plugin type
    public override void Alter(PluginFamily family)
    {
        family.SetLifecycleTo<SingletonLifecycle>();
    }

    // This method will affect single registrations
    public override void Alter(IConfiguredInstance instance)
    {
        instance.SetLifecycleTo<SingletonLifecycle>();
    }
}

This new attribute can be used on either the plugin type (typically an interface) or on a concrete type to make an individual type registration be a singleton. You can see the usage on some types below:


-        [Singleton] // ALL Instance's of ITeamCache will be singletons by default
-        public interface ITeamCache { }
-
-        public class TeamCache : ITeamCache { }
-
-        public class OtherTeamCache : ITeamCache { }
-
-        public interface ITeam { }
-
-        public class Chargers : ITeam { }
-
-        [Singleton] // This specific type will be a singleton
-        public class Chiefs : ITeam { }
-
-

Attribute Targeting Constructor Parameters or Setter Properties


[Singleton] // ALL Instance's of ITeamCache will be singletons by default
public interface ITeamCache { }

public class TeamCache : ITeamCache { }

public class OtherTeamCache : ITeamCache { }

public interface ITeam { }

public class Chargers : ITeam { }

[Singleton] // This specific type will be a singleton
public class Chiefs : ITeam { }

Attribute Targeting Constructor Parameters or Setter Properties

As an example, let's say that you want a new attribute type that can decorate either properties or constructor parameters to say "use the value from the old .Net AppSettings collection as the value for this property/parameter." To build that new custom attribute, you would create a new attribute that subclasses StructureMapAttribute and override the two methods shown below:


-        public class AppSettingAttribute : StructureMapAttribute
-        {
-            private readonly string _key;
-
-            public AppSettingAttribute(string key)
-            {
-                _key = key;
-            }
-
-            public override void Alter(IConfiguredInstance instance, PropertyInfo property)
-            {
-                var value = System.Configuration.ConfigurationManager.AppSettings[_key];
-
-                instance.Dependencies.AddForProperty(property, value);
-            }
-
-            public override void Alter(IConfiguredInstance instance, ParameterInfo parameter)
-            {
-                var value = System.Configuration.ConfigurationManager.AppSettings[_key];
-
-                instance.Dependencies.AddForConstructorParameter(parameter, value);
-            }
-        }
-
-


public class AppSettingAttribute : StructureMapAttribute
{
    private readonly string _key;

    public AppSettingAttribute(string key)
    {
        _key = key;
    }

    public override void Alter(IConfiguredInstance instance, PropertyInfo property)
    {
        var value = System.Configuration.ConfigurationManager.AppSettings[_key];

        instance.Dependencies.AddForProperty(property, value);
    }

    public override void Alter(IConfiguredInstance instance, ParameterInfo parameter)
    {
        var value = System.Configuration.ConfigurationManager.AppSettings[_key];

        instance.Dependencies.AddForConstructorParameter(parameter, value);
    }
}

To test out the new attribute above, say we have a concrete type like this one that we decorate with the new [AppSetting] attribute:


-        public class AppSettingTarget
-        {
-            public string Name { get; set; }
-
-            [AppSetting("homestate")]
-            public string HomeState { get; set; }
-
-            public AppSettingTarget([AppSetting("name")]string name)
-            {
-                Name = name;
-            }
-        }
-
-


public class AppSettingTarget
{
    public string Name { get; set; }

    [AppSetting("homestate")]
    public string HomeState { get; set; }

    public AppSettingTarget([AppSetting("name")]string name)
    {
        Name = name;
    }
}

The following unit test demonstrates our new custom [AppSetting] attribute in action:


-        [Fact]
-        public void using_parameter_and_property_attibutes()
-        {
-            System.Configuration.ConfigurationManager.AppSettings["name"] = "Jeremy";
-            System.Configuration.ConfigurationManager.AppSettings["homestate"] = "Missouri";
-
-            System.Configuration.ConfigurationManager.AppSettings["name"].ShouldBe("Jeremy");
-
-            var container = new Container();
-
-            var target = container.GetInstance<AppSettingTarget>();
-
-            target.Name.ShouldBe("Jeremy");
-            target.HomeState.ShouldBe("Missouri");
-
-            Debug.WriteLine(container.Model.For<AppSettingTarget>().Default.DescribeBuildPlan());
-        }
-
-


[Fact]
public void using_parameter_and_property_attibutes()
{
    System.Configuration.ConfigurationManager.AppSettings["name"] = "Jeremy";
    System.Configuration.ConfigurationManager.AppSettings["homestate"] = "Missouri";

    System.Configuration.ConfigurationManager.AppSettings["name"].ShouldBe("Jeremy");

    var container = new Container();

    var target = container.GetInstance<AppSettingTarget>();

    target.Name.ShouldBe("Jeremy");
    target.HomeState.ShouldBe("Missouri");

    Debug.WriteLine(container.Model.For<AppSettingTarget>().Default.DescribeBuildPlan());
}

The build plan for AppSettingTarget is determined by the active StructureMap container to be this:

@@ -264,7 +133,7 @@ Attribute Targeting Constructor Parameters or Setter Properties
 Note that the values retrieved from AppSettings are essentially hard coded into the underlying builder function that StructureMap compiled for
 AppSettingTarget. You could instead add a "lambda builder" dependency so that StructureMap had to
 use the live value for AppSettings as it constructs objects.
-Built In Attributes
+Built In Attributes
 StructureMap supplies a handful of built in attributes for customizing configuration:
 
 [ValidationMethod] - Allows you to expose Environment Tests in your StructureMap registrations
@@ -273,7 +142,6 @@ Built In Attributes
 [AlwaysUnique] and [Singleton] - These attributes, new for StructureMap 4.0, just add another mechanism for lifecycle configuration
 
 
-

@@ -88,364 +88,87 @@

Auto-Registration and Conventions - - -
The type scanning facilities were completely overhauled and greatly optimized for performance as part of the StructureMap 4.0 release. The mechanism for custom registration conventions is somewhat different from 2.5-3.* to 4.0.
-
StructureMap has rich support for registering types by scanning assemblies and applying conventional registrations. -Between scanning and default conventions, configurations are often just a few -lines.
-
Also see Type Scanning Diagnostics for help in understanding the assembly scanning behavior in your system.
-

Registry.Scan()

Assembly scanning operations are defined by the Registry.Scan() method demonstrated below:


-    public class BasicScanning : Registry
-    {
-        public BasicScanning()
-        {
-            Scan(_ =>
-            {
-                // Declare which assemblies to scan
-                _.Assembly("StructureMap.Testing");
-                _.AssemblyContainingType<IWidget>();
-
-                // Filter types
-                _.Exclude(type => type.Name.Contains("Bad"));
-
-                // A custom registration convention
-                _.Convention<MySpecialRegistrationConvention>();
-
-                // Built in registration conventions
-                _.AddAllTypesOf<IWidget>().NameBy(x => x.Name.Replace("Widget", ""));
-                _.WithDefaultConventions();
-            });
-        }
-    }
-

Please note (because I've been asked this several times over the years) that each call to Registry.Scan() is an entirely atomic operation that has no impact on previous or subsequent calls.

Any given call to Registry.Scan() consists of three different things:

One or more assemblies to scan for types
One or more registration conventions
Optionally, set filters to only include certain types or exclude other types from being processed by the scanning operation

Scan the Calling Assembly

One of the easiest ways to register types is by scanning the assembly your -registry is placed in.

Note if you have other registries, StructureMap will not automatically -find them.


-        [Fact]
-        public void scan_but_ignore_registries_by_default()
-        {
-            Scan(x => { x.TheCallingAssembly(); });
-
-            TestingRegistry.WasUsed.ShouldBeFalse();
-        }
-
-

Note that this method is an extension method in the StructureMap.Net4 assembly and cannot be used -if you target PCL compliance.

Scan for Registries

StructureMap can automatically include other registries with theLookForRegistries -method.


-        [Fact]
-        public void Search_for_registries_when_explicitly_told()
-        {
-            Scan(x =>
-            {
-                x.TheCallingAssembly();
-                x.LookForRegistries();
-            });
-
-            TestingRegistry.WasUsed.ShouldBeTrue();
-        }
-
-

As of 4.0, this operation is now recursive and StructureMap has always been idempotent about adding Registry types

Search for Assemblies on the File System

StructureMap provides facilities for registering types by finding assemblies in the application bin path:


-        [Fact]
-        public void scan_all_assemblies_in_a_folder()
-        {
-            Scan(x => x.AssembliesFromPath(assemblyScanningFolder));
-            shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
-            shouldHaveFamilyWithSameName<IWorker>();
-            shouldNotHaveFamilyWithSameName<IDefinedInExe>();
-        }
-
-        [Fact]
-        public void scan_all_assemblies_in_application_base_directory()
-        {
-            Scan(x => x.AssembliesFromApplicationBaseDirectory());
-            shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
-            shouldHaveFamilyWithSameName<IWorker>();
-            shouldNotHaveFamilyWithSameName<IDefinedInExe>();
-        }
-
-

Do note that StructureMap 4.0 does not search for .exe files in the assembly search. The StructureMap team felt this was -problematic and "nobody would ever actually want to do that." We were wrong, and due to many user requests, you can now -opt in to scanning .exe files with a new public method on AssemblyScanner shown below:


-        [Fact]
-        public void scan_all_assemblies_in_a_folder_including_exe()
-        {
-            Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder));
-
-            shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
-            shouldHaveFamilyWithSameName<IWorker>();
-            shouldHaveFamilyWithSameName<IDefinedInExe>();
-        }
-
-
-        [Fact]
-        public void scan_all_assemblies_in_application_base_directory_including_exe()
-        {
-            Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory());
-
-            shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
-            shouldHaveFamilyWithSameName<IWorker>();
-            shouldHaveFamilyWithSameName<IDefinedInExe>();
-        }
-
-

Do be aware that while this technique is very powerful for extensibility, it's been extremely problematic for -some folks in the past. The StructureMap team's recommendation for using this feature is to:

Make sure you have some kind of filter on the assemblies scanned for performance and predictability reasons. Either a naming convention or filter -by an assembly attribute to narrow where StructureMap looks
Get familiar with the new type scanning diagnostics introduced in 4.0;-)

Behind the scenes, StructureMap is using the Assembly.GetExportedTypes() method from the .Net CLR to find types and this -mechanism is very sensitive to missing dependencies. Again, thanks to the new type scanning diagnostics, -you now have some visibility into assembly loading failures that used to be silently swallowed internally.

Excluding Types

StructureMap also makes it easy to exclude types, either individually or by namespace. -The following examples also show how StructureMap can register an assembly by providing -a type within that assembly.

Excluding additional types or namespaces is as easy as calling the corresponding method -again.


-        [Fact]
-        public void use_a_single_exclude_of_type()
-        {
-            Scan(x =>
-            {
-                x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
-                x.ExcludeType<ITypeThatHasAttributeButIsNotInRegistry>();
-            });
-
-            shouldHaveFamily<IInterfaceInWidget5>();
-            shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>();
-        }
-
-        [Fact]
-        public void use_a_single_exclude2()
-        {
-            Scan(x =>
-            {
-                x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
-                x.ExcludeNamespace("StructureMap.Testing.Widget5");
-            });
-
-            shouldNotHaveFamily<IInterfaceInWidget5>();
-            shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>();
-        }
-
-        [Fact]
-        public void use_a_single_exclude3()
-        {
-            Scan(x =>
-            {
-                x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
-                x.ExcludeNamespaceContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
-            });
-
-            shouldNotHaveFamily<IInterfaceInWidget5>();
-            shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>();
-        }
-
-

Custom Registration Conventions

It's just not possible (or desirable) for StructureMap to include every possible type of auto registration -convention users might want, but that's okay because StructureMap allows you to create and use your own -conventions through the IRegistrationConvention interface:


-    public interface IRegistrationConvention
-    {
-        void ScanTypes(TypeSet types, Registry registry);
-    }
-

Let's say that you'd like a custom convention that just registers a concrete type against all the interfaces -that it implements. You could then build a custom IRegistrationConvention class like the following example:


-        public interface IFoo
-        {
-        }
-
-        public interface IBar
-        {
-        }
-
-        public interface IBaz
-        {
-        }
-
-        public class BusyGuy : IFoo, IBar, IBaz
-        {
-        }
-
-        // Custom IRegistrationConvention
-        public class AllInterfacesConvention : IRegistrationConvention
-        {
-            public void ScanTypes(TypeSet types, Registry registry)
-            {
-                // Only work on concrete types
-                types.FindTypes(TypeClassification.Concretes | TypeClassification.Closed).Each(type =>
-                {
-                    // Register against all the interfaces implemented
-                    // by this concrete class
-                    type.GetInterfaces().Each(@interface => registry.For(@interface).Use(type));
-                });
-            }
-        }
-
-        [Fact]
-        public void use_custom_registration_convention()
-        {
-            var container = new Container(_ =>
-            {
-                _.Scan(x =>
-                {
-                    // You're probably going to want to tightly filter
-                    // the Type's that are applicable to avoid unwanted
-                    // registrations
-                    x.TheCallingAssembly();
-                    x.IncludeNamespaceContainingType<BusyGuy>();
-
-                    // Register the custom policy
-                    x.Convention<AllInterfacesConvention>();
-                });
-            });
-
-            container.GetInstance<IFoo>().ShouldBeOfType<BusyGuy>();
-            container.GetInstance<IBar>().ShouldBeOfType<BusyGuy>();
-            container.GetInstance<IBaz>().ShouldBeOfType<BusyGuy>();
-        }
-
-

The Default ISomething/Something Convention

The "default" convention simply tries to connect concrete classes to interfaces using -the I[Something]/[Something] naming convention as shown in this sample:


-        public interface ISpaceship { }
-
-        public class Spaceship : ISpaceship { }
-
-        public interface IRocket { }
-
-        public class Rocket : IRocket { }
-
-        [Fact]
-        public void default_scanning_in_action()
-        {
-            var container = new Container(_ =>
-            {
-                _.Scan(x =>
-                {
-                    x.Assembly("StructureMap.Testing");
-                    x.WithDefaultConventions();
-                });
-            });
-
-            container.GetInstance<ISpaceship>().ShouldBeOfType<Spaceship>();
-            container.GetInstance<IRocket>().ShouldBeOfType<Rocket>();
-        }
-
-

The StructureMap team contains some VB6 veterans who hate Hungarian Notation, but can't shake the "I" nomenclature.

Registering the Single Implementation of an Interface

To tell StructureMap to automatically register any interface that only has one concrete implementation, use this method:


-        public interface ISong { }
-
-        public class TheOnlySong : ISong { }
-
-        [Fact]
-        public void only_implementation()
-        {
-            var container = new Container(_ =>
-            {
-                _.Scan(x =>
-                {
-                    x.TheCallingAssembly();
-                    x.SingleImplementationsOfInterface();
-                });
-            });
-
-            container.GetInstance<ISong>()
-                .ShouldBeOfType<TheOnlySong>();
-        }
-
-

Register all Concrete Types of an Interface

To add all concrete types that can be cast to a named plugin type, use this syntax:


-        public interface IFantasySeries { }
-
-        public class WheelOfTime : IFantasySeries { }
-
-        public class GameOfThrones : IFantasySeries { }
-
-        public class BlackCompany : IFantasySeries { }
-
-        [Fact]
-        public void register_all_types_of_an_interface()
-        {
-            var container = new Container(_ =>
-            {
-                _.Scan(x =>
-                {
-                    x.TheCallingAssembly();
-
-                    x.AddAllTypesOf<IFantasySeries>();
-
-                    // or
-
-                    x.AddAllTypesOf(typeof(IFantasySeries))
-                        .NameBy(type => type.Name.ToLower());
-                });
-            });
-
-            container.Model.For<IFantasySeries>()
-                .Instances.Select(x => x.ReturnedType)
-                .OrderBy(x => x.Name)
-                .ShouldHaveTheSameElementsAs(typeof(BlackCompany), typeof(GameOfThrones), typeof(WheelOfTime));
-        }
-
-

Note, "T" does not have to be an interface, it's all based on the ability to cast a concrete type to the "T"

Generic Types

See Generic Types for an example of using the ConnectImplementationsToTypesClosing -mechanism for generic types.

Register Concrete Types against the First Interface

The last built in registration convention is a mechanism to register all concrete types -that implement at least one interface against the first interface that they implement.


-            container = new Container(x =>
-            {
-                x.Scan(o =>
-                {
-                    o.TheCallingAssembly();
-                    o.RegisterConcreteTypesAgainstTheFirstInterface();
-
-                    o.Exclude(t => t.CanBeCastTo(typeof(IGateway)));
-                });
-            });
-

- + + +

The type scanning facilities were completely overhauled and greatly optimized for performance as part of the StructureMap 4.0 release. The mechanism for custom registration conventions is somewhat different from 2.5-3.* to 4.0.

StructureMap has rich support for registering types by scanning assemblies and applying conventional registrations. +Between scanning and default conventions, configurations are often just a few +lines.

Also see Type Scanning Diagnostics for help in understanding the assembly scanning behavior in your system.

Registry.Scan()

Assembly scanning operations are defined by the Registry.Scan() method demonstrated below:


public class BasicScanning : Registry
{
    public BasicScanning()
    {
        Scan(_ =>
        {
            // Declare which assemblies to scan
            _.Assembly("StructureMap.Testing");
            _.AssemblyContainingType<IWidget>();

            // Filter types
            _.Exclude(type => type.Name.Contains("Bad"));

            // A custom registration convention
            _.Convention<MySpecialRegistrationConvention>();

            // Built in registration conventions
            _.AddAllTypesOf<IWidget>().NameBy(x => x.Name.Replace("Widget", ""));
            _.WithDefaultConventions();
        });
    }
}

Please note (because I've been asked this several times over the years) that each call to Registry.Scan() is an entirely atomic operation that has no impact on previous or subsequent calls.

Any given call to Registry.Scan() consists of three different things:

One or more assemblies to scan for types
One or more registration conventions
Optionally, set filters to only include certain types or exclude other types from being processed by the scanning operation

Scan the Calling Assembly

One of the easiest ways to register types is by scanning the assembly your +registry is placed in.

Note if you have other registries, StructureMap will not automatically +find them.


[Fact]
public void scan_but_ignore_registries_by_default()
{
    Scan(x => { x.TheCallingAssembly(); });

    TestingRegistry.WasUsed.ShouldBeFalse();
}

Note that this method is an extension method in the StructureMap.Net4 assembly and cannot be used +if you target PCL compliance.

Scan for Registries

StructureMap can automatically include other registries with theLookForRegistries +method.


[Fact]
public void Search_for_registries_when_explicitly_told()
{
    Scan(x =>
    {
        x.TheCallingAssembly();
        x.LookForRegistries();
    });

    TestingRegistry.WasUsed.ShouldBeTrue();
}

As of 4.0, this operation is now recursive and StructureMap has always been idempotent about adding Registry types

Search for Assemblies on the File System

StructureMap provides facilities for registering types by finding assemblies in the application bin path:


[Fact]
public void scan_all_assemblies_in_a_folder()
{
    Scan(x => x.AssembliesFromPath(assemblyScanningFolder));
    shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
    shouldHaveFamilyWithSameName<IWorker>();
    shouldNotHaveFamilyWithSameName<IDefinedInExe>();
}

[Fact]
public void scan_all_assemblies_in_application_base_directory()
{
    Scan(x => x.AssembliesFromApplicationBaseDirectory());
    shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
    shouldHaveFamilyWithSameName<IWorker>();
    shouldNotHaveFamilyWithSameName<IDefinedInExe>();
}

Do note that StructureMap 4.0 does not search for .exe files in the assembly search. The StructureMap team felt this was +problematic and "nobody would ever actually want to do that." We were wrong, and due to many user requests, you can now +opt in to scanning .exe files with a new public method on AssemblyScanner shown below:


[Fact]
public void scan_all_assemblies_in_a_folder_including_exe()
{
    Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder));

    shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
    shouldHaveFamilyWithSameName<IWorker>();
    shouldHaveFamilyWithSameName<IDefinedInExe>();
}


[Fact]
public void scan_all_assemblies_in_application_base_directory_including_exe()
{
    Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory());

    shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
    shouldHaveFamilyWithSameName<IWorker>();
    shouldHaveFamilyWithSameName<IDefinedInExe>();
}

Do be aware that while this technique is very powerful for extensibility, it's been extremely problematic for +some folks in the past. The StructureMap team's recommendation for using this feature is to:

Make sure you have some kind of filter on the assemblies scanned for performance and predictability reasons. Either a naming convention or filter +by an assembly attribute to narrow where StructureMap looks
Get familiar with the new type scanning diagnostics introduced in 4.0;-)

Behind the scenes, StructureMap is using the Assembly.GetExportedTypes() method from the .Net CLR to find types and this +mechanism is very sensitive to missing dependencies. Again, thanks to the new type scanning diagnostics, +you now have some visibility into assembly loading failures that used to be silently swallowed internally.

Excluding Types

StructureMap also makes it easy to exclude types, either individually or by namespace. +The following examples also show how StructureMap can register an assembly by providing +a type within that assembly.

Excluding additional types or namespaces is as easy as calling the corresponding method +again.


[Fact]
public void use_a_single_exclude_of_type()
{
    Scan(x =>
    {
        x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
        x.ExcludeType<ITypeThatHasAttributeButIsNotInRegistry>();
    });

    shouldHaveFamily<IInterfaceInWidget5>();
    shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>();
}

[Fact]
public void use_a_single_exclude2()
{
    Scan(x =>
    {
        x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
        x.ExcludeNamespace("StructureMap.Testing.Widget5");
    });

    shouldNotHaveFamily<IInterfaceInWidget5>();
    shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>();
}

[Fact]
public void use_a_single_exclude3()
{
    Scan(x =>
    {
        x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
        x.ExcludeNamespaceContainingType<ITypeThatHasAttributeButIsNotInRegistry>();
    });

    shouldNotHaveFamily<IInterfaceInWidget5>();
    shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>();
}

Custom Registration Conventions

It's just not possible (or desirable) for StructureMap to include every possible type of auto registration +convention users might want, but that's okay because StructureMap allows you to create and use your own +conventions through the IRegistrationConvention interface:


public interface IRegistrationConvention
{
    void ScanTypes(TypeSet types, Registry registry);
}

Let's say that you'd like a custom convention that just registers a concrete type against all the interfaces +that it implements. You could then build a custom IRegistrationConvention class like the following example:


public interface IFoo
{
}

public interface IBar
{
}

public interface IBaz
{
}

public class BusyGuy : IFoo, IBar, IBaz
{
}

// Custom IRegistrationConvention
public class AllInterfacesConvention : IRegistrationConvention
{
    public void ScanTypes(TypeSet types, Registry registry)
    {
        // Only work on concrete types
        types.FindTypes(TypeClassification.Concretes | TypeClassification.Closed).Each(type =>
        {
            // Register against all the interfaces implemented
            // by this concrete class
            type.GetInterfaces().Each(@interface => registry.For(@interface).Use(type));
        });
    }
}

[Fact]
public void use_custom_registration_convention()
{
    var container = new Container(_ =>
    {
        _.Scan(x =>
        {
            // You're probably going to want to tightly filter
            // the Type's that are applicable to avoid unwanted
            // registrations
            x.TheCallingAssembly();
            x.IncludeNamespaceContainingType<BusyGuy>();

            // Register the custom policy
            x.Convention<AllInterfacesConvention>();
        });
    });

    container.GetInstance<IFoo>().ShouldBeOfType<BusyGuy>();
    container.GetInstance<IBar>().ShouldBeOfType<BusyGuy>();
    container.GetInstance<IBaz>().ShouldBeOfType<BusyGuy>();
}

The Default ISomething/Something Convention

The "default" convention simply tries to connect concrete classes to interfaces using +the I[Something]/[Something] naming convention as shown in this sample:


public interface ISpaceship { }

public class Spaceship : ISpaceship { }

public interface IRocket { }

public class Rocket : IRocket { }

[Fact]
public void default_scanning_in_action()
{
    var container = new Container(_ =>
    {
        _.Scan(x =>
        {
            x.Assembly("StructureMap.Testing");
            x.WithDefaultConventions();
        });
    });

    container.GetInstance<ISpaceship>().ShouldBeOfType<Spaceship>();
    container.GetInstance<IRocket>().ShouldBeOfType<Rocket>();
}

The StructureMap team contains some VB6 veterans who hate Hungarian Notation, but can't shake the "I" nomenclature.

Registering the Single Implementation of an Interface

To tell StructureMap to automatically register any interface that only has one concrete implementation, use this method:


public interface ISong { }

public class TheOnlySong : ISong { }

[Fact]
public void only_implementation()
{
    var container = new Container(_ =>
    {
        _.Scan(x =>
        {
            x.TheCallingAssembly();
            x.SingleImplementationsOfInterface();
        });
    });

    container.GetInstance<ISong>()
        .ShouldBeOfType<TheOnlySong>();
}

Register all Concrete Types of an Interface

To add all concrete types that can be cast to a named plugin type, use this syntax:


public interface IFantasySeries { }

public class WheelOfTime : IFantasySeries { }

public class GameOfThrones : IFantasySeries { }

public class BlackCompany : IFantasySeries { }

[Fact]
public void register_all_types_of_an_interface()
{
    var container = new Container(_ =>
    {
        _.Scan(x =>
        {
            x.TheCallingAssembly();

            x.AddAllTypesOf<IFantasySeries>();

            // or

            x.AddAllTypesOf(typeof(IFantasySeries))
                .NameBy(type => type.Name.ToLower());
        });
    });

    container.Model.For<IFantasySeries>()
        .Instances.Select(x => x.ReturnedType)
        .OrderBy(x => x.Name)
        .ShouldHaveTheSameElementsAs(typeof(BlackCompany), typeof(GameOfThrones), typeof(WheelOfTime));
}

Note, "T" does not have to be an interface, it's all based on the ability to cast a concrete type to the "T"

Generic Types

See Generic Types for an example of using the ConnectImplementationsToTypesClosing +mechanism for generic types.

Register Concrete Types against the First Interface

The last built in registration convention is a mechanism to register all concrete types +that implement at least one interface against the first interface that they implement.


container = new Container(x =>
{
    x.Scan(o =>
    {
        o.TheCallingAssembly();
        o.RegisterConcreteTypesAgainstTheFirstInterface();

        o.Exclude(t => t.CanBeCastTo(typeof(IGateway)));
    });
});

@@ -88,43 +88,20 @@

Changing Configuration at Runtime - - -

Use the technique shown here with caution.

If you need to add or change configuration to an existing StructureMap Container object, you can use the IContainer.Configure() method -to add or change your container at runtime as shown below:


-        [Fact]
-        public void change_default_in_an_existing_container()
-        {
-            var container = new Container(x => { x.For<IFoo>().Use<AFoo>(); });
-
-            container.GetInstance<IFoo>().ShouldBeOfType<AFoo>();
-
-            // Now, change the container configuration
-            container.Configure(x => x.For<IFoo>().Use<BFoo>());
-
-            // The default of IFoo is now different
-            container.GetInstance<IFoo>().ShouldBeOfType<BFoo>();
-
-            // or use the Inject method that's just syntactical
-            // sugar for replacing the default of one type at a time
-
-            container.Inject<IFoo>(new CFoo());
-
-            container.GetInstance<IFoo>().ShouldBeOfType<CFoo>();
-        }
-
-

Best Practices

First off, the best advice on this functionality is don't use it outside of testing scenarios on the root container. The Configure() method has to use a threading lock around the internal object model of a StructureMap container and can cause serious contention at runtime if you try to override services in the main application controller. Some frameworks (looking at you NancyFx) have abused this functionality quite badly in the past and the result was not pretty.

Do favor writing configuration to StructureMap Registry objects, then applying that Registry to a container rather than repeatedly calling Configure()
Do not call Configure() on the main application container after the initial configuration. Use nested or child containers that are not shared across threads or HTTP requests if you need to override services at runtime
There's a potential performance hit from using Configure() at runtime because StructureMap has to recycle its internal Build Plan's based on -the potential new configuration.

- + + +

Use the technique shown here with caution.

If you need to add or change configuration to an existing StructureMap Container object, you can use the IContainer.Configure() method +to add or change your container at runtime as shown below:


[Fact]
public void change_default_in_an_existing_container()
{
    var container = new Container(x => { x.For<IFoo>().Use<AFoo>(); });

    container.GetInstance<IFoo>().ShouldBeOfType<AFoo>();

    // Now, change the container configuration
    container.Configure(x => x.For<IFoo>().Use<BFoo>());

    // The default of IFoo is now different
    container.GetInstance<IFoo>().ShouldBeOfType<BFoo>();

    // or use the Inject method that's just syntactical
    // sugar for replacing the default of one type at a time

    container.Inject<IFoo>(new CFoo());

    container.GetInstance<IFoo>().ShouldBeOfType<CFoo>();
}

Best Practices

Do favor writing configuration to StructureMap Registry objects, then applying that Registry to a container rather than repeatedly calling Configure()
Do not call Configure() on the main application container after the initial configuration. Use nested or child containers that are not shared across threads or HTTP requests if you need to override services at runtime
There's a potential performance hit from using Configure() at runtime because StructureMap has to recycle its internal Build Plan's based on +the potential new configuration.

diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index e12a351..404f006 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@

@@ -106,37 +106,9 @@

Replace or Clear Out Previous Registrations IWidget service to run. For an important client, they want to deploy our system with a special version, so we will create a new StructureMap Registry to apply their specific registrations using the ClearAll() mechanism to insure that the important client gets their way:


-        public class ImportantClientWidget : IWidget { }
-
-        public class ImportantClientServices : Registry
-        {
-            public ImportantClientServices()
-            {
-                For<IWidget>().ClearAll().Use<ImportantClientWidget>();
-            }
-        }
-
-


public class ImportantClientWidget : IWidget { }

public class ImportantClientServices : Registry
{
    public ImportantClientServices()
    {
        For<IWidget>().ClearAll().Use<ImportantClientWidget>();
    }
}

In usage, the ClearAll() stomps all over the default registration before adding their own:


-        [Fact]
-        public void clear_all_in_action()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Use<AWidget>();
-
-                _.IncludeRegistry<ImportantClientServices>();
-            });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<ImportantClientWidget>();
-
-            Debug.WriteLine(container.WhatDoIHave(pluginType: typeof(IWidget)));
-        }
-
-


[Fact]
public void clear_all_in_action()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();

        _.IncludeRegistry<ImportantClientServices>();
    });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<ImportantClientWidget>();

    Debug.WriteLine(container.WhatDoIHave(pluginType: typeof(IWidget)));
}

If you were to check the WhatDoIHave() view for IWidget, you would see only the ImportantClientWidget:

 ==============================================================================================================================================
@@ -146,7 +118,6 @@ Replace or Clear Out Previous Registrations 
           
             
-              StructureMap
+              StructureMap 4.4.2
             
             
               
@@ -74,7 +74,7 @@
 
               
                 
-                    
+                    
                     Next
Construction Policies
                     Previous
Auto-Registration and Conventions
                 
@@ -95,139 +95,22 @@ Working with IConfiguredInstance Registry DSL fluent interface provides the main way of explicitly configuring concrete type creation,
 the IConfiguredInstance interface is meant to support conventional registration,
 configuration attributes, and construction policies.
-
-    /// <summary>
-    /// Represents a configured Instance object that
-    /// is built by StructureMap directly by calling 
-    /// constructor functions and property setters
-    /// </summary>
-    public interface IConfiguredInstance
-    {
-        /// <summary>
-        /// The Instance name
-        /// </summary>
-        string Name { get; set; }
-
-        /// <summary>
-        /// The actual concrete type built by this Instance
-        /// </summary>
-        Type PluggedType { get; }
-
-        /// <summary>
-        /// The explicitly configured inline dependencies that override
-        /// auto-wiring
-        /// </summary>
-        DependencyCollection Dependencies { get; }
-
-        /// <summary>
-        /// Add an interceptor to only this Instance
-        /// </summary>
-        /// <param name="interceptor"></param>
-        void AddInterceptor(IInterceptor interceptor);
-
-        /// <summary>
-        /// Set the lifecycle of only this Instance to the ILifecycle type.
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <example>
-        /// SetLifecycleTo<SingletonLifecycle>()
-        /// </example>
-        void SetLifecycleTo<T>() where T : ILifecycle, new();
-
-        /// <summary>
-        /// Set the lifecycle of only this Instance to a certain lifecycle
-        /// </summary>
-        /// <param name="lifecycle"></param>
-        void SetLifecycleTo(ILifecycle lifecycle);
-
-        /// <summary>
-        /// The current Lifecycle that will be used for this Instance
-        /// </summary>
-        ILifecycle Lifecycle { get; }
-
-        /// <summary>
-        /// Explicitly choose a constructor
-        /// </summary>
-        ConstructorInfo Constructor { get; set; }
-
-        /// <summary>
-        /// Has a build plan already been created for this instance?
-        /// </summary>
-        /// <returns></returns>
-        bool HasBuildPlan();
-
-        /// <summary>
-        /// Clears out any cached IBuildPlan for this Instance.
-        /// </summary>
-        void ClearBuildPlan();
-    }
-
-
Changing the Instance Lifecycle
+
/// <summary>
/// Represents a configured Instance object that
/// is built by StructureMap directly by calling 
/// constructor functions and property setters
/// </summary>
public interface IConfiguredInstance
{
    /// <summary>
    /// The Instance name
    /// </summary>
    string Name { get; set; }

    /// <summary>
    /// The actual concrete type built by this Instance
    /// </summary>
    Type PluggedType { get; }

    /// <summary>
    /// The explicitly configured inline dependencies that override
    /// auto-wiring
    /// </summary>
    DependencyCollection Dependencies { get; }

    /// <summary>
    /// Add an interceptor to only this Instance
    /// </summary>
    /// <param name="interceptor"></param>
    void AddInterceptor(IInterceptor interceptor);

    /// <summary>
    /// Set the lifecycle of only this Instance to the ILifecycle type.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <example>
    /// SetLifecycleTo<SingletonLifecycle>()
    /// </example>
    void SetLifecycleTo<T>() where T : ILifecycle, new();

    /// <summary>
    /// Set the lifecycle of only this Instance to a certain lifecycle
    /// </summary>
    /// <param name="lifecycle"></param>
    void SetLifecycleTo(ILifecycle lifecycle);

    /// <summary>
    /// The current Lifecycle that will be used for this Instance
    /// </summary>
    ILifecycle Lifecycle { get; }

    /// <summary>
    /// Explicitly choose a constructor
    /// </summary>
    ConstructorInfo Constructor { get; set; }

    /// <summary>
    /// Has a build plan already been created for this instance?
    /// </summary>
    /// <returns></returns>
    bool HasBuildPlan();

    /// <summary>
    /// Clears out any cached IBuildPlan for this Instance.
    /// </summary>
    void ClearBuildPlan();
}

+Changing the Instance Lifecycle
 You can override the lifecycle of a single IConfiguredInstance by calling the LifecycleIs() methods and either supplying a
 type of ILifecycle or an ILifecycle object. As a quick helper, there are also extension methods for common lifecycles:
-
-            IConfiguredInstance instance
-                = new ConfiguredInstance(typeof(WidgetHolder));
-
-            // Use the SingletonThing lifecycle
-            instance.Singleton();
-
-            // or supply an ILifecycle type
-            instance.SetLifecycleTo<ThreadLocalStorageLifecycle>();
-
-            // or supply an ILifecycle object
-            instance.SetLifecycleTo(new Lifecycles_Samples.MyCustomLifecycle());
-
-            // or override to the default "transient" lifecycle
-            instance.DefaultLifecycle();
-
-Reflecting over Constructor Parameters
+
IConfiguredInstance instance
    = new ConfiguredInstance(typeof(WidgetHolder));

// Use the SingletonThing lifecycle
instance.Singleton();

// or supply an ILifecycle type
instance.SetLifecycleTo<ThreadLocalStorageLifecycle>();

// or supply an ILifecycle object
instance.SetLifecycleTo(new Lifecycles_Samples.MyCustomLifecycle());

// or override to the default "transient" lifecycle
instance.DefaultLifecycle();

+Reflecting over Constructor Parameters
 To find the constructor function parameters of an IConfiguredInstance, just use this syntax (it's just .Net Reflection):
-
-        public class GuyWithArguments
-        {
-            public GuyWithArguments(IWidget widget, Rule rule)
-            {
-            }
-        }
-
-        [Fact]
-        public void reflecting_over_constructor_args()
-        {
-            IConfiguredInstance instance = new SmartInstance<GuyWithArguments>()
-                // I'm just forcing it to assign the constructor function
-                .SelectConstructor(() => new GuyWithArguments(null, null));
-
-            instance.Constructor.GetParameters().Select(x => x.Name)
-                .ShouldHaveTheSameElementsAs("widget", "rule");
-        }
-
-
+
public class GuyWithArguments
{
    public GuyWithArguments(IWidget widget, Rule rule)
    {
    }
}

[Fact]
public void reflecting_over_constructor_args()
{
    IConfiguredInstance instance = new SmartInstance<GuyWithArguments>()
        // I'm just forcing it to assign the constructor function
        .SelectConstructor(() => new GuyWithArguments(null, null));

    instance.Constructor.GetParameters().Select(x => x.Name)
        .ShouldHaveTheSameElementsAs("widget", "rule");
}


 The constructor function selection process takes place as the very first step in creating a build plan and will be
 available in any kind of construction policy or configuration attribute on
 parameters or properties.
-Reflecting over Setter Properties
+Reflecting over Setter Properties
 There's a helper extension method off of `IConfiguredInstance' for finding all of the settable properties
 that StructureMap can work with as shown below:
-
-        public class GuyWithProperties
-        {
-            public IWidget Widget { get; set; }
-            public Rule Rule { get; private set; }
-        }
-
-        [Fact]
-        public void get_settable_properties()
-        {
-            IConfiguredInstance instance
-                = new ConfiguredInstance(typeof(GuyWithProperties));
-
-            instance.SettableProperties()
-                .Single().Name.ShouldBe("Widget");
-        }
-
-
-Working with Dependencies
+
public class GuyWithProperties
{
    public IWidget Widget { get; set; }
    public Rule Rule { get; private set; }
}

[Fact]
public void get_settable_properties()
{
    IConfiguredInstance instance
        = new ConfiguredInstance(typeof(GuyWithProperties));

    instance.SettableProperties()
        .Single().Name.ShouldBe("Widget");
}


+Working with Dependencies
 The IConfiguredInstance.Dependencies property is a collection of Argument objects that model inline dependencies. A
 single Argument can refer to a public property or the parameter in a constructor function and consists of:
 
@@ -248,112 +131,22 @@ Working with Dependencies
 insert new arguments at the front of the list if you need to do any kind of overrides of previous behavior.
 There are several Add() overloads on IConfiguredInstance.Dependencies to add dependencies, or you can use the two helper
 methods for constructor parameters and setter properties shown in the following sections.
-Add a Dependency for a Setter Property
+Add a Dependency for a Setter Property
 If you already have a PropertyInfo for the concrete type (like you might in a policy or attribute usage) and you want to register an inline dependency, there is the
 Dependencies.AddForProperty() method as a convenience. For the actual value of the dependency, it needs to either be an object
 that can be cast to the property type or an Instance object that returns a type that can be cast to the property type.
 With a value:
-
-        [Fact]
-        public void dependency_with_setter_with_value()
-        {
-            var instance
-                = new ConfiguredInstance(typeof(GuyWithProperties));
-            var prop = instance.PluggedType.GetProperty("Widget");
-
-            var myWidget = new ColorWidget("red");
-            instance.Dependencies.AddForProperty(prop, myWidget);
-
-            var container = new Container();
-
-            container.GetInstance<GuyWithProperties>(instance)
-                .Widget.ShouldBeTheSameAs(myWidget);
-        }
-
-
+
[Fact]
public void dependency_with_setter_with_value()
{
    var instance
        = new ConfiguredInstance(typeof(GuyWithProperties));
    var prop = instance.PluggedType.GetProperty("Widget");

    var myWidget = new ColorWidget("red");
    instance.Dependencies.AddForProperty(prop, myWidget);

    var container = new Container();

    container.GetInstance<GuyWithProperties>(instance)
        .Widget.ShouldBeTheSameAs(myWidget);
}


 With an Instance for the dependency value:
-
-        [Fact]
-        public void dependency_with_setter_with_instance()
-        {
-            var instance
-                = new ConfiguredInstance(typeof(GuyWithProperties));
-            var prop = instance.PluggedType.GetProperty("Widget");
-
-            var dependency = new SmartInstance<AWidget>();
-            instance.Dependencies.AddForProperty(prop, dependency);
-
-            var container = new Container();
-
-            container.GetInstance<GuyWithProperties>(instance)
-                .Widget.ShouldBeOfType<AWidget>();
-        }
-
-
-Add a Dependency for a Constructor Parameter
+
[Fact]
public void dependency_with_setter_with_instance()
{
    var instance
        = new ConfiguredInstance(typeof(GuyWithProperties));
    var prop = instance.PluggedType.GetProperty("Widget");

    var dependency = new SmartInstance<AWidget>();
    instance.Dependencies.AddForProperty(prop, dependency);

    var container = new Container();

    container.GetInstance<GuyWithProperties>(instance)
        .Widget.ShouldBeOfType<AWidget>();
}


+Add a Dependency for a Constructor Parameter
 Likewise, you can add a dependency for a specific constructor parameter as either the actual value or an Instance object with the AddForConstructorParameter helper method:
-
-        public class GuyWithDatabaseConnection
-        {
-            public string ConnectionString { get; set; }
-
-            public GuyWithDatabaseConnection(string connectionString)
-            {
-                ConnectionString = connectionString;
-            }
-        }
-
-        [Fact]
-        public void specify_dependency_by_constructor_parameter()
-        {
-            var instance = ConstructorInstance
-                .For<GuyWithDatabaseConnection>();
-
-            var parameter = instance.Constructor.GetParameters().Single();
-            parameter.Name.ShouldBe("connectionString");
-
-            var connString =
-                "I haven't used sql server in years and I don't remember what connection strings look like";
-
-            instance.Dependencies.AddForConstructorParameter(parameter, connString);
-
-            var guy = new Container().GetInstance<GuyWithDatabaseConnection>(instance);
-
-            guy.ConnectionString.ShouldBe(connString);
-        }
-
-
-Adding Interceptors
+
public class GuyWithDatabaseConnection
{
    public string ConnectionString { get; set; }

    public GuyWithDatabaseConnection(string connectionString)
    {
        ConnectionString = connectionString;
    }
}

[Fact]
public void specify_dependency_by_constructor_parameter()
{
    var instance = ConstructorInstance
        .For<GuyWithDatabaseConnection>();

    var parameter = instance.Constructor.GetParameters().Single();
    parameter.Name.ShouldBe("connectionString");

    var connString =
        "I haven't used sql server in years and I don't remember what connection strings look like";

    instance.Dependencies.AddForConstructorParameter(parameter, connString);

    var guy = new Container().GetInstance<GuyWithDatabaseConnection>(instance);

    guy.ConnectionString.ShouldBe(connString);
}


+Adding Interceptors
 You can add interceptors directly to a single IConfiguredInstance with code like this:
-
-
-        public class SimpleWidget
-        {
-            public bool WasIntercepted = false;
-
-            public void Intercept()
-            {
-                WasIntercepted = true;
-            }
-        }
-
-        [Fact]
-        public void add_interceptor()
-        {
-            var interceptor =
-                new ActivatorInterceptor<SimpleWidget>(w => w.Intercept());
-            var instance = new SmartInstance<SimpleWidget>();
-
-            instance.AddInterceptor(interceptor);
-
-            new Container().GetInstance<SimpleWidget>(instance)
-                .WasIntercepted.ShouldBeTrue();
-        }
-
-
+

public class SimpleWidget
{
    public bool WasIntercepted = false;

    public void Intercept()
    {
        WasIntercepted = true;
    }
}

[Fact]
public void add_interceptor()
{
    var interceptor =
        new ActivatorInterceptor<SimpleWidget>(w => w.Intercept());
    var instance = new SmartInstance<SimpleWidget>();

    instance.AddInterceptor(interceptor);

    new Container().GetInstance<SimpleWidget>(instance)
        .WasIntercepted.ShouldBeTrue();
}


 See Interception and Decorators for more information.
 
-
                       
 
                       
diff --git a/registration/configuring-the-raw-model/index.html b/registration/configuring-the-raw-model/index.html
deleted file mode 100644
index 21988dc..0000000
--- a/registration/configuring-the-raw-model/index.html
+++ /dev/null
@@ -1,157 +0,0 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Configuring the Raw Model
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Configuring the Raw Model
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 3.1.6
-		      	

-
-				
-
-		        
-
-		        	Next
Fallback Services
-		        	Previous
Constructor Selection
-
-		        
-		      

-		      
-		      
-		      
-			      	Configuring the Raw Model
-			      
-			      	
-
-			      	
-			      		
-
-TODO(Write some content!)
-
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Constructor Selection
-
-				        
-				        
-
-				        	Next: Fallback Services
-
-				        
-			      	
-
-		      

-

- - - - - - - - - - - - - - - - - - diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index 958f4a0..8bec134 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -31,7 +31,7 @@

@@ -88,253 +88,45 @@

Constructor Selection - - -

StructureMap 3.* greatly improves the control over the selection of constructor functions to build concrete types -by allowing users to override the constructor selection on specific Instance's and register custom rules for -selecting constructors to override the basic StructureMap behavior.

In all cases, StructureMap can only use public constructor functions.

Greediest Constructor

If there are multiple public constructor functions on a concrete class, StructureMap's default behavior is to -select the "greediest" constructor, i.e., the constructor function with the most parameters. In the case of two or more -constructor functions with the same number of parameters StructureMap will simply take the first constructor encountered -in that subset of constructors.

The default constructor selection is demonstrated below:


-        public class GreaterThanRule : Rule
-        {
-            public string Attribute { get; set; }
-            public int Value { get; set; }
-
-            public GreaterThanRule()
-            {
-            }
-
-            public GreaterThanRule(string attribute, int value)
-            {
-                Attribute = attribute;
-                Value = value;
-            }
-
-            public GreaterThanRule(IWidget widget, Rule rule)
-            {
-            }
-        }
-
-        [Fact]
-        public void using_the_greediest_ctor()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForConcreteType<GreaterThanRule>().Configure
-                    .Ctor<string>("attribute").Is("foo")
-                    .Ctor<int>("value").Is(42);
-            });
-
-            var rule = container.GetInstance<GreaterThanRule>();
-            rule.Attribute.ShouldBe("foo");
-            rule.Value.ShouldBe(42);
-        }
-
-

New in StructureMap 4.0, the "greediest constructor selection" will bypass any constructor function that requires "simple" arguments -like strings, numbers, or enumeration values that are not explicitly configured for the instance.

You can see this behavior shown below:


-        public class DbContext
-        {
-            public string ConnectionString { get; set; }
-
-            public DbContext(string connectionString)
-            {
-                ConnectionString = connectionString;
-            }
-
-            public DbContext() : this("default value")
-            {
-            }
-        }
-
-        [Fact]
-        public void should_bypass_ctor_with_unresolvable_simple_args()
-        {
-            var container = new Container();
-            container.GetInstance<DbContext>()
-                .ConnectionString.ShouldBe("default value");
-        }
-
-        [Fact]
-        public void should_use_greediest_ctor_that_has_all_of_simple_dependencies()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForConcreteType<DbContext>().Configure
-                    .Ctor<string>("connectionString").Is("not the default");
-            });
-
-            container.GetInstance<DbContext>()
-                .ConnectionString.ShouldBe("not the default");
-        }
-
-

Explicitly Selecting a Constructor

To override the constructor selection explicitly on a case by case basis, you -can use the SelectConstructor(Expression) method in the Registry DSL -as shown below:


-        public class Thingie
-        {
-            public Thingie(IWidget widget)
-            {
-                CorrectCtorWasUsed = true;
-            }
-
-            public bool CorrectCtorWasUsed { get; set; }
-
-            public Thingie(IWidget widget, IService service)
-            {
-                Assert.True(false, "I should not have been called");
-            }
-        }
-
-        [Fact]
-        public void override_the_constructor_selection()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Use<AWidget>();
-
-                _.ForConcreteType<Thingie>().Configure
-
-                    // StructureMap parses the expression passed
-                    // into the method below to determine the
-                    // constructor
-                    .SelectConstructor(() => new Thingie(null));
-            });
-
-            container.GetInstance<Thingie>()
-                .CorrectCtorWasUsed
-                .ShouldBeTrue();
-        }
-
-

[DefaultConstructor] Attribute

Alternatively, you can override the choice of constructor function by using the -older [DefaultConstructor] attribute like this:


-        public class AttributedThing
-        {
-            // Normally the greediest ctor would be
-            // selected, but using this attribute
-            // will overrid that behavior
-            [DefaultConstructor]
-            public AttributedThing(IWidget widget)
-            {
-                CorrectCtorWasUsed = true;
-            }
-
-            public bool CorrectCtorWasUsed { get; set; }
-
-            public AttributedThing(IWidget widget, IService service)
-            {
-                Assert.True(false, "I should not have been called");
-            }
-        }
-
-        [Fact]
-        public void select_constructor_by_attribute()
-        {
-            var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); });
-
-            container.GetInstance<AttributedThing>()
-                .CorrectCtorWasUsed
-                .ShouldBeTrue();
-        }
-
-

Custom Constructor Selection Rule

If the constructor selection logic isn't what you want, you can systematically -override the selection rules by registering one or more custom IConstructorSelector -policies to a Container. Do note that you can register more than one policy and they -will be executed from last one registered to the first one registered.

Let's say that you want to control the constructor selection for all concrete -subclasses of an abstract class like this hiearchy:


-    public abstract class BaseThing
-    {
-        public BaseThing(IWidget widget)
-        {
-            CorrectCtorWasUsed = true;
-        }
-
-        public bool CorrectCtorWasUsed { get; set; }
-
-        public BaseThing(IWidget widget, IService service)
-        {
-            Assert.True(false, "I should not have been called");
-        }
-    }
-
-    public class Thing1 : BaseThing
-    {
-        public Thing1(IWidget widget) : base(widget)
-        {
-        }
-
-        public Thing1(IWidget widget, IService service) : base(widget, service)
-        {
-        }
-    }
-
-    public class Thing2 : BaseThing
-    {
-        public Thing2(IWidget widget) : base(widget)
-        {
-        }
-
-        public Thing2(IWidget widget, IService service) : base(widget, service)
-        {
-        }
-    }
-
-

You could create a custom IConstructorSelector like this one below to override -the constructor behavior for only subclasses of BaseThing:


-    public class ThingCtorRule : IConstructorSelector
-    {
-        public ConstructorInfo Find(Type pluggedType, DependencyCollection dependencies, PluginGraph graph)
-        {
-            // if this rule does not apply to the pluggedType,
-            // just return null to denote "not applicable"
-            if (!pluggedType.CanBeCastTo<BaseThing>()) return null;
-
-            return pluggedType.GetConstructor(new[] { typeof(IWidget) });
-        }
-    }
-
-

Finally, you can register your custom rule as shown below:


-        [Fact]
-        public void use_a_custom_constructor_selector()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Use<AWidget>();
-
-                _.Policies.ConstructorSelector<ThingCtorRule>();
-            });
-
-            container.GetInstance<Thing1>()
-                .CorrectCtorWasUsed.ShouldBeTrue();
-
-            container.GetInstance<Thing2>()
-                .CorrectCtorWasUsed.ShouldBeTrue();
-        }
-
-

- + + +

StructureMap 3.* greatly improves the control over the selection of constructor functions to build concrete types +by allowing users to override the constructor selection on specific Instance's and register custom rules for +selecting constructors to override the basic StructureMap behavior.

In all cases, StructureMap can only use public constructor functions.

Greediest Constructor

If there are multiple public constructor functions on a concrete class, StructureMap's default behavior is to +select the "greediest" constructor, i.e., the constructor function with the most parameters. In the case of two or more +constructor functions with the same number of parameters StructureMap will simply take the first constructor encountered +in that subset of constructors.

The default constructor selection is demonstrated below:


public class GreaterThanRule : Rule
{
    public string Attribute { get; set; }
    public int Value { get; set; }

    public GreaterThanRule()
    {
    }

    public GreaterThanRule(string attribute, int value)
    {
        Attribute = attribute;
        Value = value;
    }

    public GreaterThanRule(IWidget widget, Rule rule)
    {
    }
}

[Fact]
public void using_the_greediest_ctor()
{
    var container = new Container(_ =>
    {
        _.ForConcreteType<GreaterThanRule>().Configure
            .Ctor<string>("attribute").Is("foo")
            .Ctor<int>("value").Is(42);
    });

    var rule = container.GetInstance<GreaterThanRule>();
    rule.Attribute.ShouldBe("foo");
    rule.Value.ShouldBe(42);
}

New in StructureMap 4.0, the "greediest constructor selection" will bypass any constructor function that requires "simple" arguments +like strings, numbers, or enumeration values that are not explicitly configured for the instance.

You can see this behavior shown below:


public class DbContext
{
    public string ConnectionString { get; set; }

    public DbContext(string connectionString)
    {
        ConnectionString = connectionString;
    }

    public DbContext() : this("default value")
    {
    }
}

[Fact]
public void should_bypass_ctor_with_unresolvable_simple_args()
{
    var container = new Container();
    container.GetInstance<DbContext>()
        .ConnectionString.ShouldBe("default value");
}

[Fact]
public void should_use_greediest_ctor_that_has_all_of_simple_dependencies()
{
    var container = new Container(_ =>
    {
        _.ForConcreteType<DbContext>().Configure
            .Ctor<string>("connectionString").Is("not the default");
    });

    container.GetInstance<DbContext>()
        .ConnectionString.ShouldBe("not the default");
}

Explicitly Selecting a Constructor

To override the constructor selection explicitly on a case by case basis, you +can use the SelectConstructor(Expression) method in the Registry DSL +as shown below:


public class Thingie
{
    public Thingie(IWidget widget)
    {
        CorrectCtorWasUsed = true;
    }

    public bool CorrectCtorWasUsed { get; set; }

    public Thingie(IWidget widget, IService service)
    {
        Assert.True(false, "I should not have been called");
    }
}

[Fact]
public void override_the_constructor_selection()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();

        _.ForConcreteType<Thingie>().Configure

            // StructureMap parses the expression passed
            // into the method below to determine the
            // constructor
            .SelectConstructor(() => new Thingie(null));
    });

    container.GetInstance<Thingie>()
        .CorrectCtorWasUsed
        .ShouldBeTrue();
}

[DefaultConstructor] Attribute

Alternatively, you can override the choice of constructor function by using the +older [DefaultConstructor] attribute like this:


public class AttributedThing
{
    // Normally the greediest ctor would be
    // selected, but using this attribute
    // will overrid that behavior
    [DefaultConstructor]
    public AttributedThing(IWidget widget)
    {
        CorrectCtorWasUsed = true;
    }

    public bool CorrectCtorWasUsed { get; set; }

    public AttributedThing(IWidget widget, IService service)
    {
        Assert.True(false, "I should not have been called");
    }
}

[Fact]
public void select_constructor_by_attribute()
{
    var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); });

    container.GetInstance<AttributedThing>()
        .CorrectCtorWasUsed
        .ShouldBeTrue();
}

Custom Constructor Selection Rule

If the constructor selection logic isn't what you want, you can systematically +override the selection rules by registering one or more custom IConstructorSelector +policies to a Container. Do note that you can register more than one policy and they +will be executed from last one registered to the first one registered.

Let's say that you want to control the constructor selection for all concrete +subclasses of an abstract class like this hiearchy:


public abstract class BaseThing
{
    public BaseThing(IWidget widget)
    {
        CorrectCtorWasUsed = true;
    }

    public bool CorrectCtorWasUsed { get; set; }

    public BaseThing(IWidget widget, IService service)
    {
        Assert.True(false, "I should not have been called");
    }
}

public class Thing1 : BaseThing
{
    public Thing1(IWidget widget) : base(widget)
    {
    }

    public Thing1(IWidget widget, IService service) : base(widget, service)
    {
    }
}

public class Thing2 : BaseThing
{
    public Thing2(IWidget widget) : base(widget)
    {
    }

    public Thing2(IWidget widget, IService service) : base(widget, service)
    {
    }
}

You could create a custom IConstructorSelector like this one below to override +the constructor behavior for only subclasses of BaseThing:


public class ThingCtorRule : IConstructorSelector
{
    public ConstructorInfo Find(Type pluggedType, DependencyCollection dependencies, PluginGraph graph)
    {
        // if this rule does not apply to the pluggedType,
        // just return null to denote "not applicable"
        if (!pluggedType.CanBeCastTo<BaseThing>()) return null;

        return pluggedType.GetConstructor(new[] { typeof(IWidget) });
    }
}

Finally, you can register your custom rule as shown below:


[Fact]
public void use_a_custom_constructor_selector()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();

        _.Policies.ConstructorSelector<ThingCtorRule>();
    });

    container.GetInstance<Thing1>()
        .CorrectCtorWasUsed.ShouldBeTrue();

    container.GetInstance<Thing2>()
        .CorrectCtorWasUsed.ShouldBeTrue();
}

@@ -91,23 +91,12 @@

Registering Existing Objects Container and there are overloads of the Registry.For().Use(object) and Registry.For().Add(object) methods to do just that:


-        [Fact]
-        public void should_be_able_to_resolve_from_the_generic_family_expression()
-        {
-            var widget = new AWidget();
-            var container = new Container(x => x.For(typeof(IWidget)).Use(widget).Named("mine"));
-
-            container.GetInstance<IWidget>("mine").ShouldBeTheSameAs(widget);
-        }
-
-


[Fact]
public void should_be_able_to_resolve_from_the_generic_family_expression()
{
    var widget = new AWidget();
    var container = new Container(x => x.For(typeof(IWidget)).Use(widget).Named("mine"));

    container.GetInstance<IWidget>("mine").ShouldBeTheSameAs(widget);
}

Injecting an existing object into the Container makes it a de facto singleton, but the Container treats it with a special scope called ObjectLifecycle if you happen to look into the WhatDoIHave() diagnostics.

StructureMap will attempt to call the IDisposable.Dispose() on any objects that are directly injected into a Container that implement IDisposable when the Container itself is disposed.

@@ -88,92 +88,19 @@

Fallback Services - - -

The following is a technique that was stolen from FubuMVC where we used -the idea of default or "fallback" registrations to make it mechanically simple for the core framework to declare -the default service registrations in the Container for what FubuMVC needed while allowing applications to happily -override specific registrations without having to worry about the order in which the registrations were done.

To see this in practice, say you have an application that will support client specific modularity that might allow -business clients to override the base StructureMap registrations. This is a perfect use case for -defining the application defaults with UseIfNone() as shown in this example below:


-        public class DefaultServices : Registry
-        {
-            public DefaultServices()
-            {
-                // If nobody else provides a default
-                // for IWidget, use AWidget
-                For<IWidget>().UseIfNone<AWidget>();
-            }
-        }
-
-        public class SpecificServices : Registry
-        {
-            public SpecificServices()
-            {
-                // Use BWidget for IWidget, period
-                For<IWidget>().Use<BWidget>();
-            }
-        }
-
-

In application usage, you would add the default UseIfNone() registrations, and optionally pick -up additional extension Registry objects from extension assemblies as shown in this example:


-        [AttributeUsage(AttributeTargets.Assembly)]
-        public class ProductModuleAttribute : Attribute
-        {
-        }
-
-        public class ApplicationRegistry : Registry
-        {
-            public ApplicationRegistry()
-            {
-                // Use the default services as fallbacks
-                IncludeRegistry<DefaultServices>();
-
-                // Dependending on what assemblies are present,
-                // this might find specific registrations that
-                // will take precedence over the UseIfNone()
-                // registrations in DefaultServices
-                Scan(_ =>
-                {
-                    _.AssembliesFromApplicationBaseDirectory(
-                        assem => assem.HasAttribute<ProductModuleAttribute>());
-
-                    _.LookForRegistries();
-                });
-            }
-        }
-
-        [Fact]
-        public void see_use_if_none_in_action()
-        {
-            var container1 = Container.For<DefaultServices>();
-
-            // No other registrations, so fallback
-            // to AWidget
-            container1.GetInstance<IWidget>()
-                .ShouldBeOfType<AWidget>();
-
-            var container2 = new Container(_ =>
-            {
-                // add both registries above
-                // NOTE: the order does not matter for IWidget
-
-                _.IncludeRegistry<SpecificServices>();
-                _.IncludeRegistry<DefaultServices>();
-            });
-
-            // The registration in SpecificServices
-            // should win out
-            container2.GetInstance<IWidget>()
-                .ShouldBeOfType<BWidget>();
-        }
-
-

- + + +

The following is a technique that was stolen from FubuMVC where we used +the idea of default or "fallback" registrations to make it mechanically simple for the core framework to declare +the default service registrations in the Container for what FubuMVC needed while allowing applications to happily +override specific registrations without having to worry about the order in which the registrations were done.

To see this in practice, say you have an application that will support client specific modularity that might allow +business clients to override the base StructureMap registrations. This is a perfect use case for +defining the application defaults with UseIfNone() as shown in this example below:


public class DefaultServices : Registry
{
    public DefaultServices()
    {
        // If nobody else provides a default
        // for IWidget, use AWidget
        For<IWidget>().UseIfNone<AWidget>();
    }
}

public class SpecificServices : Registry
{
    public SpecificServices()
    {
        // Use BWidget for IWidget, period
        For<IWidget>().Use<BWidget>();
    }
}

In application usage, you would add the default UseIfNone() registrations, and optionally pick +up additional extension Registry objects from extension assemblies as shown in this example:


[AttributeUsage(AttributeTargets.Assembly)]
public class ProductModuleAttribute : Attribute
{
}

public class ApplicationRegistry : Registry
{
    public ApplicationRegistry()
    {
        // Use the default services as fallbacks
        IncludeRegistry<DefaultServices>();

        // Dependending on what assemblies are present,
        // this might find specific registrations that
        // will take precedence over the UseIfNone()
        // registrations in DefaultServices
        Scan(_ =>
        {
            _.AssembliesFromApplicationBaseDirectory(
                assem => assem.HasAttribute<ProductModuleAttribute>());

            _.LookForRegistries();
        });
    }
}

[Fact]
public void see_use_if_none_in_action()
{
    var container1 = Container.For<DefaultServices>();

    // No other registrations, so fallback
    // to AWidget
    container1.GetInstance<IWidget>()
        .ShouldBeOfType<AWidget>();

    var container2 = new Container(_ =>
    {
        // add both registries above
        // NOTE: the order does not matter for IWidget

        _.IncludeRegistry<SpecificServices>();
        _.IncludeRegistry<DefaultServices>();
    });

    // The registration in SpecificServices
    // should win out
    container2.GetInstance<IWidget>()
        .ShouldBeOfType<BWidget>();
}

@@ -88,119 +88,33 @@

Registration - - -

As of the 3.0 release, StructureMap provides a streamlined fluent interface called the Registry DSL to configure a StructureMap -Container with both explicit registrations and conventional auto-registrations. StructureMap no longer supports Xml configuration or MEF-style attribute configuration -- but there is some facility for rolling your own attribute-based configuration support.

The first step in using StructureMap is configuring a Container object. The following examples are based on the usage of the Registry DSL.

Let's say that you have a simple set of services like this:


-    public interface IBar
-    {
-    }
-
-    public class Bar : IBar
-    {
-    }
-
-    public interface IFoo
-    {
-    }
-
-    public class Foo : IFoo
-    {
-        public IBar Bar { get; private set; }
-
-        public Foo(IBar bar)
-        {
-            Bar = bar;
-        }
-    }
-
-

A simple configuration of a StructureMap Container might then be:


-// Example #1 - Create an container instance and directly pass in the configuration.
-            var container1 = new Container(c =>
-            {
-                c.For<IFoo>().Use<Foo>();
-                c.For<IBar>().Use<Bar>();
-            });
-
-// Example #2 - Create an container instance but add configuration later.
-            var container2 = new Container();
-
-            container2.Configure(c =>
-            {
-                c.For<IFoo>().Use<Foo>();
-                c.For<IBar>().Use<Bar>();
-            });
-

Initializing or configuring the container is usually done at application startup and is located as close as possible to the application's entry point. -This place is sometimes referred to as the composition root of the application. -In our example we are composing our application's object graph by connecting abstractions to concrete types.

We are using the fluent API For<TInterface>().Use<TConcrete>() which registers a default instance for a given plugin type (the TInterface type in this case). In our example we want an new instance of Foo every time we request the abstraction IFoo.

The recommended way of using the Registry DSL is by defining one or more Registry classes. Typically, you would subclass the Registry class, -then use the Fluent API methods exposed by the Registry class to describe a Container configuration.

Here's a sample Registry class used to configure the same types as in our previous example:


-    public class FooBarRegistry : Registry
-    {
-        public FooBarRegistry()
-        {
-            For<IFoo>().Use<Foo>();
-            For<IBar>().Use<Bar>();
-        }
-    }
-
-

When you set up a Container , you need to simply direct the Container to use the configuration in that Registry class.


-// Example #1
-            var container1 = new Container(new FooBarRegistry());
-
-// Example #2
-            var container2 = new Container(c => { c.AddRegistry<FooBarRegistry>(); });
-
-// Example #3 -- create a container for a single Registry
-            var container3 = Container.For<FooBarRegistry>();
-

The StructureMap team highly recommends using `Registry` classes for your real application configuration. The syntax is shorter inside the Registry class constructor than from within the `Container` constructor method. In addition, Registry classes can be used to modularize the configuration of a bigger application into more manageable chunks. Lastly, using `Registry` classes makes it easier to stand up additional `Container` objects in testing scenarios that reflect the real application composition.

In real world applications you also have to deal with repetitive similar registrations. Such registrations are tedious, easy to forget and can be a weak spot in your application. StructureMap provides Auto-Registration and Conventions which mitigates this pain and eases the maintenance burden. StructureMap exposes this feature through the Registry DSL by the Scan method.

In our example there is an reoccuring pattern, we are connecting the plugin type ISomething to a concrete type Something, meaning IFoo to Foo and IBar to Bar. Wouldn't it be cool if we could write a convention for exactly doing that? Fortunatly StructureMap has already one build in. Let's see how we can create an container with the same configuration as in the above examples.


-// Example #1
-            var container1 = new Container(c =>
-                c.Scan(scanner =>
-                {
-                    scanner.TheCallingAssembly();
-                    scanner.WithDefaultConventions();
-                }));
-
-// Example #2
-            var container2 = new Container();
-
-            container2.Configure(c =>
-                c.Scan(scanner =>
-                {
-                    scanner.TheCallingAssembly();
-                    scanner.WithDefaultConventions();
-                }));
-
-
-

We instruct the scanner to scan through the calling assembly with default conventions on. This will find and register the default instance for IFoo and IBar which are obviously the concrete types Foo and Bar. Now whenever you add an additional interface IMoreFoo and a class MoreFoo to your application's code base, it's automatically picked up by the scanner.

Sometimes classes need to be supplied with some primitive value in its constructor. For example the System.Data.SqlClient.SqlConnection needs to be supplied with the connection string in its constructor. No problem, just set up the value of the constructor argument in the bootstrapping:


-            var container = new Container(c =>
-            {
-                //just for demo purposes, normally you don't want to embed the connection string directly into code.
-                c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING");
-                //a better way would be providing a delegate that retrieves the value from your app config.    
-            });
-

So far you have seen an couple of ways to work with the <linkto:registration/registry-dsl]> and configure a Container object. We have seen examples of configuration that allow us to build objects that don't depend on anything like the Bar class, or do depend on other types like the Foo class needs an instance of IBar. In our last example we have seen configuration for objects that need some primitive types like strings in its constructor function.

- + + +

As of the 3.0 release, StructureMap provides a streamlined fluent interface called the Registry DSL to configure a StructureMap +Container with both explicit registrations and conventional auto-registrations. StructureMap no longer supports Xml configuration or MEF-style attribute configuration -- but there is some facility for rolling your own attribute-based configuration support.

The first step in using StructureMap is configuring a Container object. The following examples are based on the usage of the Registry DSL.

Let's say that you have a simple set of services like this:


public interface IBar
{
}

public class Bar : IBar
{
}

public interface IFoo
{
}

public class Foo : IFoo
{
    public IBar Bar { get; private set; }

    public Foo(IBar bar)
    {
        Bar = bar;
    }
}

A simple configuration of a StructureMap Container might then be:


// Example #1 - Create an container instance and directly pass in the configuration.
            var container1 = new Container(c =>
            {
                c.For<IFoo>().Use<Foo>();
                c.For<IBar>().Use<Bar>();
            });

// Example #2 - Create an container instance but add configuration later.
            var container2 = new Container();

            container2.Configure(c =>
            {
                c.For<IFoo>().Use<Foo>();
                c.For<IBar>().Use<Bar>();
            });

Initializing or configuring the container is usually done at application startup and is located as close as possible to the application's entry point. +This place is sometimes referred to as the composition root of the application. +In our example we are composing our application's object graph by connecting abstractions to concrete types.

The recommended way of using the Registry DSL is by defining one or more Registry classes. Typically, you would subclass the Registry class, +then use the Fluent API methods exposed by the Registry class to describe a Container configuration.

Here's a sample Registry class used to configure the same types as in our previous example:


public class FooBarRegistry : Registry
{
    public FooBarRegistry()
    {
        For<IFoo>().Use<Foo>();
        For<IBar>().Use<Bar>();
    }
}

When you set up a Container , you need to simply direct the Container to use the configuration in that Registry class.


// Example #1
            var container1 = new Container(new FooBarRegistry());

// Example #2
            var container2 = new Container(c => { c.AddRegistry<FooBarRegistry>(); });

// Example #3 -- create a container for a single Registry
            var container3 = Container.For<FooBarRegistry>();


// Example #1
            var container1 = new Container(c =>
                c.Scan(scanner =>
                {
                    scanner.TheCallingAssembly();
                    scanner.WithDefaultConventions();
                }));

// Example #2
            var container2 = new Container();

            container2.Configure(c =>
                c.Scan(scanner =>
                {
                    scanner.TheCallingAssembly();
                    scanner.WithDefaultConventions();
                }));


var container = new Container(c =>
{
    //just for demo purposes, normally you don't want to embed the connection string directly into code.
    c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING");
    //a better way would be providing a delegate that retrieves the value from your app config.    
});

So far you have seen an couple of ways to work with the Registry DSL and configure a Container object. We have seen examples of configuration that allow us to build objects that don't depend on anything like the Bar class, or do depend on other types like the Foo class needs an instance of IBar. In our last example we have seen configuration for objects that need some primitive types like strings in its constructor function.

@@ -88,375 +88,52 @@

Inline Dependencies - - -

While you generally allow StructureMap to just use auto-wiring to fill the dependencies of a concrete type, there are times -when you may want to explicitly configure individual dependencies on a case by case basis. In the case of primitive types -like strings or numbers, StructureMap will not do any auto-wiring, so it's incumbent upon you the user to supply the dependency.

Let's say we have a simple class called ColorWidget like the following:


-        public class ColorWidget : IWidget
-        {
-            public string Color { get; set; }
-
-            public ColorWidget(string color)
-            {
-                Color = color;
-            }
-        }
-
-

To register the ColorWidget, you would supply the value of the color parameter to the constructor function like so:


-        [Fact]
-        public void inline_usage_of_primitive_constructor_argument()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Use<ColorWidget>()
-                    .Ctor<string>().Is("Red");
-            });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<ColorWidget>()
-                .Color.ShouldBe("Red");
-        }
-
-

-The most common reason to define string arguments to classes seems to be passing in database connection strings or occasional file paths. -I used this strategy very commonly in the early days of StructureMap, but for the past 5-6 years I strongly prefer to use Settings classes -to inject configuration through StructureMap. -

Event Condition Action Rules

The ability to explicitly define dependencies inline isn't commonly used these days, but was actually one of the very core use cases in the initial versions of StructureMap. One of the first usages of StructureMap in a production application was in a configurable rules engine using an Event-Condition-Action architecture where the conditions and actions were configured in StructureMap as inline dependencies of Rule objects. Using StructureMap's old Xml configuration, we could define rules for new customers by registering rule objects with the container that reused existing condition and action classes in new configurations.

To make that concrete and establish a sample problem domain, consider these types:


-        public class SomeEvent
-        {
-        }
-
-        public interface ICondition
-        {
-            bool Matches(SomeEvent @event);
-        }
-
-        public interface IAction
-        {
-            void PerformWork(SomeEvent @event);
-        }
-
-        public interface IEventRule
-        {
-            void ProcessEvent(SomeEvent @event);
-        }
-
-

Now, let's move on to seeing how we could use inline dependency configuration to register new rules.

Constructor Parameters by Type

First off, let's say that we have a SimpleRule that takes a single condition and action:


-        public class SimpleRule : IEventRule
-        {
-            private readonly ICondition _condition;
-            private readonly IAction _action;
-
-            public SimpleRule(ICondition condition, IAction action)
-            {
-                _condition = condition;
-                _action = action;
-            }
-
-            public void ProcessEvent(SomeEvent @event)
-            {
-                if (_condition.Matches(@event))
-                {
-                    _action.PerformWork(@event);
-                }
-            }
-        }
-
-

Now, since SimpleRule has only a single dependency on both IAction and ICondition, we can create new rules by registering new Instance's -of SimpleRule with different combinations of its dependencies:


-        public class InlineCtorArgs : Registry
-        {
-            public InlineCtorArgs()
-            {
-                // Defining args by type
-                For<IEventRule>().Use<SimpleRule>()
-                    .Ctor<ICondition>().Is<Condition1>()
-                    .Ctor<IAction>().Is<Action1>()
-                    .Named("One");
-
-                // Pass the explicit values for dependencies
-                For<IEventRule>().Use<SimpleRule>()
-                    .Ctor<ICondition>().Is(new Condition2())
-                    .Ctor<IAction>().Is(new Action2())
-                    .Named("Two");
-
-                // Use Lambda construction
-                For<IEventRule>().Use<SimpleRule>()
-                    .Ctor<ICondition>().Is(() => new Condition3())
-                    .Ctor<IAction>().Is("some crazy builder", c => c.GetInstance<Action3>())
-                    .Named("Three");
-
-                // Rarely used, but gives you a "do any crazy thing" option
-                // Pass in your own Instance object
-                For<IEventRule>().Use<SimpleRule>()
-                    .Ctor<IAction>().Is(new MySpecialActionInstance());
-
-                // Inline configuration of your dependency's dependencies
-
-                For<IEventRule>().Use<SimpleRule>()
-                    .Ctor<ICondition>().IsSpecial(_ => _.Type<BigCondition>().Ctor<int>().Is(100))
-
-                    // or
-                    .Ctor<ICondition>().Is(new SmartInstance<BigCondition>().Ctor<int>().Is(100));
-            }
-
-            public class BigCondition : ICondition
-            {
-                public BigCondition(int number)
-                {
-                }
-
-                public bool Matches(SomeEvent @event)
-                {
-                    throw new NotImplementedException();
-                }
-            }
-
-            public class MySpecialActionInstance : LambdaInstance<Action3>
-            {
-                public MySpecialActionInstance()
-                    : base(() => new Action3())
-                {
-                }
-            }
-        }
-
-

The inline dependency configuration using the Ctor<T>().Is() syntax supports all the common StructureMap configuration options: define by type, by lambdas, by value, or if you really want to risk severe eye strain, you can use your own Instance objects and define the configuration of your dependency's dependencies.

Specifying the Argument Name

If for some reason you need to specify an inline constructor argument dependency, and the concrete type has more than one dependency for that type, -you just need to specify the parameter name as shown in this sample:


-        public class DualConditionRule : IEventRule
-        {
-            private readonly ICondition _first;
-            private readonly ICondition _second;
-            private readonly IAction _action;
-
-            public DualConditionRule(ICondition first, ICondition second, IAction action)
-            {
-                _first = first;
-                _second = second;
-                _action = action;
-            }
-
-            public void ProcessEvent(SomeEvent @event)
-            {
-                if (_first.Matches(@event) || _second.Matches(@event))
-                {
-                    _action.PerformWork(@event);
-                }
-            }
-        }
-
-        public class DualConditionRuleRegistry : Registry
-        {
-            public DualConditionRuleRegistry()
-            {
-                // In this case, because DualConditionRule
-                // has two different
-                For<IEventRule>().Use<DualConditionRule>()
-                    .Ctor<ICondition>("first").Is<Condition1>()
-                    .Ctor<ICondition>("second").Is<Condition2>();
-            }
-        }
-
-

Setter Dependencies

You can also configure setter dependencies with a similar syntax, but with additional options to specify the property name -by using an Expression as shown below:


-        public class RuleWithSetters : IEventRule
-        {
-            public ICondition Condition { get; set; }
-            public IAction Action { get; set; }
-
-            public void ProcessEvent(SomeEvent @event)
-            {
-                if (Condition.Matches(@event))
-                {
-                    Action.PerformWork(@event);
-                }
-            }
-        }
-
-        public class RuleWithSettersRegistry : Registry
-        {
-            public RuleWithSettersRegistry()
-            {
-                For<IEventRule>().Use<RuleWithSetters>()
-                    .Setter<ICondition>().Is<Condition1>()
-
-                    // or
-                    .Setter(x => x.Action).Is(new Action1())
-
-                    // or if you need to specify the name
-                    .Setter<IAction>("Action").Is<Action2>()
-
-                    // or you can configure values *after* the object
-                    // is constructed with the SetProperty method
-                    .SetProperty(x => x.Action = new Action2());
-            }
-        }
-
-

The `Ctor` and `Setter` methods are just syntactic sugar. Both methods store data to the same underlying structure.

Enumerable Dependencies

TODO(show a sample of using enumerable dependencies)

Programmatic Configuration outside of the Registry DSL

In some cases, you may want to skip the Registry DSL and go straight for the raw dependencies structures. Let's say that -we're using an open generic type for our rules engine so that we can respond to multiple event types:


-        public interface IEventRule<TEvent>
-        {
-            void ProcessEvent(TEvent @event);
-        }
-
-        public interface ICondition<TEvent>
-        {
-            bool Matches(TEvent @event);
-        }
-
-        public class Condition1<TEvent> : ICondition<TEvent>
-        {
-            public bool Matches(TEvent @event)
-            {
-                throw new NotImplementedException();
-            }
-        }
-
-        public interface IAction<TEvent>
-        {
-            void PerformWork(TEvent @event);
-        }
-
-        public class Action1<TEvent> : IAction<TEvent>
-        {
-            public void PerformWork(TEvent @event)
-            {
-                throw new NotImplementedException();
-            }
-        }
-
-        public class EventRule<TEvent> : IEventRule<TEvent>
-        {
-            private readonly string _name;
-            private readonly ICondition<TEvent> _condition;
-            private readonly IAction<TEvent> _action;
-
-            public EventRule(string name, ICondition<TEvent> condition, IAction<TEvent> action)
-            {
-                _name = name;
-                _condition = condition;
-                _action = action;
-            }
-
-            public string Name
-            {
-                get { return _name; }
-            }
-
-            public void ProcessEvent(TEvent @event)
-            {
-                if (_condition.Matches(@event))
-                {
-                    _action.PerformWork(@event);
-                }
-            }
-        }
-
-

As an alternative approach, we could build up ConstructorInstance objects to represent our rules like so:


-        public class OpenTypesRegistry : Registry
-        {
-            public OpenTypesRegistry()
-            {
-                var instance = new ConstructorInstance(typeof(EventRule<>));
-
-                // By name
-                instance.Dependencies.Add("action", typeof(Action1<>));
-
-                // Everything else is syntactical sugur over this:
-                instance.Dependencies.Add(new Argument
-                {
-                    Type = typeof(IAction<>), // The dependency type
-                    Name = "action", // The name of the dependency, either
-                    // a constructor argument name or
-                    // the name of a setter property
-
-                    // Specify the actual dependency
-                    // This can be either a concrete type, the prebuilt value,
-                    // or an Instance
-                    Dependency = typeof(Action1<>)
-                });
-            }
-        }
-
-

It's frequently useful to explicitly configure all the elements for an enumerable argument (arrays, IEnumerable, or IList). -StructureMap provides this syntax to do just that:


-        public class BigRule : IEventRule
-        {
-            private readonly IEnumerable<ICondition> _conditions;
-            private readonly IEnumerable<IAction> _actions;
-
-            public BigRule(IEnumerable<ICondition> conditions, IEnumerable<IAction> actions)
-            {
-                _conditions = conditions;
-                _actions = actions;
-            }
-
-            public void ProcessEvent(SomeEvent @event)
-            {
-                if (_conditions.Any(x => x.Matches(@event)))
-                {
-                    _actions.Each(x => x.PerformWork(@event));
-                }
-            }
-        }
-
-        public class BigRuleRegistry : Registry
-        {
-            public BigRuleRegistry()
-            {
-                For<IEventRule>().Use<BigRule>()
-
-                    // Each line in the nested closure adds another
-                    // ICondition to the enumerable dependency in
-                    // the order in which they are configured
-                    .EnumerableOf<ICondition>().Contains(_ =>
-                    {
-                        _.Type<Condition1>();
-                        _.Type<Condition2>();
-                    })
-                    .EnumerableOf<IAction>().Contains(_ =>
-                    {
-                        _.Type<Action1>();
-                        _.Object(new Action2());
-                    });
-            }
-        }
-
-

- + + +

While you generally allow StructureMap to just use auto-wiring to fill the dependencies of a concrete type, there are times +when you may want to explicitly configure individual dependencies on a case by case basis. In the case of primitive types +like strings or numbers, StructureMap will not do any auto-wiring, so it's incumbent upon you the user to supply the dependency.

Let's say we have a simple class called ColorWidget like the following:


public class ColorWidget : IWidget
{
    public string Color { get; set; }

    public ColorWidget(string color)
    {
        Color = color;
    }
}

To register the ColorWidget, you would supply the value of the color parameter to the constructor function like so:


[Fact]
public void inline_usage_of_primitive_constructor_argument()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Use<ColorWidget>()
            .Ctor<string>().Is("Red");
    });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<ColorWidget>()
        .Color.ShouldBe("Red");
}

+The most common reason to define string arguments to classes seems to be passing in database connection strings or occasional file paths. +I used this strategy very commonly in the early days of StructureMap, but for the past 5-6 years I strongly prefer to use Settings classes +to inject configuration through StructureMap. +

Event Condition Action Rules

To make that concrete and establish a sample problem domain, consider these types:


public class SomeEvent
{
}

public interface ICondition
{
    bool Matches(SomeEvent @event);
}

public interface IAction
{
    void PerformWork(SomeEvent @event);
}

public interface IEventRule
{
    void ProcessEvent(SomeEvent @event);
}

Now, let's move on to seeing how we could use inline dependency configuration to register new rules.

Constructor Parameters by Type

First off, let's say that we have a SimpleRule that takes a single condition and action:


public class SimpleRule : IEventRule
{
    private readonly ICondition _condition;
    private readonly IAction _action;

    public SimpleRule(ICondition condition, IAction action)
    {
        _condition = condition;
        _action = action;
    }

    public void ProcessEvent(SomeEvent @event)
    {
        if (_condition.Matches(@event))
        {
            _action.PerformWork(@event);
        }
    }
}

Now, since SimpleRule has only a single dependency on both IAction and ICondition, we can create new rules by registering new Instance's +of SimpleRule with different combinations of its dependencies:


public class InlineCtorArgs : Registry
{
    public InlineCtorArgs()
    {
        // Defining args by type
        For<IEventRule>().Use<SimpleRule>()
            .Ctor<ICondition>().Is<Condition1>()
            .Ctor<IAction>().Is<Action1>()
            .Named("One");

        // Pass the explicit values for dependencies
        For<IEventRule>().Use<SimpleRule>()
            .Ctor<ICondition>().Is(new Condition2())
            .Ctor<IAction>().Is(new Action2())
            .Named("Two");

        // Use Lambda construction
        For<IEventRule>().Use<SimpleRule>()
            .Ctor<ICondition>().Is(() => new Condition3())
            .Ctor<IAction>().Is("some crazy builder", c => c.GetInstance<Action3>())
            .Named("Three");

        // Rarely used, but gives you a "do any crazy thing" option
        // Pass in your own Instance object
        For<IEventRule>().Use<SimpleRule>()
            .Ctor<IAction>().Is(new MySpecialActionInstance());

        // Inline configuration of your dependency's dependencies

        For<IEventRule>().Use<SimpleRule>()
            .Ctor<ICondition>().IsSpecial(_ => _.Type<BigCondition>().Ctor<int>().Is(100))

            // or
            .Ctor<ICondition>().Is(new SmartInstance<BigCondition>().Ctor<int>().Is(100));
    }

    public class BigCondition : ICondition
    {
        public BigCondition(int number)
        {
        }

        public bool Matches(SomeEvent @event)
        {
            throw new NotImplementedException();
        }
    }

    public class MySpecialActionInstance : LambdaInstance<Action3>
    {
        public MySpecialActionInstance()
            : base(() => new Action3())
        {
        }
    }
}

Specifying the Argument Name

If for some reason you need to specify an inline constructor argument dependency, and the concrete type has more than one dependency for that type, +you just need to specify the parameter name as shown in this sample:


public class DualConditionRule : IEventRule
{
    private readonly ICondition _first;
    private readonly ICondition _second;
    private readonly IAction _action;

    public DualConditionRule(ICondition first, ICondition second, IAction action)
    {
        _first = first;
        _second = second;
        _action = action;
    }

    public void ProcessEvent(SomeEvent @event)
    {
        if (_first.Matches(@event) || _second.Matches(@event))
        {
            _action.PerformWork(@event);
        }
    }
}

public class DualConditionRuleRegistry : Registry
{
    public DualConditionRuleRegistry()
    {
        // In this case, because DualConditionRule
        // has two different
        For<IEventRule>().Use<DualConditionRule>()
            .Ctor<ICondition>("first").Is<Condition1>()
            .Ctor<ICondition>("second").Is<Condition2>();
    }
}

Setter Dependencies

You can also configure setter dependencies with a similar syntax, but with additional options to specify the property name +by using an Expression as shown below:


public class RuleWithSetters : IEventRule
{
    public ICondition Condition { get; set; }
    public IAction Action { get; set; }

    public void ProcessEvent(SomeEvent @event)
    {
        if (Condition.Matches(@event))
        {
            Action.PerformWork(@event);
        }
    }
}

public class RuleWithSettersRegistry : Registry
{
    public RuleWithSettersRegistry()
    {
        For<IEventRule>().Use<RuleWithSetters>()
            .Setter<ICondition>().Is<Condition1>()

            // or
            .Setter(x => x.Action).Is(new Action1())

            // or if you need to specify the name
            .Setter<IAction>("Action").Is<Action2>()

            // or you can configure values *after* the object
            // is constructed with the SetProperty method
            .SetProperty(x => x.Action = new Action2());
    }
}

The `Ctor` and `Setter` methods are just syntactic sugar. Both methods store data to the same underlying structure.

Enumerable Dependencies

TODO(show a sample of using enumerable dependencies)

Programmatic Configuration outside of the Registry DSL

In some cases, you may want to skip the Registry DSL and go straight for the raw dependencies structures. Let's say that +we're using an open generic type for our rules engine so that we can respond to multiple event types:


public interface IEventRule<TEvent>
{
    void ProcessEvent(TEvent @event);
}

public interface ICondition<TEvent>
{
    bool Matches(TEvent @event);
}

public class Condition1<TEvent> : ICondition<TEvent>
{
    public bool Matches(TEvent @event)
    {
        throw new NotImplementedException();
    }
}

public interface IAction<TEvent>
{
    void PerformWork(TEvent @event);
}

public class Action1<TEvent> : IAction<TEvent>
{
    public void PerformWork(TEvent @event)
    {
        throw new NotImplementedException();
    }
}

public class EventRule<TEvent> : IEventRule<TEvent>
{
    private readonly string _name;
    private readonly ICondition<TEvent> _condition;
    private readonly IAction<TEvent> _action;

    public EventRule(string name, ICondition<TEvent> condition, IAction<TEvent> action)
    {
        _name = name;
        _condition = condition;
        _action = action;
    }

    public string Name
    {
        get { return _name; }
    }

    public void ProcessEvent(TEvent @event)
    {
        if (_condition.Matches(@event))
        {
            _action.PerformWork(@event);
        }
    }
}

As an alternative approach, we could build up ConstructorInstance objects to represent our rules like so:


public class OpenTypesRegistry : Registry
{
    public OpenTypesRegistry()
    {
        var instance = new ConstructorInstance(typeof(EventRule<>));

        // By name
        instance.Dependencies.Add("action", typeof(Action1<>));

        // Everything else is syntactical sugur over this:
        instance.Dependencies.Add(new Argument
        {
            Type = typeof(IAction<>), // The dependency type
            Name = "action", // The name of the dependency, either
            // a constructor argument name or
            // the name of a setter property

            // Specify the actual dependency
            // This can be either a concrete type, the prebuilt value,
            // or an Instance
            Dependency = typeof(Action1<>)
        });
    }
}

It's frequently useful to explicitly configure all the elements for an enumerable argument (arrays, IEnumerable, or IList). +StructureMap provides this syntax to do just that:


public class BigRule : IEventRule
{
    private readonly IEnumerable<ICondition> _conditions;
    private readonly IEnumerable<IAction> _actions;

    public BigRule(IEnumerable<ICondition> conditions, IEnumerable<IAction> actions)
    {
        _conditions = conditions;
        _actions = actions;
    }

    public void ProcessEvent(SomeEvent @event)
    {
        if (_conditions.Any(x => x.Matches(@event)))
        {
            _actions.Each(x => x.PerformWork(@event));
        }
    }
}

public class BigRuleRegistry : Registry
{
    public BigRuleRegistry()
    {
        For<IEventRule>().Use<BigRule>()

            // Each line in the nested closure adds another
            // ICondition to the enumerable dependency in
            // the order in which they are configured
            .EnumerableOf<ICondition>().Contains(_ =>
            {
                _.Type<Condition1>();
                _.Type<Condition2>();
            })
            .EnumerableOf<IAction>().Contains(_ =>
            {
                _.Type<Action1>();
                _.Object(new Action2());
            });
    }
}

@@ -88,207 +88,48 @@

On Missing Family Policies - - -

New for StructureMap 3.0 is a feature to create missing service registrations at runtime based on pluggable rules using the new IFamilyPolicy -interface:


-
-    /// <summary>
-    /// Allows StructureMap to fill in missing registrations by unknown plugin types
-    /// at runtime
-    /// </summary>
-    public interface IFamilyPolicy
-    {
-        /// <summary>
-        /// Allows you to create missing registrations for an unknown plugin type
-        /// at runtime.
-        /// Return null if this policy does not apply to the given type
-        /// </summary>
-        PluginFamily Build(Type type);
-
-        /// <summary>
-        /// Should this policy be used to determine whether or not the Container has
-        /// registrations for a plugin type in the PluginGraph.HasFamily(type) method
-        /// </summary>
-        bool AppliesToHasFamilyChecks { get; }
-    }
-

Internally, if you make a request to IContainer.GetInstance(type) for a type that the active Container does not recognize, StructureMap will next -try to apply all the registered IFamilyPolicy policies to create a PluginFamily object for that plugin type that models the registrations for that plugin type, including the default, additional named instances, interceptors or decorators, and lifecycle rules.

The simplest built in example is the EnumerableFamilyPolicy shown below that can fill in requests for IList<T>, ICollection<T>, and T[] with a collection of all the known registrations of the type T:


-    public class EnumerableFamilyPolicy : IFamilyPolicy
-    {
-        public PluginFamily Build(Type type)
-        {
-            if (EnumerableInstance.IsEnumerable(type))
-            {
-                var family = new PluginFamily(type);
-                family.SetDefault(new AllPossibleInstance(type));
-
-                return family;
-            }
-
-            return null;
-        }
-
-        public bool AppliesToHasFamilyChecks
-        {
-            get
-            {
-                return false;
-            }
-            
-        }
-    }
-

The result of EnumerableFamilyPolicy in action is shown by the acceptance test below:


-        [Fact]
-        public void collection_types_are_all_possible_by_default()
-        {
-            // NOTE that we do NOT make any explicit registration of
-            // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[]
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Add<AWidget>();
-                _.For<IWidget>().Add<BWidget>();
-                _.For<IWidget>().Add<CWidget>();
-            });
-
-            // IList<T>
-            container.GetInstance<IList<IWidget>>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-
-            // ICollection<T>
-            container.GetInstance<ICollection<IWidget>>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-
-            // Array of T
-            container.GetInstance<IWidget[]>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-        }
-
-

See also the Handling Missing Named Instances for runtime determination of named instances within a known plugin type.

Built In Policies

StructureMap and StructureMap.AutoMocking use several IFamilyPolicy rules internally to create default behavior. In all cases, any custom -IFamilyPolicy rule that you explicitly add to a Container will be evaluated before the built in policies.

CloseGenericFamilyPolicy - -uses the registration for an open type as a template to create the registrations for a closed type the first time StructureMap encounters -that closed type. See Generic Types for more information.
FuncBuildByNamePolicy - -Used internally to create registrations for Func<string, T> builders.
EnumerableFamilyPolicy - -Shown above.
AutoMockedContainer - -Used by StructureMap.AutoMocking to create registrations on the fly that just return a mock object for the requested plugin type.

Using a Custom IFamilyPolicy" id="custom">

FubuMVC 2.0 (still unreleased to the public as of yet, but in production usage) uses a custom family policy in its StructureMap -integration to auto-resolve concrete configuration types like the following type:


-    public class SomeSettings
-    {
-        public string ThisDirectory { get; set; }
-        public string ThatDirectory { get; set; }
-    }
-
-

Unless the system using this object has explicitly registered SomeSettings, we want StructureMap to resolve this object by -using data from the basic .Net appSettings collection to create a SomeSettings object.

For the sake of the example, assume that you have a functioning service that implements this interface below:


-    public interface ISettingsProvider
-    {
-        T SettingsFor<T>() where T : class, new();
-
-        object SettingsFor(Type settingsType);
-    }
-
-    public class AppSettingsProvider : ISettingsProvider
-    {
-        public T SettingsFor<T>() where T : class, new()
-        {
-            return SettingsFor(typeof (T)).As<T>();
-        }
-
-        public object SettingsFor(Type settingsType)
-        {
-            // The real one reads key/value data from
-            // the appSettings and uses FubuCore's
-            // model binding to assign data to a new
-            // object of settingsType
-            return null;
-        }
-    }
-
-

Assuming that ISettingsProvider is registered in your StructureMap Container, you could then craft a custom -IFamilyPolicy class like this:


-    public class SettingPolicy : IFamilyPolicy
-    {
-        public PluginFamily Build(Type type)
-        {
-            if (type.Name.EndsWith("Settings") && type.IsConcreteWithDefaultCtor())
-            {
-                var family = new PluginFamily(type);
-                var instance = buildInstanceForType(type);
-                family.SetDefault(instance);
-
-                return family;
-            }
-
-            return null;
-        }
-
-        public bool AppliesToHasFamilyChecks
-        {
-            get { return true; }
-        }
-
-
-        private static Instance buildInstanceForType(Type type)
-        {
-            var instanceType = typeof (SettingsInstance<>).MakeGenericType(type);
-            var instance = Activator.CreateInstance(instanceType).As<Instance>();
-            return instance;
-        }
-    }
-
-    // SettingsInstance just uses the registered service for ISettingsProvider to
-    // build the real object
-    public class SettingsInstance<T> : LambdaInstance<T> where T : class, new()
-    {
-        public SettingsInstance() : base("Building {0} from application settings".ToFormat(typeof (T).FullName),
-            c => c.GetInstance<ISettingsProvider>().SettingsFor<T>())
-        {
-        }
-    }
-
-

SettingPolicy is able to create a registration on the fly for any concrete type whose name ends in "Settings" and has a default, no arg -constructor.

To use register the custom SettingPolicy, use one of the Registry.Policies.OnMissingFamily() methods:


-    public class SettingsRegistry : Registry
-    {
-        public SettingsRegistry()
-        {
-            For<ISettingsProvider>().Use<AppSettingsProvider>();
-            Policies.OnMissingFamily<SettingPolicy>();
-        }
-    }
-
-

You can see the real implementation of the SettingPolicy in action in its integration tests on GitHub.

- + + +

New for StructureMap 3.0 is a feature to create missing service registrations at runtime based on pluggable rules using the new IFamilyPolicy +interface:



/// <summary>
/// Allows StructureMap to fill in missing registrations by unknown plugin types
/// at runtime
/// </summary>
public interface IFamilyPolicy
{
    /// <summary>
    /// Allows you to create missing registrations for an unknown plugin type
    /// at runtime.
    /// Return null if this policy does not apply to the given type
    /// </summary>
    PluginFamily Build(Type type);

    /// <summary>
    /// Should this policy be used to determine whether or not the Container has
    /// registrations for a plugin type in the PluginGraph.HasFamily(type) method
    /// </summary>
    bool AppliesToHasFamilyChecks { get; }
}

Internally, if you make a request to IContainer.GetInstance(type) for a type that the active Container does not recognize, StructureMap will next +try to apply all the registered IFamilyPolicy policies to create a PluginFamily object for that plugin type that models the registrations for that plugin type, including the default, additional named instances, interceptors or decorators, and lifecycle rules.


public class EnumerableFamilyPolicy : IFamilyPolicy
{
    public PluginFamily Build(Type type)
    {
        if (EnumerableInstance.IsEnumerable(type))
        {
            var family = new PluginFamily(type);
            family.SetDefault(new AllPossibleInstance(type));

            return family;
        }

        return null;
    }

    public bool AppliesToHasFamilyChecks
    {
        get
        {
            return false;
        }
        
    }
}

The result of EnumerableFamilyPolicy in action is shown by the acceptance test below:


[Fact]
public void collection_types_are_all_possible_by_default()
{
    // NOTE that we do NOT make any explicit registration of
    // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[]
    var container = new Container(_ =>
    {
        _.For<IWidget>().Add<AWidget>();
        _.For<IWidget>().Add<BWidget>();
        _.For<IWidget>().Add<CWidget>();
    });

    // IList<T>
    container.GetInstance<IList<IWidget>>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // ICollection<T>
    container.GetInstance<ICollection<IWidget>>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // Array of T
    container.GetInstance<IWidget[]>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
}

See also the Handling Missing Named Instances for runtime determination of named instances within a known plugin type.

Built In Policies

StructureMap and StructureMap.AutoMocking use several IFamilyPolicy rules internally to create default behavior. In all cases, any custom +IFamilyPolicy rule that you explicitly add to a Container will be evaluated before the built in policies.

CloseGenericFamilyPolicy - +uses the registration for an open type as a template to create the registrations for a closed type the first time StructureMap encounters +that closed type. See Generic Types for more information.
FuncBuildByNamePolicy - +Used internally to create registrations for Func<string, T> builders.
EnumerableFamilyPolicy - +Shown above.
AutoMockedContainer - +Used by StructureMap.AutoMocking to create registrations on the fly that just return a mock object for the requested plugin type.

Using a Custom IFamilyPolicy" id="custom">

FubuMVC 2.0 (still unreleased to the public as of yet, but in production usage) uses a custom family policy in its StructureMap +integration to auto-resolve concrete configuration types like the following type:


public class SomeSettings
{
    public string ThisDirectory { get; set; }
    public string ThatDirectory { get; set; }
}

Unless the system using this object has explicitly registered SomeSettings, we want StructureMap to resolve this object by +using data from the basic .Net appSettings collection to create a SomeSettings object.

For the sake of the example, assume that you have a functioning service that implements this interface below:


public interface ISettingsProvider
{
    T SettingsFor<T>() where T : class, new();

    object SettingsFor(Type settingsType);
}

public class AppSettingsProvider : ISettingsProvider
{
    public T SettingsFor<T>() where T : class, new()
    {
        return SettingsFor(typeof (T)).As<T>();
    }

    public object SettingsFor(Type settingsType)
    {
        // The real one reads key/value data from
        // the appSettings and uses FubuCore's
        // model binding to assign data to a new
        // object of settingsType
        return null;
    }
}

Assuming that ISettingsProvider is registered in your StructureMap Container, you could then craft a custom +IFamilyPolicy class like this:


public class SettingPolicy : IFamilyPolicy
{
    public PluginFamily Build(Type type)
    {
        if (type.Name.EndsWith("Settings") && type.IsConcreteWithDefaultCtor())
        {
            var family = new PluginFamily(type);
            var instance = buildInstanceForType(type);
            family.SetDefault(instance);

            return family;
        }

        return null;
    }

    public bool AppliesToHasFamilyChecks
    {
        get { return true; }
    }


    private static Instance buildInstanceForType(Type type)
    {
        var instanceType = typeof (SettingsInstance<>).MakeGenericType(type);
        var instance = Activator.CreateInstance(instanceType).As<Instance>();
        return instance;
    }
}

// SettingsInstance just uses the registered service for ISettingsProvider to
// build the real object
public class SettingsInstance<T> : LambdaInstance<T> where T : class, new()
{
    public SettingsInstance() : base("Building {0} from application settings".ToFormat(typeof (T).FullName),
        c => c.GetInstance<ISettingsProvider>().SettingsFor<T>())
    {
    }
}

SettingPolicy is able to create a registration on the fly for any concrete type whose name ends in "Settings" and has a default, no arg +constructor.

To use register the custom SettingPolicy, use one of the Registry.Policies.OnMissingFamily() methods:


public class SettingsRegistry : Registry
{
    public SettingsRegistry()
    {
        For<ISettingsProvider>().Use<AppSettingsProvider>();
        Policies.OnMissingFamily<SettingPolicy>();
    }
}

You can see the real implementation of the SettingPolicy in action in its integration tests on GitHub.

@@ -94,32 +94,10 @@

Construction Policies interception policies. The 4.0 release extends StructureMap's support for conventional build policies with a new mechanism for altering how object instances are built based on user created meta-conventions using the IInstancePolicy shown below:


-    /// <summary>
-    /// Custom policy on Instance construction that is evaluated
-    /// as part of creating a "build plan"
-    /// </summary>
-    public interface IInstancePolicy
-    {
-        /// <summary>
-        /// Apply any conventional changes to the configuration
-        /// of a single Instance
-        /// </summary>
-        /// <param name="pluginType"></param>
-        /// <param name="instance"></param>
-        void Apply(Type pluginType, Instance instance);
-    }
-


/// <summary>
/// Custom policy on Instance construction that is evaluated
/// as part of creating a "build plan"
/// </summary>
public interface IInstancePolicy
{
    /// <summary>
    /// Apply any conventional changes to the configuration
    /// of a single Instance
    /// </summary>
    /// <param name="pluginType"></param>
    /// <param name="instance"></param>
    void Apply(Type pluginType, Instance instance);
}

These policies are registered as part of the registry dsl with the Policies.Add() method:


-            var container = new Container(_ =>
-            {
-                _.Policies.Add<MyCustomPolicy>();
-                // or
-                _.Policies.Add(new MyCustomPolicy());
-            });
-


var container = new Container(_ =>
{
    _.Policies.Add<MyCustomPolicy>();
    // or
    _.Policies.Add(new MyCustomPolicy());
});

The IInstancePolicy mechanism probably works differently than other IoC containers in that the policy is applied to the container's underlying configuration model instead of at runtime. Internally, StructureMap lazily creates a "build plan" for each configured Instance at the first time @@ -131,278 +109,65 @@

Construction Policies - public abstract class ConfiguredInstancePolicy : IInstancePolicy - { - /// <summary> - /// Applies explicit configuration to an IConfiguredInstance - /// </summary> - /// <param name="pluginType"></param> - /// <param name="instance"></param> - public void Apply(Type pluginType, Instance instance) - { - var configured = instance as IConfiguredInstance; - if (configured != null) - { - apply(pluginType, configured); - } - } - - /// <summary> - /// This method is called against any Instance that implements the - /// IConfiguredInstance interface - /// </summary> - /// <param name="pluginType"></param> - /// <param name="instance"></param> - protected abstract void apply(Type pluginType, IConfiguredInstance instance); - } - +


public abstract class ConfiguredInstancePolicy : IInstancePolicy
{
    /// <summary>
    /// Applies explicit configuration to an IConfiguredInstance
    /// </summary>
    /// <param name="pluginType"></param>
    /// <param name="instance"></param>
    public void Apply(Type pluginType, Instance instance)
    {
        var configured = instance as IConfiguredInstance;
        if (configured != null)
        {
            apply(pluginType, configured);
        }
    }

    /// <summary>
    /// This method is called against any Instance that implements the
    /// IConfiguredInstance interface
    /// </summary>
    /// <param name="pluginType"></param>
    /// <param name="instance"></param>
    protected abstract void apply(Type pluginType, IConfiguredInstance instance);
}

For more information, see:

Example 1: Constructor arguments

So let me say upfront that I don't like this approach, but other folks have asked for this ability over the years. Say that you have some legacy code where many concrete classes have a constructor argument called "connectionString" that needs to be the connection string to the application database like these classes:


-        public class DatabaseUser
-        {
-            public string ConnectionString { get; set; }
-
-            public DatabaseUser(string connectionString)
-            {
-                ConnectionString = connectionString;
-            }
-        }
-
-        public class ConnectedThing
-        {
-            public string ConnectionString { get; set; }
-
-            public ConnectedThing(string connectionString)
-            {
-                ConnectionString = connectionString;
-            }
-        }
-
-


public class DatabaseUser
{
    public string ConnectionString { get; set; }

    public DatabaseUser(string connectionString)
    {
        ConnectionString = connectionString;
    }
}

public class ConnectedThing
{
    public string ConnectionString { get; set; }

    public ConnectedThing(string connectionString)
    {
        ConnectionString = connectionString;
    }
}

Instead of explicitly configuring every single concrete class in StructureMap with that inline constructor argument, we can make a policy to do that in one place:


-        public class ConnectionStringPolicy : ConfiguredInstancePolicy
-        {
-            protected override void apply(Type pluginType, IConfiguredInstance instance)
-            {
-                var parameter = instance.Constructor.GetParameters().FirstOrDefault(x => x.Name == "connectionString");
-                if (parameter != null)
-                {
-                    var connectionString = findConnectionStringFromConfiguration();
-                    instance.Dependencies.AddForConstructorParameter(parameter, connectionString);
-                }
-            }
-
-            // find the connection string from whatever configuration
-            // strategy your application uses
-            private string findConnectionStringFromConfiguration()
-            {
-                return "the connection string";
-            }
-        }
-
-


public class ConnectionStringPolicy : ConfiguredInstancePolicy
{
    protected override void apply(Type pluginType, IConfiguredInstance instance)
    {
        var parameter = instance.Constructor.GetParameters().FirstOrDefault(x => x.Name == "connectionString");
        if (parameter != null)
        {
            var connectionString = findConnectionStringFromConfiguration();
            instance.Dependencies.AddForConstructorParameter(parameter, connectionString);
        }
    }

    // find the connection string from whatever configuration
    // strategy your application uses
    private string findConnectionStringFromConfiguration()
    {
        return "the connection string";
    }
}

Now, let's use that policy against the types that need "connectionString" and see what happens:


-        [Fact]
-        public void use_the_connection_string_policy()
-        {
-            var container = new Container(_ =>
-            {
-                _.Policies.Add<ConnectionStringPolicy>();
-            });
-
-            container.GetInstance<DatabaseUser>()
-                .ConnectionString.ShouldBe("the connection string");
-
-            container.GetInstance<ConnectedThing>()
-                .ConnectionString.ShouldBe("the connection string");
-        }
-
-


[Fact]
public void use_the_connection_string_policy()
{
    var container = new Container(_ =>
    {
        _.Policies.Add<ConnectionStringPolicy>();
    });

    container.GetInstance<DatabaseUser>()
        .ConnectionString.ShouldBe("the connection string");

    container.GetInstance<ConnectedThing>()
        .ConnectionString.ShouldBe("the connection string");
}

Years ago StructureMap was knocked by an "IoC expert" for not having this functionality. I said at the time -- and still would -- that I would strongly recommend that you simply don't directly open database connections in more than one or a very few spots in your code anyway. If I did need to configure a database connection string in multiple concrete classes, I prefer strong typed configuration.

Example 2: Connecting to Databases based on Parameter Name

From another common user request over the years, let's say that your application needs to connect to multiple databases, but your data access service in both cases is an interface called IDatabase, and that's all the consumers of any database should ever need to know.

To make this concrete, let's say that our data access is all behind an interface and concrete class pair named Database/IDatabase like so:


-        public interface IDatabase { }
-
-        public class Database : IDatabase
-        {
-            public string ConnectionString { get; set; }
-
-            public Database(string connectionString)
-            {
-                ConnectionString = connectionString;
-            }
-
-            public override string ToString()
-            {
-                return string.Format("ConnectionString: {0}", ConnectionString);
-            }
-        }
-
-


public interface IDatabase { }

public class Database : IDatabase
{
    public string ConnectionString { get; set; }

    public Database(string connectionString)
    {
        ConnectionString = connectionString;
    }

    public override string ToString()
    {
        return string.Format("ConnectionString: {0}", ConnectionString);
    }
}

For a registration policy, let's say that the parameter name of an IDatabase dependency in a constructor function should match an identifier of one of the registered IDatabase services. That policy would be:


-        public class InjectDatabaseByName : ConfiguredInstancePolicy
-        {
-            protected override void apply(Type pluginType, IConfiguredInstance instance)
-            {
-                instance.Constructor.GetParameters()
-                    .Where(x => x.ParameterType == typeof(IDatabase))
-                    .Each(param =>
-                    {
-                        // Using ReferencedInstance here tells StructureMap
-                        // to "use the IDatabase by this name"
-                        var db = new ReferencedInstance(param.Name);
-                        instance.Dependencies.AddForConstructorParameter(param, db);
-                    });
-            }
-        }
-
-


public class InjectDatabaseByName : ConfiguredInstancePolicy
{
    protected override void apply(Type pluginType, IConfiguredInstance instance)
    {
        instance.Constructor.GetParameters()
            .Where(x => x.ParameterType == typeof(IDatabase))
            .Each(param =>
            {
                // Using ReferencedInstance here tells StructureMap
                // to "use the IDatabase by this name"
                var db = new ReferencedInstance(param.Name);
                instance.Dependencies.AddForConstructorParameter(param, db);
            });
    }
}

And because I'm generally pretty boring about picking test data names, let's say that two of our databases are named "red" and "green" with this container registration below:


-            var container = new Container(_ =>
-            {
-                _.For<IDatabase>().Add<Database>().Named("red")
-                    .Ctor<string>("connectionString").Is("*red*");
-
-                _.For<IDatabase>().Add<Database>().Named("green")
-                    .Ctor<string>("connectionString").Is("*green*");
-
-                _.Policies.Add<InjectDatabaseByName>();
-            });
-


var container = new Container(_ =>
{
    _.For<IDatabase>().Add<Database>().Named("red")
        .Ctor<string>("connectionString").Is("*red*");

    _.For<IDatabase>().Add<Database>().Named("green")
        .Ctor<string>("connectionString").Is("*green*");

    _.Policies.Add<InjectDatabaseByName>();
});

For more context, the classes that use IDatabase would need to have constructor functions like these below:


-        public class BigService
-        {
-            public BigService(IDatabase green)
-            {
-                DB = green;
-            }
-
-            public IDatabase DB { get; set; }
-        }
-
-        public class ImportantService
-        {
-            public ImportantService(IDatabase red)
-            {
-                DB = red;
-            }
-
-            public IDatabase DB { get; set; }
-        }
-
-        public class DoubleDatabaseUser
-        {
-            public DoubleDatabaseUser(IDatabase red, IDatabase green)
-            {
-                Red = red;
-                Green = green;
-            }
-
-            // Watch out for potential conflicts between setters
-            // and ctor params. The easiest thing is to just make
-            // setters private
-            public IDatabase Green { get; private set; }
-
-            public IDatabase Red { get; private set; }
-        }
-
-


public class BigService
{
    public BigService(IDatabase green)
    {
        DB = green;
    }

    public IDatabase DB { get; set; }
}

public class ImportantService
{
    public ImportantService(IDatabase red)
    {
        DB = red;
    }

    public IDatabase DB { get; set; }
}

public class DoubleDatabaseUser
{
    public DoubleDatabaseUser(IDatabase red, IDatabase green)
    {
        Red = red;
        Green = green;
    }

    // Watch out for potential conflicts between setters
    // and ctor params. The easiest thing is to just make
    // setters private
    public IDatabase Green { get; private set; }

    public IDatabase Red { get; private set; }
}

Finally, we can exercise our new policy and see it in action:


-            // ImportantService should get the "red" database
-            container.GetInstance<ImportantService>()
-                .DB.As<Database>().ConnectionString.ShouldBe("*red*");
-
-            // BigService should get the "green" database
-            container.GetInstance<BigService>()
-                .DB.As<Database>().ConnectionString.ShouldBe("*green*");
-
-            // DoubleDatabaseUser gets both
-            var user = container.GetInstance<DoubleDatabaseUser>();
-
-            user.Green.As<Database>().ConnectionString.ShouldBe("*green*");
-            user.Red.As<Database>().ConnectionString.ShouldBe("*red*");
-


// ImportantService should get the "red" database
container.GetInstance<ImportantService>()
    .DB.As<Database>().ConnectionString.ShouldBe("*red*");

// BigService should get the "green" database
container.GetInstance<BigService>()
    .DB.As<Database>().ConnectionString.ShouldBe("*green*");

// DoubleDatabaseUser gets both
var user = container.GetInstance<DoubleDatabaseUser>();

user.Green.As<Database>().ConnectionString.ShouldBe("*green*");
user.Red.As<Database>().ConnectionString.ShouldBe("*red*");

How I prefer to do this - my strong preference would be to use separate interfaces for the different databases even if that type is just an empty type marker that implements the same base. I feel like using separate interfaces makes the code easier to trace and understand than trying to make StructureMap vary dependencies based on naming conventions or what namespace a concrete type happens to be in. At least now though, you have the choice of my way or using policies based on naming conventions.

Example 3: Make objects singletons based on type name

Unlike the top two examples, this is taken from a strategy that I used in FubuMVC for its service registration. In that case, we wanted any concrete type whose name ended with "Cache" to be a singleton in the container registration. With the new IInstancePolicy feature in StructureMap 4, we could create a new policy class like so:


-        public class CacheIsSingleton : IInstancePolicy
-        {
-            public void Apply(Type pluginType, Instance instance)
-            {
-                if (instance.ReturnedType.Name.EndsWith("Cache"))
-                {
-                    instance.SetLifecycleTo<SingletonLifecycle>();
-                }
-            }
-        }
-
-

Now, let's say that we have an interface named IWidgets and a single implementation called WidgetCache that -should track our widgets in the application. Using our new policy, we should see WidgetCache being -made a singleton:


-        [Fact]
-        public void set_cache_to_singleton()
-        {
-            var container = new Container(_ =>
-            {
-                _.Policies.Add<CacheIsSingleton>();
-
-                _.For<IWidgets>().Use<WidgetCache>();
-            });
-
-            // The policy is applied *only* at the time
-            // that StructureMap creates a "build plan"
-            container.GetInstance<IWidgets>()
-                .ShouldBeTheSameAs(container.GetInstance<IWidgets>());
-
-            // Now that the policy has executed, we
-            // can verify that WidgetCache is a SingletonThing
-            container.Model.For<IWidgets>().Default
-                .Lifecycle.ShouldBeOfType<SingletonLifecycle>();
-        }
-
-

- +


public class CacheIsSingleton : IInstancePolicy
{
    public void Apply(Type pluginType, Instance instance)
    {
        if (instance.ReturnedType.Name.EndsWith("Cache"))
        {
            instance.SetLifecycleTo<SingletonLifecycle>();
        }
    }
}

+ +Now, let's say that we have an interface named `IWidgets` and a single implementation called `WidgetCache` that +should track our widgets in the application. Using our new policy, we should see `WidgetCache` being +made a singleton: + +


[Fact]
public void set_cache_to_singleton()
{
    var container = new Container(_ =>
    {
        _.Policies.Add<CacheIsSingleton>();

        _.For<IWidgets>().Use<WidgetCache>();
    });

    // The policy is applied *only* at the time
    // that StructureMap creates a "build plan"
    container.GetInstance<IWidgets>()
        .ShouldBeTheSameAs(container.GetInstance<IWidgets>());

    // Now that the policy has executed, we
    // can verify that WidgetCache is a SingletonThing
    container.Model.For<IWidgets>().Default
        .Lifecycle.ShouldBeOfType<SingletonLifecycle>();
}

@@ -88,183 +88,55 @@

Registry DSL - - -
Creating `Registry` classes is the recommended way of using the Registry DSL.
-
The Registry DSL is mostly a fluent interface with some nested closure -usage. The intent of the Registry DSL is to make the configuration process as -error free as possible by using "compiler safe" expressions and defensive -programming to point out missing data.
-

The Registry Class

On all but the smallest systems, the main unit of configuration will probably be -the Registry class. Typically, you would subclass the Registry class, then -use the fluent interface methods exposed by the Registry class to create Container -configuration. Here's a sample Registry class below used to configure an -instance of an IWidget interface:


-        public class PurpleRegistry : Registry
-        {
-            public PurpleRegistry()
-            {
-                For<IWidget>().Use<AWidget>();
-            }
-        }
-
-

Including Registries

The next question is "how does my new Registry class get used?"

When you set up a Container, you need to simply direct the -Container to use the configuration in that Registry class:


-        [Fact]
-        public void include_a_registry()
-        {
-            var registry = new Registry();
-            registry.IncludeRegistry<YellowBlueRegistry>();
-            registry.IncludeRegistry<RedGreenRegistry>();
-            registry.IncludeRegistry<PurpleRegistry>();
-            // build a container
-            var container = new Container(registry);
-            // verify the default implementation and total registered implementations
-            container.GetInstance<IWidget>().ShouldBeOfType<AWidget>();
-            container.GetAllInstances<IWidget>().Count().ShouldBe(5);
-        }
-
-

Use versus Add

Registrations in the Registry DSL can be done with either Add() or Use() methods, but they have -a different semantic meaning to StructureMap. Add() means add another Instance to this plugin type -while Use() means this one is the default.

One of the things that is different about StructureMap is that if it has multiple registrations of any -given plugin type, one of these registrations has to be explicitly marked as the default usage for that plugin type -or StructureMap will blow up in the call to Container.GetInstance(). Other IoC tools will magically use -the first registration or the last registration (and some even allow you to configure that behavior). We chose to -make that determination be explicit.

As of StructureMap 3.0, the WhatDoIHave() output is part of any exception thrown by StructureMap when -it cannot determine a default registration for a requested type if there is more than one registration for that -type.

If there are multiple calls to Use() for the same plugin type, the last one wins. For more control over this behavior in -modularity scenarios, see Fallback Services and Replace or Clear Out Previous Registrations.

For().Use()

To register the default Instance of a type, the syntax is one of the Registry.For().Use() overloads shown below:


-    public class SettingDefaults : Registry
-    {
-        public SettingDefaults()
-        {
-            // If you know the plugin type and its a closed type
-            // you can use this syntax
-            For<IWidget>().Use<DefaultWidget>();
-
-            // By Lambda
-            For<IWidget>().Use(() => new DefaultWidget());
-
-            // Pre-existing object
-            For<IWidget>().Use(new AWidget());
-
-            // This is rare now, but still valid
-            For<IWidget>().Add<AWidget>().Named("A");
-            For<IWidget>().Add<BWidget>().Named("B");
-            For<IWidget>().Use("A"); // makes AWidget the default
-
-            // Also rare, but you can supply an Instance object
-            // yourself for special needs
-            For<IWidget>().UseInstance(new MySpecialInstance());
-
-            // If you're registering an open generic type
-            // or you just have Type objects, use this syntax
-            For(typeof (IService<>)).Use(typeof (Service<>));
-
-            // This is occasionally useful for generic types
-            For(typeof (IService<>)).Use(new MySpecialInstance());
-        }
-    }
-

For().Add()

To register additional Instances for a plugin type, use one of the overloads of For().Add():


-    public class AdditionalRegistrations : Registry
-    {
-        public AdditionalRegistrations()
-        {
-            // If you know the plugin type and its a closed type
-            // you can Add this syntax
-            For<IWidget>().Add<DefaultWidget>();
-
-            // By Lambda
-            For<IWidget>().Add(() => new DefaultWidget());
-
-            // Pre-existing object
-            For<IWidget>().Add(new AWidget());
-
-            // Also rare, but you can supply an Instance object
-            // yourself for special needs
-            For<IWidget>().AddInstance(new MySpecialInstance());
-
-            // If you're registering an open generic type
-            // or you just have Type objects, Add this syntax
-            For(typeof(IService<>)).Add(typeof(Service<>));
-
-            // This is occasionally Addful for generic types
-            For(typeof(IService<>)).Add(new MySpecialInstance());
-        }
-    }
-

Add Many Registrations with For().AddInstances()

If you need to add several Instances to a single plugin type, the AddInstances() syntax -shown below may be quicker and easier to use:


-
-                // registry is a StructureMap Registry object
-                registry.For<IService>().AddInstances(x =>
-                {
-                    // Equivalent to For<IService>().Add<ColorService>().....
-                    x.Type<ColorService>().Named("Red").Ctor<string>("color").Is("Red");
-
-                    // Equivalent to For<IService>().Add(new ColorService("Yellow"))......
-                    x.Object(new ColorService("Yellow")).Named("Yellow");
-
-                    // Equivalent to For<IService>().Use(() => new ColorService("Purple"))....
-                    x.ConstructedBy(() => new ColorService("Purple")).Named("Purple");
-
-                    x.Type<ColorService>().Named("Decorated").Ctor<string>("color").Is("Orange");
-                });
-
-

Named Instances

When you have multiple implementations of an interface, it can often be useful to -name instances. To retrieve a specific implementation:


-        [Fact]
-        public void SimpleCaseWithNamedInstance()
-        {
-            container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("MyInstance"); });
-            // retrieve an instance by name
-            var widget = (AWidget)container.GetInstance<IWidget>("MyInstance");
-            widget.ShouldNotBeNull();
-        }
-
-

You can also register named instances with the following shorthand:


-        [Fact]
-        public void A_concrete_type_is_available_by_name_when_it_is_added_by_the_shorthand_mechanism()
-        {
-            IContainer container = new Container(r => r.For<IAddTypes>().AddInstances(x =>
-            {
-                x.Type<RedAddTypes>().Named("Red");
-                x.Type<GreenAddTypes>().Named("Green");
-                x.Type<BlueAddTypes>().Named("Blue");
-                x.Type<PurpleAddTypes>();
-            }));
-            // retrieve the instances by name
-            container.GetInstance<IAddTypes>("Red").IsType<RedAddTypes>();
-            container.GetInstance<IAddTypes>("Green").IsType<GreenAddTypes>();
-            container.GetInstance<IAddTypes>("Blue").IsType<BlueAddTypes>();
-        }
-
-

- + + +

Creating Registry classes is the recommended way of using the Registry DSL.

The Registry DSL is mostly a fluent interface with some nested closure +usage. The intent of the Registry DSL is to make the configuration process as +error free as possible by using "compiler safe" expressions and defensive +programming to point out missing data.

The Registry Class

On all but the smallest systems, the main unit of configuration will probably be +the Registry class. Typically, you would subclass the Registry class, then +use the fluent interface methods exposed by the Registry class to create Container +configuration. Here's a sample Registry class below used to configure an +instance of an IWidget interface:


public class PurpleRegistry : Registry
{
    public PurpleRegistry()
    {
        For<IWidget>().Use<AWidget>();
    }
}

Including Registries

The next question is "how does my new Registry class get used?"

When you set up a Container, you need to simply direct the +Container to use the configuration in that Registry class:


[Fact]
public void include_a_registry()
{
    var registry = new Registry();
    registry.IncludeRegistry<YellowBlueRegistry>();
    registry.IncludeRegistry<RedGreenRegistry>();
    registry.IncludeRegistry<PurpleRegistry>();
    // build a container
    var container = new Container(registry);
    // verify the default implementation and total registered implementations
    container.GetInstance<IWidget>().ShouldBeOfType<AWidget>();
    container.GetAllInstances<IWidget>().Count().ShouldBe(5);
}

Use versus Add

Registrations in the Registry DSL can be done with either Add() or Use() methods, but they have +a different semantic meaning to StructureMap. Add() means add another Instance to this plugin type +while Use() means this one is the default.

One of the things that is different about StructureMap is that if it has multiple registrations of any +given plugin type, one of these registrations has to be explicitly marked as the default usage for that plugin type +or StructureMap will blow up in the call to Container.GetInstance(). Other IoC tools will magically use +the first registration or the last registration (and some even allow you to configure that behavior). We chose to +make that determination be explicit.

As of StructureMap 3.0, the WhatDoIHave() output is part of any exception thrown by StructureMap when +it cannot determine a default registration for a requested type if there is more than one registration for that +type.

If there are multiple calls to Use() for the same plugin type, the last one wins. For more control over this behavior in +modularity scenarios, see Fallback Services and Replace or Clear Out Previous Registrations.

For().Use()

To register the default Instance of a type, the syntax is one of the Registry.For().Use() overloads shown below:


public class SettingDefaults : Registry
{
    public SettingDefaults()
    {
        // If you know the plugin type and its a closed type
        // you can use this syntax
        For<IWidget>().Use<DefaultWidget>();

        // By Lambda
        For<IWidget>().Use(() => new DefaultWidget());

        // Pre-existing object
        For<IWidget>().Use(new AWidget());

        // This is rare now, but still valid
        For<IWidget>().Add<AWidget>().Named("A");
        For<IWidget>().Add<BWidget>().Named("B");
        For<IWidget>().Use("A"); // makes AWidget the default

        // Also rare, but you can supply an Instance object
        // yourself for special needs
        For<IWidget>().UseInstance(new MySpecialInstance());

        // If you're registering an open generic type
        // or you just have Type objects, use this syntax
        For(typeof (IService<>)).Use(typeof (Service<>));

        // This is occasionally useful for generic types
        For(typeof (IService<>)).Use(new MySpecialInstance());
    }
}

For().Add()

To register additional Instances for a plugin type, use one of the overloads of For().Add():


public class AdditionalRegistrations : Registry
{
    public AdditionalRegistrations()
    {
        // If you know the plugin type and its a closed type
        // you can use this syntax
        For<IWidget>().Add<DefaultWidget>();

        // By Lambda
        For<IWidget>().Add(() => new DefaultWidget());

        // Pre-existing object
        For<IWidget>().Add(new AWidget());

        // Also rare, but you can supply an Instance object
        // yourself for special needs
        For<IWidget>().AddInstance(new MySpecialInstance());

        // If you're registering an open generic type
        // or you just have Type objects, use this syntax
        For(typeof(IService<>)).Add(typeof(Service<>));

        // This is occasionally useful for generic types
        For(typeof(IService<>)).Add(new MySpecialInstance());
    }
}

Add Many Registrations with For().AddInstances()

If you need to add several Instances to a single plugin type, the AddInstances() syntax +shown below may be quicker and easier to use:



// registry is a StructureMap Registry object
registry.For<IService>().AddInstances(x =>
{
    // Equivalent to For<IService>().Add<ColorService>().....
    x.Type<ColorService>().Named("Red").Ctor<string>("color").Is("Red");

    // Equivalent to For<IService>().Add(new ColorService("Yellow"))......
    x.Object(new ColorService("Yellow")).Named("Yellow");

    // Equivalent to For<IService>().Use(() => new ColorService("Purple"))....
    x.ConstructedBy(() => new ColorService("Purple")).Named("Purple");

    x.Type<ColorService>().Named("Decorated").Ctor<string>("color").Is("Orange");
});

Named Instances

When you have multiple implementations of an interface, it can often be useful to +name instances. To retrieve a specific implementation:


[Fact]
public void SimpleCaseWithNamedInstance()
{
    container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("MyInstance"); });
    // retrieve an instance by name
    var widget = (AWidget)container.GetInstance<IWidget>("MyInstance");
    widget.ShouldNotBeNull();
}

You can also register named instances with the following shorthand:


[Fact]
public void A_concrete_type_is_available_by_name_when_it_is_added_by_the_shorthand_mechanism()
{
    IContainer container = new Container(r => r.For<IAddTypes>().AddInstances(x =>
    {
        x.Type<RedAddTypes>().Named("Red");
        x.Type<GreenAddTypes>().Named("Green");
        x.Type<BlueAddTypes>().Named("Blue");
        x.Type<PurpleAddTypes>();
    }));
    // retrieve the instances by name
    container.GetInstance<IAddTypes>("Red").IsType<RedAddTypes>();
    container.GetInstance<IAddTypes>("Green").IsType<GreenAddTypes>();
    container.GetInstance<IAddTypes>("Blue").IsType<BlueAddTypes>();
}

StructureMap - Setter Injection Policies

- -

- - -

StructureMap 3.1.6

-
- - - -

On Missing Family Policies

Changing Configuration at Runtime

- -

- - -

Setter Injection Policies

- -

- - -

TODO(Write some content!)

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - diff --git a/release-notes/index.html b/release-notes/index.html index 8e3bfd4..9c6c764 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -31,7 +31,7 @@

@@ -88,123 +88,109 @@

Release Notes - - -
StructureMap is attempting to follow a strict SemVer versioning policy.
-

Release Notes 4.3

See the closed GitHub issues for -a complete list of changes.

Converts the codebase to using the new dotnet CLI tools
Targets .Net 4.5, Netstandard 1.3, and Netstandard 1.5
Performance improvement for some IContainer.With() usages

Release Notes 4.2

Added the "disposal lock" feature to prevent a Container from being erroneously disposed

Release Notes 4.1

4.1 was mostly a bugfix release, but also included some new public API calls for type scanning discovery from *.exe files. -See the closed GitHub issues for details.

4.1.2 - Bug fix for GH-461 singleton scoped registrations to a child container
4.1.1 - Bug fix for "AlwaysUnique" lifecycle within enumerable, inline dependencies

Release Notes 4.0.*

4.0.1 was strictly a bug fix release.

Release Notes 4.0

4.0 is a medium sized release that largely builds on the existing 3.0 architecture with significant improvements to conventional -registration via type scanning and several performance improvements as well as some bug fixes.

The highlights:

We believe that the documentation is finally comprehensive in regards to StructureMap behavior and features
StructureMap 4.0 is cross-compiled to .Net 4.0, .Net 4.0 as/ PCL, and as CoreCLR compliant (using the dotnet build profile).
The type scanning model (Registry.Scan()) was completely rebuilt to make the model easier to extend and to -optimize application bootstrapping in systems that heavily rely on StructureMap type scanning. See Auto-Registration and Conventions for more information.
New diagnostic method specifically for troubleshooting type scanning problems. See Type Scanning Diagnostics for more information.
New concept of a "build time Instance convention" to apply much more powerful policies and conventions against your StructureMap registrations -as a whole. See Construction Policies for more information.
Runtime performance improvements
Hardened StructureMap for multi-threaded usage
Performance improvements specifically targeted at usage from within ASP.Net MVC and its particular manner of using IoC tools.
Removed the static ObjectFactory facade over the application Container altogether.
Enhanced lifecycle support for compliance with ASP.Net MVC6. Nested containers track and dispose AlwaysUnique objects, the new ContainerScoped -lifecyle, and an optional mode to make the root or child containers track Transient disposable objects. See Object Lifecycles and Nested Containers (Per Request/Transaction) for more information.
Registry.For<T>().ClearAll() and Registry.For(Type).ClearAll() methods for removing all previous registrations for a type. See -Replace or Clear Out Previous Registrations for more information.

See also the complete list of changes and issues for StructureMap 4.0.

3.1.*

Click on any release version to see the list of closed GitHub issues related to any of the 3.1 releases.

3.1.6 -- Optional strong named nugets, bug fixes
3.1.5 -- Fixes for open generics convention resolution, child containers and policies, naming conflicts between setters and ctor arguments
3.1.4 -- performance optimization for resolving objects that are registered directly to a Container
3.1.3 -- named instances registered to child or nested containers
3.1.2 -- reduces thread contention issues on Container.Configure() calls at runtime
3.1.1 -- fixed a potentially significant memory leak issue
3.1.0 -- new functionality on IContext

3.0.* Bug Fix Releases

Click on any release version to see the list of closed GitHub issues related to a bugfix release.

Release Notes 3.0

-
The exception messages provide contextual information about what StructureMap was trying to do when things went wrong.
-
-
The nested container implementation is vastly improved, much faster (100X in my testing against a big application), and doesn’t have the massive singleton behavior bug from 2.6.*.
-
-
All old [Obsolete] 2.5 registration syntax has been removed, and there’s been a major effort to enforce consistency throughout the registration API’s.
-
-
The original StructureMap.dll has been broken up into a couple pieces. The main assembly will be targeting PCL compliance thanks to the diligent efforts of Frank Quednau, and that means that Xml configuration and anything to do with ASP.Net has been devolved into separate assemblies and eventually into different Nuget packages. This means that StructureMap will theoretically support WP8 and other versions of .Net for the very first time. God help me.
-
-
The strong naming has been removed. My thought is to distribute separate Nuget packages with unsigned versions for sane folks and signed versions for enterprise-y folks.
-
-
Lifecycle (scope) can be set individually on each Instance (stupid limitation left over from the very early days) -Constructor selection can be specified per Instance.
-
-
Improved diagnostics, both at runtime and for the container configuration.
-
-
Improved runtime performance, especially for deep object graphs with inline dependencies (i.e., behavior chains).
-
-
The interception model has been completely redesigned.
-
-
The ancient attribute model for StructureMap configuration has been mostly removed.
-
-
The “Profile” model has been much improved.
-
-
The Xml configuration has been heavily streamlined.
-
-
Internally, the old PipelineGraph, InstanceFactory, ProfileManager architecture is all gone. The new PipelineGraph implementations just wrap one or more PluginGraph objects, so there’s vastly less data structure shuffling gone on internally.
-

Related links:

http://jeremydmiller.com/2014/02/18/structuremap-3-is-gonna-tell-you-whats-wrong-and-where-it-hurts/
http://jeremydmiller.com/2014/01/17/structuremap-3-0-is-very-nearly-done-no-seriously/
http://jeremydmiller.com/2013/02/22/big-update-on-structuremap-3-0-progress/
http://jeremydmiller.com/2013/01/30/lets-try-this-again-structuremap-3-0-in-en-route-as-of-now/

- + + +

StructureMap is attempting to follow a strict SemVer versioning policy.

Release Notes 4.3

See the closed GitHub issues for +a complete list of changes.

Converts the codebase to using the new dotnet CLI tools
Targets .Net 4.5, Netstandard 1.3, and Netstandard 1.5
Performance improvement for some IContainer.With() usages

Release Notes 4.2

Added the "disposal lock" feature to prevent a Container from being erroneously disposed

Release Notes 4.1

4.1 was mostly a bugfix release, but also included some new public API calls for type scanning discovery from *.exe files. +See the closed GitHub issues for details.

4.1.2 - Bug fix for GH-461 singleton scoped registrations to a child container
4.1.1 - Bug fix for "AlwaysUnique" lifecycle within enumerable, inline dependencies

Release Notes 4.0.*

4.0.1 was strictly a bug fix release.

Release Notes 4.0

4.0 is a medium sized release that largely builds on the existing 3.0 architecture with significant improvements to conventional +registration via type scanning and several performance improvements as well as some bug fixes.

The highlights:

We believe that the documentation is finally comprehensive in regards to StructureMap behavior and features
StructureMap 4.0 is cross-compiled to .Net 4.0, .Net 4.0 as/ PCL, and as CoreCLR compliant (using the dotnet build profile).
The type scanning model (Registry.Scan()) was completely rebuilt to make the model easier to extend and to +optimize application bootstrapping in systems that heavily rely on StructureMap type scanning. See Auto-Registration and Conventions for more information.
New diagnostic method specifically for troubleshooting type scanning problems. See Type Scanning Diagnostics for more information.
New concept of a "build time Instance convention" to apply much more powerful policies and conventions against your StructureMap registrations +as a whole. See Construction Policies for more information.
Runtime performance improvements
Hardened StructureMap for multi-threaded usage
Performance improvements specifically targeted at usage from within ASP.Net MVC and its particular manner of using IoC tools.
Removed the static ObjectFactory facade over the application Container altogether.
Enhanced lifecycle support for compliance with ASP.Net MVC6. Nested containers track and dispose AlwaysUnique objects, the new ContainerScoped +lifecyle, and an optional mode to make the root or child containers track Transient disposable objects. See Object Lifecycles and Nested Containers (Per Request/Transaction) for more information.
Registry.For<T>().ClearAll() and Registry.For(Type).ClearAll() methods for removing all previous registrations for a type. See +Replace or Clear Out Previous Registrations for more information.

See also the complete list of changes and issues for StructureMap 4.0.

3.1.*

Click on any release version to see the list of closed GitHub issues related to any of the 3.1 releases.

3.1.6 -- Optional strong named nugets, bug fixes
3.1.5 -- Fixes for open generics convention resolution, child containers and policies, naming conflicts between setters and ctor arguments
3.1.4 -- performance optimization for resolving objects that are registered directly to a Container
3.1.3 -- named instances registered to child or nested containers
3.1.2 -- reduces thread contention issues on Container.Configure() calls at runtime
3.1.1 -- fixed a potentially significant memory leak issue
3.1.0 -- new functionality on IContext

3.0.* Bug Fix Releases

Click on any release version to see the list of closed GitHub issues related to a bugfix release.

Release Notes 3.0

The exception messages provide contextual information about what StructureMap was trying to do when things went wrong.
+
The nested container implementation is vastly improved, much faster (100X in my testing against a big application), and doesn’t have the massive singleton behavior bug from 2.6.*.
+
All old [Obsolete] 2.5 registration syntax has been removed, and there’s been a major effort to enforce consistency throughout the registration API’s.
+
The original StructureMap.dll has been broken up into a couple pieces. The main assembly will be targeting PCL compliance thanks to the diligent efforts of Frank Quednau, and that means that Xml configuration and anything to do with ASP.Net has been devolved into separate assemblies and eventually into different Nuget packages. This means that StructureMap will theoretically support WP8 and other versions of .Net for the very first time. God help me.
+
The strong naming has been removed. My thought is to distribute separate Nuget packages with unsigned versions for sane folks and signed versions for enterprise-y folks.
+
Lifecycle (scope) can be set individually on each Instance (stupid limitation left over from the very early days) +Constructor selection can be specified per Instance.
+
Improved diagnostics, both at runtime and for the container configuration.
+
Improved runtime performance, especially for deep object graphs with inline dependencies (i.e., behavior chains).
+
The interception model has been completely redesigned.
+
The ancient attribute model for StructureMap configuration has been mostly removed.
+
The “Profile” model has been much improved.
+
The Xml configuration has been heavily streamlined.
+
Internally, the old PipelineGraph, InstanceFactory, ProfileManager architecture is all gone. The new PipelineGraph implementations just wrap one or more PluginGraph objects, so there’s vastly less data structure shuffling gone on internally.
+

Related links:

http://jeremydmiller.com/2014/02/18/structuremap-3-is-gonna-tell-you-whats-wrong-and-where-it-hurts/
http://jeremydmiller.com/2014/01/17/structuremap-3-0-is-very-nearly-done-no-seriously/
http://jeremydmiller.com/2013/02/22/big-update-on-structuremap-3-0-progress/
http://jeremydmiller.com/2013/01/30/lets-try-this-again-structuremap-3-0-in-en-route-as-of-now/

@@ -88,33 +88,10 @@

Get a Service by Plugin Type and Name - - -

You can also request a named configuration for a given PluginType by using the overloads of IContainer.GetInstance() that take in a name like this:


-        [Fact]
-        public void get_a_named_instance()
-        {
-            var container = new Container(x =>
-            {
-                x.For<IWidget>().Add<AWidget>().Named("A");
-                x.For<IWidget>().Add<BWidget>().Named("B");
-                x.For<IWidget>().Add<CWidget>().Named("C");
-            });
-
-            container.GetInstance<IWidget>("A").ShouldBeOfType<AWidget>();
-            container.GetInstance<IWidget>("B").ShouldBeOfType<BWidget>();
-            container.GetInstance<IWidget>("C").ShouldBeOfType<CWidget>();
-
-            // or
-
-            container.GetInstance(typeof(IWidget), "A").ShouldBeOfType<AWidget>();
-            container.GetInstance(typeof(IWidget), "B").ShouldBeOfType<BWidget>();
-            container.GetInstance(typeof(IWidget), "C").ShouldBeOfType<CWidget>();
-        }
-
-

- + + +

You can also request a named configuration for a given PluginType by using the overloads of IContainer.GetInstance() that take in a name like this:


[Fact]
public void get_a_named_instance()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Add<AWidget>().Named("A");
        x.For<IWidget>().Add<BWidget>().Named("B");
        x.For<IWidget>().Add<CWidget>().Named("C");
    });

    container.GetInstance<IWidget>("A").ShouldBeOfType<AWidget>();
    container.GetInstance<IWidget>("B").ShouldBeOfType<BWidget>();
    container.GetInstance<IWidget>("C").ShouldBeOfType<CWidget>();

    // or

    container.GetInstance(typeof(IWidget), "A").ShouldBeOfType<AWidget>();
    container.GetInstance(typeof(IWidget), "B").ShouldBeOfType<BWidget>();
    container.GetInstance(typeof(IWidget), "C").ShouldBeOfType<CWidget>();
}

diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html index ab5b674..7b29e58 100644 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -31,7 +31,7 @@

@@ -88,26 +88,10 @@

Get a Service by PluginType - - -

Requesting the default configured object of a plugin type is done through the IContainer.GetInstance() method shown below:


-        [Fact]
-        public void get_the_default_instance()
-        {
-            var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<AWidget>();
-
-            // or
-
-            container.GetInstance(typeof(IWidget))
-                .ShouldBeOfType<AWidget>();
-        }
-
-

- + + +

Requesting the default configured object of a plugin type is done through the IContainer.GetInstance() method shown below:


[Fact]
public void get_the_default_instance()
{
    var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<AWidget>();

    // or

    container.GetInstance(typeof(IWidget))
        .ShouldBeOfType<AWidget>();
}

diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html index d1b4e24..f324136 100644 --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -31,7 +31,7 @@

@@ -88,37 +88,13 @@

Get all Services by Plugin Type - - -

Please see Working with Enumerable Types for a lot more information about what's going on behind the -scenes.

Once in a while you might want to get an enumerable of all the configured objects for a PluginType. That's done with the GetAllInstances() method shown below:


-        [Fact]
-        public void get_all_instances()
-        {
-            var container = new Container(x =>
-            {
-                x.For<IWidget>().Add<AWidget>().Named("A");
-                x.For<IWidget>().Add<BWidget>().Named("B");
-                x.For<IWidget>().Add<CWidget>().Named("C");
-            });
-
-            container.GetAllInstances<IWidget>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-
-            // or
-
-            container.GetAllInstances(typeof(IWidget))
-                .OfType<IWidget>() // returns an IEnumerable, so I'm casting here
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-        }
-
-

GetAllInstances() respects the order in which the actual instances are configured in the Container. Be warned that some other IoC tools make different assuptions if you are coming from a different tool.

- + + +

Please see Working with Enumerable Types for a lot more information about what's going on behind the +scenes.

Once in a while you might want to get an enumerable of all the configured objects for a PluginType. That's done with the GetAllInstances() method shown below:


[Fact]
public void get_all_instances()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Add<AWidget>().Named("A");
        x.For<IWidget>().Add<BWidget>().Named("B");
        x.For<IWidget>().Add<CWidget>().Named("C");
    });

    container.GetAllInstances<IWidget>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // or

    container.GetAllInstances(typeof(IWidget))
        .OfType<IWidget>() // returns an IEnumerable, so I'm casting here
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
}

@@ -88,11 +88,10 @@

Resolving Services - -
This will be the easy part of interacting with StructureMap. During application execution, you will need to resolve the services you previously registered in the container. When you ask StructureMap to resolve a service, StructureMap either creates a new object instance or finds the previously built object for the correct Object Lifecycles.
-
While in many systems you will probably only resolve the default service of a type or a named instance of a service, there are far more ways to resolve services exposed by StructureMap. The `IContainer` interface acts as a Service Locator to build and resolve configured services on demand.
-
- + +
This will be the easy part of interacting with StructureMap. During application execution, you will need to resolve the services you previously registered in the container. When you ask StructureMap to resolve a service, StructureMap either creates a new object instance or finds the previously built object for the correct Object Lifecycles.
+
While in many systems you will probably only resolve the default service of a type or a named instance of a service, there are far more ways to resolve services exposed by StructureMap. The `IContainer` interface acts as a Service Locator to build and resolve configured services on demand.
+

@@ -88,130 +88,37 @@

Passing Arguments at Runtime - - -

Most of the time you will be using StructureMap to build objects based on pre-canned configuration established upfront, but StructureMap -also has the capability to supply dependencies by type or named parameters (if you know the name of constructor arguments or setter property names) to the Container at runtime using the IContainer.With() methods.

Why would you use this? Here are a few examples from my own usage over the years:

In adhoc code, retrieve some service but override a connectionString constructor argument to connect to a different database
If you were to use StructureMap as a configuration intermediary, it becomes common to use this mechanism to swap out configuration on the fly
Inject an Entity object into a service (uncommon now, but I did this on several systems years ago)
Inject something contextual that can only be built at runtime like an ASP.Net HttpContext into a pre-configured object graph

Now, for some samples. Let's say that we have some classes like so:


-    public class ColorWidget : IWidget
-    {
-        public string Color { get; set; }
-
-        public ColorWidget(string color)
-        {
-            Color = color;
-        }
-    }
-
-    public class GuyWithWidgetAndService
-    {
-        public IWidget Widget { get; set; }
-        public IService Service { get; set; }
-
-        public GuyWithWidgetAndService(IWidget widget, IService service)
-        {
-            Widget = widget;
-            Service = service;
-        }
-    }
-
-

and unless stated otherwise in a sample, a Container configured like so:


-            var container = new Container(x =>
-            {
-                x.For<IWidget>().Use<BWidget>();
-                x.For<IService>().Use<AService>();
-            });
-

Passing Named Arguments

The original usage of explicit arguments was to replace primitive arguments to constructor functions like this sample:


-        [Fact]
-        public void supply_named_arguments()
-        {
-            var container = new Container(x => { x.For<IWidget>().Use<ColorWidget>().Ctor<string>().Is("Red"); });
-
-            container.GetInstance<IWidget>()
-                .ShouldBeOfType<ColorWidget>()
-                .Color.ShouldBe("Red");
-
-            container.With("color").EqualTo("Blue")
-                .GetInstance<IWidget>()
-                .ShouldBeOfType<ColorWidget>()
-                .Color.ShouldBe("Blue");
-        }
-
-

The canonical usage is overriding file paths, database connection string, or urls.

Passing Arguments with a Fluent Interface

You can invoke the explicit argument passing as a fluent interface starting with -IContainer.With() like the following sample:


-            var widget = new BWidget();
-            var service = new BService();
-
-            var guyWithWidgetAndService = container
-                .With<IWidget>(widget)
-                .With<IService>(service)
-                .GetInstance<GuyWithWidgetAndService>();
-
-            guyWithWidgetAndService
-                .Widget.ShouldBeTheSameAs(widget);
-
-            guyWithWidgetAndService
-                .Service.ShouldBeTheSameAs(service);
-

Using a Nested Closure

If you dislike fluent interfaces or want to pass in a lot of dependencies, -the nested closure syntax might be more usable:


-            var widget = new BWidget();
-            var service = new BService();
-
-            var guyWithWidgetAndService = container
-                .With(x =>
-                {
-                    x.With<IWidget>(widget);
-                    x.With<IService>(service);
-                })
-                .GetInstance<GuyWithWidgetAndService>();
-
-            guyWithWidgetAndService
-                .Widget.ShouldBeTheSameAs(widget);
-
-            guyWithWidgetAndService
-                .Service.ShouldBeTheSameAs(service);
-

Using the ExplicitArguments object

Finally, you can also pass an object of type ExplicitArguments directly to an overload -of the IContainer.GetInstance() method:


-            var widget = new BWidget();
-            var service = new BService();
-
-            var args = new ExplicitArguments();
-            args.Set<IWidget>(widget);
-            args.Set<IService>(service);
-
-            var guyWithWidgetAndService = container
-                .GetInstance<GuyWithWidgetAndService>(args);
-
-            guyWithWidgetAndService
-                .Widget.ShouldBeTheSameAs(widget);
-
-            guyWithWidgetAndService
-                .Service.ShouldBeTheSameAs(service);
-

- + + +

Most of the time you will be using StructureMap to build objects based on pre-canned configuration established upfront, but StructureMap +also has the capability to supply dependencies by type or named parameters (if you know the name of constructor arguments or setter property names) to the Container at runtime using the IContainer.With() methods.

Why would you use this? Here are a few examples from my own usage over the years:

In adhoc code, retrieve some service but override a connectionString constructor argument to connect to a different database
If you were to use StructureMap as a configuration intermediary, it becomes common to use this mechanism to swap out configuration on the fly
Inject an Entity object into a service (uncommon now, but I did this on several systems years ago)
Inject something contextual that can only be built at runtime like an ASP.Net HttpContext into a pre-configured object graph

Now, for some samples. Let's say that we have some classes like so:


public class ColorWidget : IWidget
{
    public string Color { get; set; }

    public ColorWidget(string color)
    {
        Color = color;
    }
}

public class GuyWithWidgetAndService
{
    public IWidget Widget { get; set; }
    public IService Service { get; set; }

    public GuyWithWidgetAndService(IWidget widget, IService service)
    {
        Widget = widget;
        Service = service;
    }
}

and unless stated otherwise in a sample, a Container configured like so:


var container = new Container(x =>
{
    x.For<IWidget>().Use<BWidget>();
    x.For<IService>().Use<AService>();
});

Passing Named Arguments

The original usage of explicit arguments was to replace primitive arguments to constructor functions like this sample:


[Fact]
public void supply_named_arguments()
{
    var container = new Container(x => { x.For<IWidget>().Use<ColorWidget>().Ctor<string>().Is("Red"); });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<ColorWidget>()
        .Color.ShouldBe("Red");

    container.With("color").EqualTo("Blue")
        .GetInstance<IWidget>()
        .ShouldBeOfType<ColorWidget>()
        .Color.ShouldBe("Blue");
}

The canonical usage is overriding file paths, database connection string, or urls.

Passing Arguments with a Fluent Interface

You can invoke the explicit argument passing as a fluent interface starting with +IContainer.With() like the following sample:


var widget = new BWidget();
var service = new BService();

var guyWithWidgetAndService = container
    .With<IWidget>(widget)
    .With<IService>(service)
    .GetInstance<GuyWithWidgetAndService>();

guyWithWidgetAndService
    .Widget.ShouldBeTheSameAs(widget);

guyWithWidgetAndService
    .Service.ShouldBeTheSameAs(service);

Using a Nested Closure

If you dislike fluent interfaces or want to pass in a lot of dependencies, +the nested closure syntax might be more usable:


var widget = new BWidget();
var service = new BService();

var guyWithWidgetAndService = container
    .With(x =>
    {
        x.With<IWidget>(widget);
        x.With<IService>(service);
    })
    .GetInstance<GuyWithWidgetAndService>();

guyWithWidgetAndService
    .Widget.ShouldBeTheSameAs(widget);

guyWithWidgetAndService
    .Service.ShouldBeTheSameAs(service);

Using the ExplicitArguments object

Finally, you can also pass an object of type ExplicitArguments directly to an overload +of the IContainer.GetInstance() method:


var widget = new BWidget();
var service = new BService();

var args = new ExplicitArguments();
args.Set<IWidget>(widget);
args.Set<IService>(service);

var guyWithWidgetAndService = container
    .GetInstance<GuyWithWidgetAndService>(args);

guyWithWidgetAndService
    .Widget.ShouldBeTheSameAs(widget);

guyWithWidgetAndService
    .Service.ShouldBeTheSameAs(service);

diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index 3c9cf66..468e659 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -31,7 +31,7 @@

@@ -88,66 +88,22 @@

Auto Resolving Concrete Types - - -

StructureMap allows you to resolve instances of concrete classes without configuring that concrete type with a few provisos:

The concrete type must have at least one public constructor
StructureMap can build all the arguments in the constructor, either because StructureMap has explicit configuration for that dependency or can auto resolve the type
The constructor does not contain any primitive arguments like strings, numbers, or dates because StructureMap assumes those elements are configuration items and not auto resolvable.

Let's say we have the following object model, which represents the weather condition for a certain location.


-    public class Weather
-    {
-        public Location Location { get; set; }
-        public Atmosphere Atmosphere { get; set; }
-        public Wind Wind { get; set; }
-        public Condition Condition { get; set; }
-
-        public Weather(Location location, Atmosphere atmosphere, Wind wind, Condition condition)
-        {
-            Location = location;
-            Atmosphere = atmosphere;
-            Wind = wind;
-            Condition = condition;
-        }
-    }
-
-    public class Location
-    {
-        //some properties
-    }
-
-    public class Atmosphere
-    {
-        //some properties
-    }
-
-    public class Wind
-    {
-        //some properties        
-    }
-
-    public class Condition
-    {
-        //some properties        
-    }
-
-

Before we can resolve the concrete Weather type, we need an instance of an Container object. As mentioned earlier, these objects defines a generic GetInstance method which can build us an instance of the Weather type.

You can create a container yourself or use the statically accessed container.


-            var container = new Container();
-            var weather1 = container.GetInstance<Weather>();
-
-            var weather2 = container.GetInstance<Weather>();
-            weather2 = container.GetInstance<Weather>(); //short version for above.
-

The reason why we don't need to supply any configuration is because StructureMap supports a concept called Auto Wiring. It's basically a smart way of building instances of types by looking to the constructors of the requested and all the needed underlaying types. During this inspection StructureMap also uses any provided configuration to help building the requested service or dependency.

In our example, where there isn't any configuration available, StructureMap looks at the constructor of the requested Weather type. It sees that it depends on four concrete types which all have a default constructor. StructureMap is therefore able to create an instance for all of them and inject them into the Weather constructor. After that the Weather instance is returned to the caller.

Most of the time you will be mapping abstractions to concrete types, but as you have seen StructureMap supports other use cases as well.

- + + +

StructureMap allows you to resolve instances of concrete classes without configuring that concrete type with a few provisos:

The concrete type must have at least one public constructor
StructureMap can build all the arguments in the constructor, either because StructureMap has explicit configuration for that dependency or can auto resolve the type
The constructor does not contain any primitive arguments like strings, numbers, or dates because StructureMap assumes those elements are configuration items and not auto resolvable.

Let's say we have the following object model, which represents the weather condition for a certain location.


public class Weather
{
    public Location Location { get; set; }
    public Atmosphere Atmosphere { get; set; }
    public Wind Wind { get; set; }
    public Condition Condition { get; set; }

    public Weather(Location location, Atmosphere atmosphere, Wind wind, Condition condition)
    {
        Location = location;
        Atmosphere = atmosphere;
        Wind = wind;
        Condition = condition;
    }
}

public class Location
{
    //some properties
}

public class Atmosphere
{
    //some properties
}

public class Wind
{
    //some properties        
}

public class Condition
{
    //some properties        
}

You can create a container yourself or use the statically accessed container.


var container = new Container();
var weather1 = container.GetInstance<Weather>();

var weather2 = container.GetInstance<Weather>();
weather2 = container.GetInstance<Weather>(); //short version for above.

Most of the time you will be mapping abstractions to concrete types, but as you have seen StructureMap supports other use cases as well.

@@ -88,24 +88,10 @@

Try Geting an Optional Service by Plugin Type and Name - - -

Just use the IContainer.TryGetInstance<T>(name) or IContainer.TryGetInstance(Type pluginType, string name) method as shown below:


-        [Fact]
-        public void TryGetInstanceViaNameAndGeneric_ReturnsInstance_WhenTypeFound()
-        {
-            addColorInstance("Red");
-            addColorInstance("Orange");
-            addColorInstance("Blue");
-
-            // "Orange" exists, so an object should be returned
-            var instance = _container.TryGetInstance<Rule>("Orange");
-            instance.ShouldBeOfType(typeof(ColorRule));
-        }
-
-

- + + +

Just use the IContainer.TryGetInstance<T>(name) or IContainer.TryGetInstance(Type pluginType, string name) method as shown below:


[Fact]
public void TryGetInstanceViaNameAndGeneric_ReturnsInstance_WhenTypeFound()
{
    addColorInstance("Red");
    addColorInstance("Orange");
    addColorInstance("Blue");

    // "Orange" exists, so an object should be returned
    var instance = _container.TryGetInstance<Rule>("Orange");
    instance.ShouldBeOfType(typeof(ColorRule));
}

diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html index 6e15e3c..7688fb2 100644 --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -31,7 +31,7 @@

@@ -88,127 +88,33 @@

Try Getting an Optional Service by Plugin Type - - -

The StructureMap team does not recommend using "optional" dependencies as shown in this topic, but -external frameworks like ASP.Net MVC and Web API use this concept in their IoC container integration, so here it is. The StructureMap team -prefers the usage of the Nullo pattern instead.

In normal usage, if you ask StructureMap for a service and StructureMap doesn't recognize the requested type, the requested name, or know what the default should be for that type, StructureMap will fail fast by throwing an exception rather than returning a null. Sometimes though, you may want to -retrieve an optional service from StructureMap that may or may not be registered in the Container. If that particular registration doesn't exist, you -just want a null value. StructureMap provides first class support for optional dependencies through the usage of the IContainer.TryGetInstance() methods.

Say you have a simple interface IFoo that may or may not be registered in the Container:


-        public interface IFoo
-        {
-        }
-
-        public class Foo : IFoo
-        {
-        }
-
-

In your own code you might request the IFoo service like the code below, knowing that you'll -take responsibility yourself for building the IFoo service if StructureMap doesn't have a registration -for IFoo:


-        public class MyFoo : IFoo
-        {
-        }
-
-        [Fact]
-        public void real_usage()
-        {
-            var container = new Container();
-
-            // if the container doesn't know about it,
-            // I'll build it myself
-            var foo = container.TryGetInstance<IFoo>()
-                      ?? new MyFoo();
-        }
-
-

Just to make this perfectly clear, if StructureMap has a default registration for IFoo, you get this behavior:


-        [Fact]
-        public void i_have_got_that()
-        {
-            var container = new Container(_ => _.For<IFoo>().Use<Foo>());
-
-            container.TryGetInstance<IFoo>()
-                .ShouldNotBeNull();
-
-            // -- or --
-
-            container.TryGetInstance(typeof(IFoo))
-                .ShouldNotBeNull();
-        }
-
-

If StructureMap knows nothing about IFoo, you get a null:


-        [Fact]
-        public void i_do_not_have_that()
-        {
-            var container = new Container();
-
-            container.TryGetInstance<IFoo>()
-                .ShouldBeNull();
-
-            // -- or --
-
-            container.TryGetInstance(typeof(IFoo))
-                .ShouldBeNull();
-        }
-
-

Concrete Types

Since it's not a perfect world, there are some gotchas you need to be aware of. -While StructureMap will happily auto-resolve concrete types that aren't registered, -that does not apply to the TryGetInstance mechanism:


-        public class ConcreteThing
-        {
-        }
-
-        [Fact]
-        public void no_auto_resolution_of_concrete_types()
-        {
-            var container = new Container();
-
-            container.TryGetInstance<ConcreteThing>()
-                .ShouldBeNull();
-
-            // now register ConcreteThing and do it again
-            container.Configure(_ => { _.For<ConcreteThing>().Use<ConcreteThing>(); });
-
-            container.TryGetInstance<ConcreteThing>()
-                .ShouldNotBeNull();
-        }
-
-

Optional Generic Types

If you are using open generic types, the TryGetInstance() mechanism can close the open generic registration -to satisfy the optional dependency like this sample:


-        public interface IThing<T>
-        {
-        }
-
-        public class Thing<T> : IThing<T>
-        {
-        }
-
-        [Fact]
-        public void can_try_get_open_type_resolution()
-        {
-            var container = new Container(_ => { _.For(typeof(IThing<>)).Use(typeof(Thing<>)); });
-
-            container.TryGetInstance<IThing<string>>()
-                .ShouldBeOfType<Thing<string>>();
-        }
-
-

- + + +

The StructureMap team does not recommend using "optional" dependencies as shown in this topic, but +external frameworks like ASP.Net MVC and Web API use this concept in their IoC container integration, so here it is. The StructureMap team +prefers the usage of the Nullo pattern instead.

In normal usage, if you ask StructureMap for a service and StructureMap doesn't recognize the requested type, the requested name, or know what the default should be for that type, StructureMap will fail fast by throwing an exception rather than returning a null. Sometimes though, you may want to +retrieve an optional service from StructureMap that may or may not be registered in the Container. If that particular registration doesn't exist, you +just want a null value. StructureMap provides first class support for optional dependencies through the usage of the IContainer.TryGetInstance() methods.

Say you have a simple interface IFoo that may or may not be registered in the Container:


public interface IFoo
{
}

public class Foo : IFoo
{
}

In your own code you might request the IFoo service like the code below, knowing that you'll +take responsibility yourself for building the IFoo service if StructureMap doesn't have a registration +for IFoo:


public class MyFoo : IFoo
{
}

[Fact]
public void real_usage()
{
    var container = new Container();

    // if the container doesn't know about it,
    // I'll build it myself
    var foo = container.TryGetInstance<IFoo>()
              ?? new MyFoo();
}

Just to make this perfectly clear, if StructureMap has a default registration for IFoo, you get this behavior:


[Fact]
public void i_have_got_that()
{
    var container = new Container(_ => _.For<IFoo>().Use<Foo>());

    container.TryGetInstance<IFoo>()
        .ShouldNotBeNull();

    // -- or --

    container.TryGetInstance(typeof(IFoo))
        .ShouldNotBeNull();
}

If StructureMap knows nothing about IFoo, you get a null:


[Fact]
public void i_do_not_have_that()
{
    var container = new Container();

    container.TryGetInstance<IFoo>()
        .ShouldBeNull();

    // -- or --

    container.TryGetInstance(typeof(IFoo))
        .ShouldBeNull();
}

Concrete Types

Since it's not a perfect world, there are some gotchas you need to be aware of. +While StructureMap will happily auto-resolve concrete types that aren't registered, +that does not apply to the TryGetInstance mechanism:


public class ConcreteThing
{
}

[Fact]
public void no_auto_resolution_of_concrete_types()
{
    var container = new Container();

    container.TryGetInstance<ConcreteThing>()
        .ShouldBeNull();

    // now register ConcreteThing and do it again
    container.Configure(_ => { _.For<ConcreteThing>().Use<ConcreteThing>(); });

    container.TryGetInstance<ConcreteThing>()
        .ShouldNotBeNull();
}

Optional Generic Types

If you are using open generic types, the TryGetInstance() mechanism can close the open generic registration +to satisfy the optional dependency like this sample:


public interface IThing<T>
{
}

public class Thing<T> : IThing<T>
{
}

[Fact]
public void can_try_get_open_type_resolution()
{
    var container = new Container(_ => { _.For(typeof(IThing<>)).Use(typeof(Thing<>)); });

    container.TryGetInstance<IThing<string>>()
        .ShouldBeOfType<Thing<string>>();
}

@@ -88,19 +88,18 @@

Roadmap - - -
StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's. The 4.0 release was -a much smaller release that primarily improved type scanning, diagnostics, and performance. The only breaking changes from 3 to 4 were in custom type scanning conventions, the removal of `ObjectFactory`, and -the elimination of some obscure configuration API's.
-
Please log any suspected bugs or feature requests on StructureMap's GitHub page.
-

Ongoing and upcoming work

StructureMap.DynamicInterception
StructureMap.AutoFactory
Auto Mocking updates and modernization

- + + +

StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's. The 4.0 release was +a much smaller release that primarily improved type scanning, diagnostics, and performance. The only breaking changes from 3 to 4 were in custom type scanning conventions, the removal of ObjectFactory, and +the elimination of some obscure configuration API's.

Please log any suspected bugs or feature requests on StructureMap's GitHub page.

Ongoing and upcoming work

StructureMap.DynamicInterception
StructureMap.AutoFactory
Auto Mocking updates and modernization

StructureMap can inject dependencies into public setter properties as part of its construction process using the Setter Injection form of Dependency Injection. The StructureMap team strongly recommends using constructor injection wherever possible instead of setter injection. That being said, there are few cases where setter injection is probably easier (inheritance hierarchies), not to mention legacy or third party tools that simply cannot support constructor injection cough ASP.Net cough.

See this discussion from Martin Fowler on Constructor vs Setter Injection.

If you are having any trouble with setter injection in your StructureMap usage, make sure you're familiar with using Build Plans to help in troubleshooting

Explicit Setter Injection with [SetterProperty] Attributes

The simplest conceptual way to force StructureMap into making public setters mandatory service dependencies by decorating setter properties with the [SetterProperty] attribute like this example:


-    public class Repository
-    {
-        private IDataProvider _provider;
-
-        // Adding the SetterProperty to a setter directs
-        // StructureMap to use this property when
-        // constructing a Repository instance
-        [SetterProperty]
-        public IDataProvider Provider
-        {
-            set { _provider = value; }
-        }
-
-        [SetterProperty]
-        public bool ShouldCache { get; set; }
-    }
-


public class Repository
{
    private IDataProvider _provider;

    // Adding the SetterProperty to a setter directs
    // StructureMap to use this property when
    // constructing a Repository instance
    [SetterProperty]
    public IDataProvider Provider
    {
        set { _provider = value; }
    }

    [SetterProperty]
    public bool ShouldCache { get; set; }
}

Without the [SetterProperty] attributes decorating the setters, StructureMap would ignore the Provider and ShouldCache properties when it builds up a Repository object. With the attributes, StructureMap will try to build and attach values for the two properties as part of object construction.

If you were to look at StructureMap's "build plan" for the Repository class, you would see something like this:

@@ -128,117 +111,24 @@ Explicit Setter Injection with [SetterProperty] Attributes
     Set Boolean ShouldCache = Value: False

If you intensely dislike runaway attribute usage, that's okay because there are other ways to enable setter injection in StructureMap.

Inline Setter Configuration

Any setter property not configured with [SetterProperty] or the setter policies in the next section can still be filled by StructureMap if an inline dependency is configured matching that setter property as shown in the example below:


-        public class RuleWithSetters : IEventRule
-        {
-            public ICondition Condition { get; set; }
-            public IAction Action { get; set; }
-
-            public void ProcessEvent(SomeEvent @event)
-            {
-                if (Condition.Matches(@event))
-                {
-                    Action.PerformWork(@event);
-                }
-            }
-        }
-
-        public class RuleWithSettersRegistry : Registry
-        {
-            public RuleWithSettersRegistry()
-            {
-                For<IEventRule>().Use<RuleWithSetters>()
-                    .Setter<ICondition>().Is<Condition1>()
-
-                    // or
-                    .Setter(x => x.Action).Is(new Action1())
-
-                    // or if you need to specify the name
-                    .Setter<IAction>("Action").Is<Action2>()
-
-                    // or you can configure values *after* the object
-                    // is constructed with the SetProperty method
-                    .SetProperty(x => x.Action = new Action2());
-            }
-        }
-
-


public class RuleWithSetters : IEventRule
{
    public ICondition Condition { get; set; }
    public IAction Action { get; set; }

    public void ProcessEvent(SomeEvent @event)
    {
        if (Condition.Matches(@event))
        {
            Action.PerformWork(@event);
        }
    }
}

public class RuleWithSettersRegistry : Registry
{
    public RuleWithSettersRegistry()
    {
        For<IEventRule>().Use<RuleWithSetters>()
            .Setter<ICondition>().Is<Condition1>()

            // or
            .Setter(x => x.Action).Is(new Action1())

            // or if you need to specify the name
            .Setter<IAction>("Action").Is<Action2>()

            // or you can configure values *after* the object
            // is constructed with the SetProperty method
            .SetProperty(x => x.Action = new Action2());
    }
}

Setter Injection Policies

Lastly, you can give StructureMap some criteria for determining which setters should be mandatory dependencies with the Registry.Policies.SetAllProperties() method during Container setup as shown in this example below:


-        public class ClassWithNamedProperties
-        {
-            public int Age { get; set; }
-            public string LastName { get; set; }
-            public string FirstName { get; set; }
-            public IGateway Gateway { get; set; }
-            public IService Service { get; set; }
-        }
-
-        [Fact]
-        public void specify_setter_policy_and_construct_an_object()
-        {
-            var theService = new ColorService("red");
-
-            var container = new Container(x =>
-            {
-                x.For<IService>().Use(theService);
-                x.For<IGateway>().Use<DefaultGateway>();
-
-                x.ForConcreteType<ClassWithNamedProperties>().Configure.Setter<int>().Is(5);
-
-                x.Policies.SetAllProperties(
-                    policy => policy.WithAnyTypeFromNamespace("StructureMap.Testing.Widget3"));
-            });
-
-            var description = container.Model.For<ClassWithNamedProperties>().Default.DescribeBuildPlan();
-            Debug.WriteLine(description);
-
-            var target = container.GetInstance<ClassWithNamedProperties>();
-            target.Service.ShouldBeTheSameAs(theService);
-            target.Gateway.ShouldBeOfType<DefaultGateway>();
-        }
-
-


public class ClassWithNamedProperties
{
    public int Age { get; set; }
    public string LastName { get; set; }
    public string FirstName { get; set; }
    public IGateway Gateway { get; set; }
    public IService Service { get; set; }
}

[Fact]
public void specify_setter_policy_and_construct_an_object()
{
    var theService = new ColorService("red");

    var container = new Container(x =>
    {
        x.For<IService>().Use(theService);
        x.For<IGateway>().Use<DefaultGateway>();

        x.ForConcreteType<ClassWithNamedProperties>().Configure.Setter<int>().Is(5);

        x.Policies.SetAllProperties(
            policy => policy.WithAnyTypeFromNamespace("StructureMap.Testing.Widget3"));
    });

    var description = container.Model.For<ClassWithNamedProperties>().Default.DescribeBuildPlan();
    Debug.WriteLine(description);

    var target = container.GetInstance<ClassWithNamedProperties>();
    target.Service.ShouldBeTheSameAs(theService);
    target.Gateway.ShouldBeOfType<DefaultGateway>();
}

All calls to Registry.Policies.SetAllProperties() are additive, meaning you can use as many criteria as possible for setter injection.

Filling Setter's of an Object

You can run into situations where you'll want StructureMap to fill the setter dependencies of an object that is built outside of your own code and cannot be built by StructureMap itself. Action filter attributes from ASP.Net MVC are an obvious example.

You're still in luck because StructureMap has the BuildUp(object) method for just this scenario as shown in this example from the unit tests:


-        public class BuildUpTarget1
-        {
-            public IGateway Gateway { get; set; }
-            public IService Service { get; set; }
-        }
-
-        [Fact]
-        public void create_a_setter_rule_and_see_it_applied_in_BuildUp()
-        {
-            var theGateway = new DefaultGateway();
-            var container = new Container(x =>
-            {
-                x.For<IGateway>().Use(theGateway);
-                x.Policies.SetAllProperties(y => y.OfType<IGateway>());
-            });
-
-            var target = new BuildUpTarget1();
-            container.BuildUp(target);
-
-            target.Gateway.ShouldBeTheSameAs(theGateway);
-            target.Service.ShouldBeNull();
-        }
-
-


public class BuildUpTarget1
{
    public IGateway Gateway { get; set; }
    public IService Service { get; set; }
}

[Fact]
public void create_a_setter_rule_and_see_it_applied_in_BuildUp()
{
    var theGateway = new DefaultGateway();
    var container = new Container(x =>
    {
        x.For<IGateway>().Use(theGateway);
        x.Policies.SetAllProperties(y => y.OfType<IGateway>());
    });

    var target = new BuildUpTarget1();
    container.BuildUp(target);

    target.Gateway.ShouldBeTheSameAs(theGateway);
    target.Service.ShouldBeNull();
}

The normal rules for what setters should be filled as described above apply to BuildUp().

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index b96eaa3..efd4db3 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -31,7 +31,7 @@

@@ -88,49 +88,19 @@

Software Design Concepts - - -
Inversion of Control
-
Years ago I consulted for a company that had developed a successful software engine for pricing and analyzing potential energy trades. The next step for them was to adapt their pricing engine so that it could be embedded in other software packages or even a simple spreadsheet so that analysts could quickly try out "what if" scenarios before making any kind of deal. The immediate problem this firm had was that their pricing engine was archtected such that the pricing engine business logic directly invoked their proprietary database schema and configuration files. The strategic pricing engine logic was effectively useless without all the rest of their system, so forget embedding the logic into spreadsheet logic.
-
With the benefit of hindsight, if we were to build an energy trading pricing engine from scratch, we would probably opt to use the software design concept of Inversion of Control such that the actual pricing logic code would be handed all the pricing metadata it needed to perform its work instead of making the pricing logic reach out to get it. In its most general usage, Inversion of Control simply means that a component is given some sort of dependent data or service or configuration instead of that component having to "know" how to fetch or find that resource.
-
An IoC container like StructureMap uses the Inversion of Control concept to simplify your internal services by freeing them from having to know how to find, build, or clean up their dependencies.
-

Dependency Injection

Dependency Injection is nothing more than pushing dependencies of an object into constructor functions or setter properties instead of that object doing everything for itself. If you are strictly using Dependency Injection to fill the dependencies of your classes, your code should have no coupling to StructureMap itself.


-        public interface IDatabase { }
-
-        public class DatabaseUser
-        {
-            // Using Constructor Injection
-            public DatabaseUser(IDatabase database)
-            {
-            }
-        }
-
-        public class OtherDatabaseUser
-        {
-            // Setter Injection
-            public IDatabase Database { get; set; }
-        }
-
-

Service Locator

StructureMap also fills the role of a service locator. In this usage, your code would directly access StructureMap's Container class to build or resolve services upon demand like this sample:


-        public class ThirdDatabaseUser
-        {
-            private IDatabase _database;
-
-            public ThirdDatabaseUser(IContainer container)
-            {
-                // This is service location
-                _database = container.GetInstance<IDatabase>();
-            }
-        }
-
-

Since IoC tools like StructureMap have come onto the software scene, many developers have very badly overused the service locator pattern and many other developers have become very vocal in their distaste for service location. The StructureMap team simply recommends that you favor Dependency Injection wherever possible, but that some service location in your system where you may need more advanced building options or lazy resolution of services is probably just fine.

- + + +

Inversion of Control

Years ago I consulted for a company that had developed a successful software engine for pricing and analyzing potential energy trades. The next step for them was to adapt their pricing engine so that it could be embedded in other software packages or even a simple spreadsheet so that analysts could quickly try out "what if" scenarios before making any kind of deal. The immediate problem this firm had was that their pricing engine was archtected such that the pricing engine business logic directly invoked their proprietary database schema and configuration files. The strategic pricing engine logic was effectively useless without all the rest of their system, so forget embedding the logic into spreadsheet logic.

With the benefit of hindsight, if we were to build an energy trading pricing engine from scratch, we would probably opt to use the software design concept of Inversion of Control such that the actual pricing logic code would be handed all the pricing metadata it needed to perform its work instead of making the pricing logic reach out to get it. In its most general usage, Inversion of Control simply means that a component is given some sort of dependent data or service or configuration instead of that component having to "know" how to fetch or find that resource.

An IoC container like StructureMap uses the Inversion of Control concept to simplify your internal services by freeing them from having to know how to find, build, or clean up their dependencies.

Dependency Injection


public interface IDatabase { }

public class DatabaseUser
{
    // Using Constructor Injection
    public DatabaseUser(IDatabase database)
    {
    }
}

public class OtherDatabaseUser
{
    // Setter Injection
    public IDatabase Database { get; set; }
}

Service Locator

StructureMap also fills the role of a service locator. In this usage, your code would directly access StructureMap's Container class to build or resolve services upon demand like this sample:


public class ThirdDatabaseUser
{
    private IDatabase _database;

    public ThirdDatabaseUser(IContainer container)
    {
        // This is service location
        _database = container.GetInstance<IDatabase>();
    }
}

@@ -88,76 +88,38 @@

Auto Wiring - - -

The best way to use an IoC container is to allow "Auto Wiring" to do most of the work for you. IoC Containers like StructureMap are an infrastructure concern, and as such, should be isolated from as much of your code as possible. Before examining Auto Wiring in depth, let's look at a common anti pattern of IoC usage:


-        // This is the wrong way to use an IoC container.  Do NOT invoke the container from
-        // the constructor function.  This tightly couples the ShippingScreenPresenter to
-        // the IoC container in a harmful way.  This class cannot be used in either
-        // production or testing without a valid IoC configuration.  Plus, you're writing more
-        // code
-        public ShippingScreenPresenter(IContainer container)
-        {
-            // It's even worse if you use a static facade to retrieve
-            // a service locator!
-            _service = container.GetInstance<IShippingService>();
-            _repository = container.GetInstance<IRepository>();
-        }
-

Instead of binding ShippingScreenPresenter so tightly to StructureMap and having to explicitly fetch its dependencies, let's switch -it to using StructureMap a little more idiomatically and just exposing a constructor function with the necessary dependencies -as arguments:


-        // This is the way to write a Constructor Function with an IoC tool
-        // Let the IoC container "inject" services from outside, and keep
-        // ShippingScreenPresenter ignorant of the IoC infrastructure
-        public ShippingScreenPresenter(IShippingService service, IRepository repository)
-        {
-            _service = service;
-            _repository = repository;
-        }
-

As long as a StructureMap Container knows how to resolve the IRepository and -IShippingService interfaces, StructureMap can build ShippingScreenPresenter by using "auto-wiring." All this means is that -instead of forcing you to explicitly configure all the dependencies for ShippingScreenPresenter, StructureMap can infer from -the public constructor function and public property setters -what dependencies ShippingScreenPresenter needs and uses the defaults of both to build it out.

Looking at the build plan for ShippingScreenPresenter:


-        public void ShowBuildPlan()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IShippingService>().Use<InternalShippingService>();
-                _.For<IRepository>().Use<SimpleRepository>();
-            });
-
-            // Just proving that we can build ShippingScreenPresenter;)
-            container.GetInstance<ShippingScreenPresenter>().ShouldNotBeNull();
-
-            var buildPlan = container.Model.For<ShippingScreenPresenter>().Default.DescribeBuildPlan(1);
-
-            Debug.WriteLine(buildPlan);
-        }
-

give us:

-PluginType: StructureMap.Testing.DocumentationExamples.ShippingScreenPresenter
-Lifecycle: Transient
-new ShippingScreenPresenter(IShippingService, IRepository)
-  ┣ IShippingService = **Default**
-  ┃                     | PluginType: StructureMap.Testing.DocumentationExamples.IShippingService
-  ┃                     | Lifecycle: Transient
-  ┃                     | new InternalShippingService()
-  ┃                    
-  ┗ IRepository = **Default**
-               | PluginType: StructureMap.Testing.DocumentationExamples.IRepository
-               | Lifecycle: Transient
-               | new SimpleRepository()
-

See Working with Primitive Types for more information on how StructureMap deals with primitive types like numbers, strings, enums, and dates in auto-wiring.

- + + +


// This is the wrong way to use an IoC container.  Do NOT invoke the container from
// the constructor function.  This tightly couples the ShippingScreenPresenter to
// the IoC container in a harmful way.  This class cannot be used in either
// production or testing without a valid IoC configuration.  Plus, you're writing more
// code
public ShippingScreenPresenter(IContainer container)
{
    // It's even worse if you use a static facade to retrieve
    // a service locator!
    _service = container.GetInstance<IShippingService>();
    _repository = container.GetInstance<IRepository>();
}

Instead of binding ShippingScreenPresenter so tightly to StructureMap and having to explicitly fetch its dependencies, let's switch +it to using StructureMap a little more idiomatically and just exposing a constructor function with the necessary dependencies +as arguments:


// This is the way to write a Constructor Function with an IoC tool
// Let the IoC container "inject" services from outside, and keep
// ShippingScreenPresenter ignorant of the IoC infrastructure
public ShippingScreenPresenter(IShippingService service, IRepository repository)
{
    _service = service;
    _repository = repository;
}

As long as a StructureMap Container knows how to resolve the IRepository and +IShippingService interfaces, StructureMap can build ShippingScreenPresenter by using "auto-wiring." All this means is that +instead of forcing you to explicitly configure all the dependencies for ShippingScreenPresenter, StructureMap can infer from +the public constructor function and public property setters +what dependencies ShippingScreenPresenter needs and uses the defaults of both to build it out.

Looking at the build plan for ShippingScreenPresenter:


public void ShowBuildPlan()
{
    var container = new Container(_ =>
    {
        _.For<IShippingService>().Use<InternalShippingService>();
        _.For<IRepository>().Use<SimpleRepository>();
    });

    // Just proving that we can build ShippingScreenPresenter;)
    container.GetInstance<ShippingScreenPresenter>().ShouldNotBeNull();

    var buildPlan = container.Model.For<ShippingScreenPresenter>().Default.DescribeBuildPlan(1);

    Debug.WriteLine(buildPlan);
}

give us:

+PluginType: StructureMap.Testing.DocumentationExamples.ShippingScreenPresenter
+Lifecycle: Transient
+new ShippingScreenPresenter(IShippingService, IRepository)
+  ┣ IShippingService = **Default**
+  ┃                     | PluginType: StructureMap.Testing.DocumentationExamples.IShippingService
+  ┃                     | Lifecycle: Transient
+  ┃                     | new InternalShippingService()
+  ┃                    
+  ┗ IRepository = **Default**
+               | PluginType: StructureMap.Testing.DocumentationExamples.IRepository
+               | Lifecycle: Transient
+               | new SimpleRepository()
+              
+

See Working with Primitive Types for more information on how StructureMap deals with primitive types like numbers, strings, enums, and dates in auto-wiring.

StructureMap - Fill Setter Dependencies of an Object Created Outside of StructureMap

- -

- - -

StructureMap 3.1.6

-
- - - -

Working with Primitive Types

Handling Missing Named Instances

- -

- - -

Fill Setter Dependencies of an Object Created Outside of StructureMap

- -

TODO -- Whine about how this is all a workaround bad legacy designs like just about anything in ASP.Net.

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index 3f6ef48..bcbf79d 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

@@ -89,147 +89,27 @@

StructureMap and IDisposable -

Singletons

This one is easy, any object marked as the Singleton lifecycle that implements IDisposable is disposed when the root container is disposed:


-        [Fact]
-        public void singletons_are_disposed_when_the_container_is_disposed()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForSingletonOf<DisposableSingleton>();
-            });
-
-            // As a singleton-scoped object, every request for DisposableSingleton
-            // will return the same object
-            var singleton = container.GetInstance<DisposableSingleton>();
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
-
-            singleton.WasDisposed.ShouldBeFalse();
-
-            // now, dispose the Container
-            container.Dispose();
-
-            // the SingletonThing scoped object should be disposed
-            singleton.WasDisposed.ShouldBeTrue();
-        }
-
-


[Fact]
public void singletons_are_disposed_when_the_container_is_disposed()
{
    var container = new Container(_ =>
    {
        _.ForSingletonOf<DisposableSingleton>();
    });

    // As a singleton-scoped object, every request for DisposableSingleton
    // will return the same object
    var singleton = container.GetInstance<DisposableSingleton>();
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
    singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());

    singleton.WasDisposed.ShouldBeFalse();

    // now, dispose the Container
    container.Dispose();

    // the SingletonThing scoped object should be disposed
    singleton.WasDisposed.ShouldBeTrue();
}

Ejecting a singleton-scoped object will also force it to be disposed. See Using the Container Model for more information on how to eject singletons from a running Container.

Nested Containers

As discussed in Nested Containers (Per Request/Transaction), any transient, AlwaysUnique (as of 4.0), or container-scoped object that implements IDisposable and is created by a nested container will be disposed as the nested container is disposed:


-        [Fact]
-        public void nested_container_disposal()
-        {
-            var container = new Container(_ =>
-            {
-                // A SingletonThing scoped service
-                _.ForSingletonOf<IColorCache>().Use<ColorCache>();
-
-                // A transient scoped service
-                _.For<IColor>().Use<Green>();
-
-                // An AlwaysUnique scoped service
-                _.For<Purple>().AlwaysUnique();
-            });
-
-            ColorCache singleton = null;
-            Green nestedGreen = null;
-            Blue nestedBlue = null;
-            Purple nestedPurple = null;
-
-            using (var nested = container.GetNestedContainer())
-            {
-                // SingletonThing's are really built by the parent
-                singleton = nested.GetInstance<IColorCache>()
-                    .ShouldBeOfType<ColorCache>();
-
-                nestedGreen = nested.GetInstance<IColor>()
-                    .ShouldBeOfType<Green>();
-
-                nestedBlue = nested.GetInstance<Blue>();
-
-                nestedPurple = nested.GetInstance<Purple>();
-            }
-
-            // Transients created by the Nested Container
-            // are disposed
-            nestedGreen.WasDisposed.ShouldBeTrue();
-            nestedBlue.WasDisposed.ShouldBeTrue();
-
-            // Unique's created by the Nested Container
-            // are disposed
-            nestedPurple.WasDisposed.ShouldBeTrue();
-
-            // NOT disposed because it's owned by
-            // the parent container
-            singleton.WasDisposed.ShouldBeFalse();
-        }
-
-

Transients


[Fact]
public void nested_container_disposal()
{
    var container = new Container(_ =>
    {
        // A SingletonThing scoped service
        _.ForSingletonOf<IColorCache>().Use<ColorCache>();

        // A transient scoped service
        _.For<IColor>().Use<Green>();

        // An AlwaysUnique scoped service
        _.For<Purple>().AlwaysUnique();
    });

    ColorCache singleton = null;
    Green nestedGreen = null;
    Blue nestedBlue = null;
    Purple nestedPurple = null;

    using (var nested = container.GetNestedContainer())
    {
        // SingletonThing's are really built by the parent
        singleton = nested.GetInstance<IColorCache>()
            .ShouldBeOfType<ColorCache>();

        nestedGreen = nested.GetInstance<IColor>()
            .ShouldBeOfType<Green>();

        nestedBlue = nested.GetInstance<Blue>();

        nestedPurple = nested.GetInstance<Purple>();
    }

    // Transients created by the Nested Container
    // are disposed
    nestedGreen.WasDisposed.ShouldBeTrue();
    nestedBlue.WasDisposed.ShouldBeTrue();

    // Unique's created by the Nested Container
    // are disposed
    nestedPurple.WasDisposed.ShouldBeTrue();

    // NOT disposed because it's owned by
    // the parent container
    singleton.WasDisposed.ShouldBeFalse();
}

Transients

Regardless of the new tracking/release mode, the StructureMap team still strongly recommends using a nested container per HTTP request or service bus message handling session or logical transaction to deal with disposing transient objects.

By default, StructureMap will not hang on to any transient-scoped objects created by the root or child containers. Dealing with IDisposable is completely up to the user in this case. The StructureMap team has long believed that trying to track transient disposables with an explicit Release(object) mode as other IoC containers behave would do more harm than good (memory leaks from forgetting to call Release(), more work on the user).

That all being said, in order to comply with the new ASP.Net vNext compliance behavior, StructureMap 4.0 introduces a new opt-in transient tracking mode with the prerequisite Release(object) method:


-        [Fact]
-        public void release_transient_created_by_root_container()
-        {
-            var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode);
-
-            container.TransientTracking.ShouldBeOfType<TrackingTransientCache>();
-
-            var transient1 = container.GetInstance<DisposableGuy>();
-            var transient2 = container.GetInstance<DisposableGuy>();
-
-            transient1.WasDisposed.ShouldBeFalse();
-            transient2.WasDisposed.ShouldBeFalse();
-
-            // release ONLY transient2
-            container.Release(transient2);
-
-            transient1.WasDisposed.ShouldBeFalse();
-            transient2.WasDisposed.ShouldBeTrue();
-
-            // transient2 should no longer be
-            // tracked by the container
-            container.TransientTracking.Tracked
-                .Single()
-                .ShouldBeTheSameAs(transient1);
-        }
-
-        [Fact]
-        public void disposing_the_container_disposes_tracked_transients()
-        {
-            var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode);
-
-            var transient1 = container.GetInstance<DisposableGuy>();
-            var transient2 = container.GetInstance<DisposableGuy>();
-
-            transient1.WasDisposed.ShouldBeFalse();
-            transient2.WasDisposed.ShouldBeFalse();
-
-            container.Dispose();
-
-            transient1.WasDisposed.ShouldBeTrue();
-            transient2.WasDisposed.ShouldBeTrue();
-        }
-
-


[Fact]
public void release_transient_created_by_root_container()
{
    var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode);

    container.TransientTracking.ShouldBeOfType<TrackingTransientCache>();

    var transient1 = container.GetInstance<DisposableGuy>();
    var transient2 = container.GetInstance<DisposableGuy>();

    transient1.WasDisposed.ShouldBeFalse();
    transient2.WasDisposed.ShouldBeFalse();

    // release ONLY transient2
    container.Release(transient2);

    transient1.WasDisposed.ShouldBeFalse();
    transient2.WasDisposed.ShouldBeTrue();

    // transient2 should no longer be
    // tracked by the container
    container.TransientTracking.Tracked
        .Single()
        .ShouldBeTheSameAs(transient1);
}

[Fact]
public void disposing_the_container_disposes_tracked_transients()
{
    var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode);

    var transient1 = container.GetInstance<DisposableGuy>();
    var transient2 = container.GetInstance<DisposableGuy>();

    transient1.WasDisposed.ShouldBeFalse();
    transient2.WasDisposed.ShouldBeFalse();

    container.Dispose();

    transient1.WasDisposed.ShouldBeTrue();
    transient2.WasDisposed.ShouldBeTrue();
}

As of right now, StructureMap will only track the top level object requested from a Container and not all the other IDisposable objects that may have been created as part of the main object graph.

@@ -88,67 +88,23 @@

Registering a Single Instance Against Multiple PluginType's - - -

It's not uncommon to want a single instance registration in StructureMap to be mapped to multiple -plugin type interfaces, especially if you have a class that implements multiple role interfaces -to support different consumers.

As a simplified example, let's say that we have a class named StatefulCache that will govern some kind -of application wide state. Some consumers will only need to read or query data, so we'll create an IReader -interface for that role. Other consumers will only make updates to the StatefulCache, so we'll also have -an IWriter interface as shown below:


-        public interface IWriter { }
-
-        public interface IReader { }
-
-        public class StatefulCache : IReader, IWriter
-        {
-        }
-
-

What we need from StructureMap is a way to make all requests to either IReader and IWriter -resolve to the same singleton object instance of StatefulCache.

StructureMap provides the Forward<TFrom, TTo>() mechanism for exactly this purpose:


-        [Fact]
-        public void stateful_cache_serves_multiple_interfaces()
-        {
-            var container = new Container(_ =>
-            {
-                // Let's make StatefulCache a SingletonThing in the container
-                _.ForConcreteType<StatefulCache>().Configure.Singleton();
-
-                _.Forward<StatefulCache, IReader>();
-                _.Forward<StatefulCache, IWriter>();
-            });
-
-            container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
-            container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
-        }
-
-

And because the syntax has consistently been confusing to users (including me even though I wrote it), -here's how to effect the same registration with lambda registrations:


-        [Fact]
-        public void equivalent()
-        {
-            var container = new Container(_ =>
-            {
-                // Let's make StatefulCache a SingletonThing in the container
-                _.ForConcreteType<StatefulCache>().Configure.Singleton();
-
-                _.For<IReader>().Use(c => c.GetInstance<StatefulCache>());
-                _.For<IWriter>().Use(c => c.GetInstance<StatefulCache>());
-            });
-
-            container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
-            container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
-        }
-
-

- + + +

It's not uncommon to want a single instance registration in StructureMap to be mapped to multiple +plugin type interfaces, especially if you have a class that implements multiple role interfaces +to support different consumers.

As a simplified example, let's say that we have a class named StatefulCache that will govern some kind +of application wide state. Some consumers will only need to read or query data, so we'll create an IReader +interface for that role. Other consumers will only make updates to the StatefulCache, so we'll also have +an IWriter interface as shown below:


public interface IWriter { }

public interface IReader { }

public class StatefulCache : IReader, IWriter
{
}

What we need from StructureMap is a way to make all requests to either IReader and IWriter +resolve to the same singleton object instance of StatefulCache.

StructureMap provides the Forward<TFrom, TTo>() mechanism for exactly this purpose:


[Fact]
public void stateful_cache_serves_multiple_interfaces()
{
    var container = new Container(_ =>
    {
        // Let's make StatefulCache a SingletonThing in the container
        _.ForConcreteType<StatefulCache>().Configure.Singleton();

        _.Forward<StatefulCache, IReader>();
        _.Forward<StatefulCache, IWriter>();
    });

    container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
    container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
}

And because the syntax has consistently been confusing to users (including me even though I wrote it), +here's how to effect the same registration with lambda registrations:


[Fact]
public void equivalent()
{
    var container = new Container(_ =>
    {
        // Let's make StatefulCache a SingletonThing in the container
        _.ForConcreteType<StatefulCache>().Configure.Singleton();

        _.For<IReader>().Use(c => c.GetInstance<StatefulCache>());
        _.For<IWriter>().Use(c => c.GetInstance<StatefulCache>());
    });

    container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
    container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
}

@@ -88,182 +88,38 @@

Handling Missing Named Instances - - -

Let's say that something asks StructureMap to resolve a named instance of a type that StructureMap does not know about. What if instead -of throwing the exception for an unknown named service, StructureMap could be taught to create a new registration for that type for the name -requested? That's the exact purpose of the Missing Named Instance feature in StructureMap.

I've always thought of this feature as being somewhat akin to Ruby's Method Missing language feature.

Using the contrived example from the StructureMap tests for this feature, let's say that you have a simple interface and object implementation like this:


-        public interface Rule
-        {
-        }
-
-        public class ColorRule : Rule
-        {
-            public string Color { get; set; }
-
-            public ColorRule(string color)
-            {
-                Color = color;
-            }
-        }
-
-

If a user asks the container for a named Rule by a name and that rule doesn't exist, we'll just build -a ColorRule where the Color property should be the name of the Instance requested. That registration -and the usage is shown below:


-        [Fact]
-        public void configure_and_use_missing_instance()
-        {
-            var container = new Container(x =>
-            {
-                x.For<Rule>().MissingNamedInstanceIs
-                    .ConstructedBy(context => new ColorRule(context.RequestedName));
-            });
-
-            container.GetInstance<Rule>("red")
-                .ShouldBeOfType<ColorRule>().Color.ShouldBe("red");
-
-            container.GetInstance<Rule>("green")
-                .ShouldBeOfType<ColorRule>().Color.ShouldBe("green");
-
-            container.GetInstance<Rule>("blue")
-                .ShouldBeOfType<ColorRule>().Color.ShouldBe("blue");
-        }
-
-

The missing named instance rules are evaluated last, meaning that the container will still resolve -explicitly registered instances:


-        [Fact]
-        public void does_not_override_explicit_registrations()
-        {
-            var container = new Container(x =>
-            {
-                x.For<Rule>().Add(new ColorRule("DarkRed")).Named("red");
-
-                x.For<Rule>().MissingNamedInstanceIs
-                    .ConstructedBy(context => new ColorRule(context.RequestedName));
-            });
-
-            container.GetInstance<Rule>("red")
-                .ShouldBeOfType<ColorRule>()
-                .Color.ShouldBe("DarkRed");
-        }
-
-

You also have the ability to explicitly supply an Instance to be evaluated in the missing named instance -resolution:


-        [Fact]
-        public void configure_and_use_missing_instance_by_generic_registration()
-        {
-            var instance = new LambdaInstance<ColorRule>(c => new ColorRule(c.RequestedName));
-
-            var container = new Container(x =>
-            {
-                x.For(typeof(Rule))
-                    .MissingNamedInstanceIs(instance);
-            });
-
-            container.GetInstance<Rule>("red").ShouldBeOfType<ColorRule>().Color.ShouldBe("red");
-            container.GetInstance<Rule>("green").ShouldBeOfType<ColorRule>().Color.ShouldBe("green");
-            container.GetInstance<Rule>("blue").ShouldBeOfType<ColorRule>().Color.ShouldBe("blue");
-        }
-
-

Multi-Tenancy

To the best of my recollection, the feature described in this section was designed for a multi-tenancy situation where -we needed to allow the business rules to vary by client, but most clients would still be using the default rules. In our -implemenation, we would make a service location call to the container for the rules by the client id and use the -object returned to calculate the business rules (it was an invoice processing service).

If our rules logic class structure looked like:


-        public interface Rule
-        {
-        }
-
-        public class DefaultRule : Rule
-        {
-        }
-
-        public class Client1Rule : Rule
-        {
-        }
-
-        public class Client2Rule : Rule
-        {
-        }
-
-

then we could allow client specific rules while still allowing the container to fall through to the default rules -for clients that don't need customized rules:


-        [Fact]
-        public void use_customer_overrides()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<Rule>().MissingNamedInstanceIs.Type<DefaultRule>();
-
-                _.For<Rule>().Add<Client1Rule>().Named("client1");
-                _.For<Rule>().Add<Client2Rule>().Named("client2");
-            });
-
-            // Client1 & Client2 have explicit registrations
-            container.GetInstance<Rule>("client1").ShouldBeOfType<Client1Rule>();
-            container.GetInstance<Rule>("client2").ShouldBeOfType<Client2Rule>();
-
-            // Client3 has no explicit registration, so falls through to
-            // DefaultRule
-            container.GetInstance<Rule>("client3").ShouldBeOfType<DefaultRule>();
-        }
-
-

In a more complex usage, maybe you need to pull client specific information from a database or configuration files -to construct the rules object. The code below is a partial sample of how you might use the missing named instance -feature to do data lookups inside of StructureMap:


-        public interface IClientRulesRepsitory
-        {
-            ClientRulesData Find(string clientName);
-        }
-
-        public class ClientRulesData
-        {
-        }
-
-        public class DataUsingRule : Rule
-        {
-            private readonly ClientRulesData _data;
-
-            public DataUsingRule(ClientRulesData data)
-            {
-                _data = data;
-            }
-        }
-
-        [Fact]
-        public void register_by_looking_up_data()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<Rule>().MissingNamedInstanceIs.ConstructedBy(
-                    "Building client rules by looking up client data", c =>
-                    {
-                        var data = c.GetInstance<IClientRulesRepsitory>()
-                            .Find(c.RequestedName);
-
-                        return new DataUsingRule(data);
-                    });
-            });
-        }
-
-

- + + +

Let's say that something asks StructureMap to resolve a named instance of a type that StructureMap does not know about. What if instead +of throwing the exception for an unknown named service, StructureMap could be taught to create a new registration for that type for the name +requested? That's the exact purpose of the Missing Named Instance feature in StructureMap.

I've always thought of this feature as being somewhat akin to Ruby's Method Missing language feature.

Using the contrived example from the StructureMap tests for this feature, let's say that you have a simple interface and object implementation like this:


public interface Rule
{
}

public class ColorRule : Rule
{
    public string Color { get; set; }

    public ColorRule(string color)
    {
        Color = color;
    }
}

If a user asks the container for a named Rule by a name and that rule doesn't exist, we'll just build +a ColorRule where the Color property should be the name of the Instance requested. That registration +and the usage is shown below:


[Fact]
public void configure_and_use_missing_instance()
{
    var container = new Container(x =>
    {
        x.For<Rule>().MissingNamedInstanceIs
            .ConstructedBy(context => new ColorRule(context.RequestedName));
    });

    container.GetInstance<Rule>("red")
        .ShouldBeOfType<ColorRule>().Color.ShouldBe("red");

    container.GetInstance<Rule>("green")
        .ShouldBeOfType<ColorRule>().Color.ShouldBe("green");

    container.GetInstance<Rule>("blue")
        .ShouldBeOfType<ColorRule>().Color.ShouldBe("blue");
}

The missing named instance rules are evaluated last, meaning that the container will still resolve +explicitly registered instances:


[Fact]
public void does_not_override_explicit_registrations()
{
    var container = new Container(x =>
    {
        x.For<Rule>().Add(new ColorRule("DarkRed")).Named("red");

        x.For<Rule>().MissingNamedInstanceIs
            .ConstructedBy(context => new ColorRule(context.RequestedName));
    });

    container.GetInstance<Rule>("red")
        .ShouldBeOfType<ColorRule>()
        .Color.ShouldBe("DarkRed");
}

You also have the ability to explicitly supply an Instance to be evaluated in the missing named instance +resolution:


[Fact]
public void configure_and_use_missing_instance_by_generic_registration()
{
    var instance = new LambdaInstance<ColorRule>(c => new ColorRule(c.RequestedName));

    var container = new Container(x =>
    {
        x.For(typeof(Rule))
            .MissingNamedInstanceIs(instance);
    });

    container.GetInstance<Rule>("red").ShouldBeOfType<ColorRule>().Color.ShouldBe("red");
    container.GetInstance<Rule>("green").ShouldBeOfType<ColorRule>().Color.ShouldBe("green");
    container.GetInstance<Rule>("blue").ShouldBeOfType<ColorRule>().Color.ShouldBe("blue");
}

Multi-Tenancy

To the best of my recollection, the feature described in this section was designed for a multi-tenancy situation where +we needed to allow the business rules to vary by client, but most clients would still be using the default rules. In our +implemenation, we would make a service location call to the container for the rules by the client id and use the +object returned to calculate the business rules (it was an invoice processing service).

If our rules logic class structure looked like:


public interface Rule
{
}

public class DefaultRule : Rule
{
}

public class Client1Rule : Rule
{
}

public class Client2Rule : Rule
{
}

then we could allow client specific rules while still allowing the container to fall through to the default rules +for clients that don't need customized rules:


[Fact]
public void use_customer_overrides()
{
    var container = new Container(_ =>
    {
        _.For<Rule>().MissingNamedInstanceIs.Type<DefaultRule>();

        _.For<Rule>().Add<Client1Rule>().Named("client1");
        _.For<Rule>().Add<Client2Rule>().Named("client2");
    });

    // Client1 & Client2 have explicit registrations
    container.GetInstance<Rule>("client1").ShouldBeOfType<Client1Rule>();
    container.GetInstance<Rule>("client2").ShouldBeOfType<Client2Rule>();

    // Client3 has no explicit registration, so falls through to
    // DefaultRule
    container.GetInstance<Rule>("client3").ShouldBeOfType<DefaultRule>();
}

In a more complex usage, maybe you need to pull client specific information from a database or configuration files +to construct the rules object. The code below is a partial sample of how you might use the missing named instance +feature to do data lookups inside of StructureMap:


public interface IClientRulesRepsitory
{
    ClientRulesData Find(string clientName);
}

public class ClientRulesData
{
}

public class DataUsingRule : Rule
{
    private readonly ClientRulesData _data;

    public DataUsingRule(ClientRulesData data)
    {
        _data = data;
    }
}

[Fact]
public void register_by_looking_up_data()
{
    var container = new Container(_ =>
    {
        _.For<Rule>().MissingNamedInstanceIs.ConstructedBy(
            "Building client rules by looking up client data", c =>
            {
                var data = c.GetInstance<IClientRulesRepsitory>()
                    .Find(c.RequestedName);

                return new DataUsingRule(data);
            });
    });
}

@@ -88,12 +88,11 @@

The Container - - -
The primary way to interact with StructureMap is through the `IContainer` interface and `Container` class. The following topics -discuss some of the features and internal workings of the `Container.`
-
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Registering a Single Instance Against Multiple PluginType's
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Lazy Resolution
StructureMap and IDisposable
Working with Primitive Types
- + + +
The primary way to interact with StructureMap is through the `IContainer` interface and `Container` class. The following topics +discuss some of the features and internal workings of the `Container.`
+
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Registering a Single Instance Against Multiple PluginType's
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Lazy Resolution
StructureMap and IDisposable
Working with Primitive Types

@@ -92,36 +92,10 @@

Building Objects with Lambdas Lambda function that can be called to create an object at resolution time.

Using NHibernate's ISession as an example of an object that typically has to be built by using an ISessionFactory object:


-    public interface ISession { }
-
-    public interface ISessionFactory
-    {
-        ISession Build();
-    }
-


public interface ISession { }

public interface ISessionFactory
{
    ISession Build();
}

If we want to allow StructureMap to control the ISession lifecycle and creation, we have to register a Lambda function as the means of creating ISession as shown in this example below:


-    public class SessionFactoryRegistry : Registry
-    {
-        // Let's not worry about how ISessionFactory is built
-        // in this example
-        public SessionFactoryRegistry(ISessionFactory factory)
-        {
-            For<ISessionFactory>().Use(factory);
-
-            // Build ISession with a lambda:
-            For<ISession>().Use("Build ISession from ISessionFactory", c =>
-            {
-                // To resolve ISession, I first pull out
-                // ISessionFactory from the IContext and use that
-                // to build a new ISession. 
-                return c.GetInstance<ISessionFactory>().Build();
-            });
-        }
-    }
-


public class SessionFactoryRegistry : Registry
{
    // Let's not worry about how ISessionFactory is built
    // in this example
    public SessionFactoryRegistry(ISessionFactory factory)
    {
        For<ISessionFactory>().Use(factory);

        // Build ISession with a lambda:
        For<ISession>().Use("Build ISession from ISessionFactory", c =>
        {
            // To resolve ISession, I first pull out
            // ISessionFactory from the IContext and use that
            // to build a new ISession. 
            return c.GetInstance<ISessionFactory>().Build();
        });
    }
}

Lambda registrations can be done with any of the following four signatures:

(Expression<Func<IContext, T>> builder) -- a simple, one line Lambda to build T using IContext

Building Objects with Lambdas Working with the IContext at Build Time for more information.
-

@@ -98,129 +98,24 @@

Lazy Resolution Lazy<T>

Assuming that StructureMap either has an existing configuration for T or can derive a way to build T, you can just declare a dependency on Lazy<T> like this sample:


-        public class WidgetLazyUser
-        {
-            private readonly Lazy<IWidget> _widget;
-
-            public WidgetLazyUser(Lazy<IWidget> widget)
-            {
-                _widget = widget;
-            }
-
-            public IWidget Widget
-            {
-                get { return _widget.Value; }
-            }
-        }
-
-        [Fact]
-        public void lazy_resolution_in_action()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Use<AWidget>();
-            });
-
-            container.GetInstance<WidgetLazyUser>()
-                .Widget.ShouldBeOfType<AWidget>();
-        }
-
-

Func<T>


public class WidgetLazyUser
{
    private readonly Lazy<IWidget> _widget;

    public WidgetLazyUser(Lazy<IWidget> widget)
    {
        _widget = widget;
    }

    public IWidget Widget
    {
        get { return _widget.Value; }
    }
}

[Fact]
public void lazy_resolution_in_action()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();
    });

    container.GetInstance<WidgetLazyUser>()
        .Widget.ShouldBeOfType<AWidget>();
}

Func<T>

Likewise, you can also declare a dependency on Func<T> with very similar mechanics:


-        [Fact]
-        public void build_a_func_that_returns_a_singleton()
-        {
-            var container = new Container(x =>
-            {
-                x.ForSingletonOf<IWidget>().Use<ColorWidget>().Ctor<string>("color").Is("green");
-            });
-
-            var func = container.GetInstance<Func<IWidget>>();
-            var w1 = func();
-            var w2 = func();
-            var w3 = func();
-
-            w1.ShouldBeOfType<ColorWidget>().Color.ShouldBe("green");
-
-            w1.ShouldBeTheSameAs(w2);
-            w1.ShouldBeTheSameAs(w3);
-            w2.ShouldBeTheSameAs(w3);
-        }
-
-


[Fact]
public void build_a_func_that_returns_a_singleton()
{
    var container = new Container(x =>
    {
        x.ForSingletonOf<IWidget>().Use<ColorWidget>().Ctor<string>("color").Is("green");
    });

    var func = container.GetInstance<Func<IWidget>>();
    var w1 = func();
    var w2 = func();
    var w3 = func();

    w1.ShouldBeOfType<ColorWidget>().Color.ShouldBe("green");

    w1.ShouldBeTheSameAs(w2);
    w1.ShouldBeTheSameAs(w3);
    w2.ShouldBeTheSameAs(w3);
}

This functionality predates the introduction of the Lazy type to .Net

Func<string, T>

Finally, you can also declare a dependency on Func<string, T> that will allow you to lazily resolve a dependency of T by name:


-        [Fact]
-        public void build_a_func_by_string()
-        {
-            var container = new Container(x =>
-            {
-                x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("green").Named("green");
-                x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("blue").Named("blue");
-                x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("red").Named("red");
-            });
-
-            var func = container.GetInstance<Func<string, IWidget>>();
-            func("green").ShouldBeOfType<ColorWidget>().Color.ShouldBe("green");
-        }
-
-

Bi-relational Dependency Workaround


[Fact]
public void build_a_func_by_string()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("green").Named("green");
        x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("blue").Named("blue");
        x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("red").Named("red");
    });

    var func = container.GetInstance<Func<string, IWidget>>();
    func("green").ShouldBeOfType<ColorWidget>().Color.ShouldBe("green");
}

Bi-relational Dependency Workaround

StructureMap does not directly support bi-directional dependency relationships -- but will happily tell you in an exception when you accidentally manage to create one without cratering your AppDomain with a StackOverflowException.

Either Func<T> or Lazy<T> can be used as a workaround for purposeful bi-directional dependencies between types. The following is an example of using this strategy:


-
-        [Singleton]
-        public class Thing1
-        {
-            private readonly Lazy<Thing2> _thing2;
-
-            public Thing1(Lazy<Thing2> thing2)
-            {
-                _thing2 = thing2;
-            }
-
-            public Thing2 Thing2
-            {
-                get { return _thing2.Value; }
-            }
-        }
-
-        [Singleton]
-        public class Thing2
-        {
-            public Thing1 Thing1 { get; set; }
-
-            public Thing2(Thing1 thing1)
-            {
-                Thing1 = thing1;
-            }
-        }
-
-        [Fact]
-        public void use_lazy_as_workaround_for_bi_directional_dependency()
-        {
-            var container = new Container();
-            var thing1 = container.GetInstance<Thing1>();
-            var thing2 = container.GetInstance<Thing2>();
-
-            thing1.Thing2.ShouldBeSameAs(thing2);
-            thing2.Thing1.ShouldBeSameAs(thing1);
-        }
-
-

- +



[Singleton]
public class Thing1
{
    private readonly Lazy<Thing2> _thing2;

    public Thing1(Lazy<Thing2> thing2)
    {
        _thing2 = thing2;
    }

    public Thing2 Thing2
    {
        get { return _thing2.Value; }
    }
}

[Singleton]
public class Thing2
{
    public Thing1 Thing1 { get; set; }

    public Thing2(Thing1 thing1)
    {
        Thing1 = thing1;
    }
}

[Fact]
public void use_lazy_as_workaround_for_bi_directional_dependency()
{
    var container = new Container();
    var thing1 = container.GetInstance<Thing1>();
    var thing2 = container.GetInstance<Thing2>();

    thing1.Thing2.ShouldBeSameAs(thing2);
    thing2.Thing1.ShouldBeSameAs(thing1);
}

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 2cb0efd..38bc84d 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -31,7 +31,7 @@

@@ -88,326 +88,76 @@

Nested Containers (Per Request/Transaction) - - -
Nested Containers are not interchangeable with Child Containers. See for more information on child containers.
-
Nested Container's are a powerful feature in StructureMap for service resolution and clean object disposal in the -context of short lived operations. Nested Container's were introduced in version 2.6, but greatly improved in both performance (100X reduction in the time to create a nested container in a large application) and ahem lifecycle -mechanics as a major goal of the 3.0 release.
-

History

The original use case and impetus for building this feature was a simplistic message handling system that dequeued -messages from a Sql Server table (please forget for a second the wisdom of using Sql Server as a queueing system), deserialized -the contents into a .Net object, then created the proper handler object for that message type and executed that handler -- all within -a single transaction. What we wanted at the time was a way to track and clean up all IDisposable objects created during the lifespan of each -transaction. We also wanted a new type of object lifecycle where objects like the NHibernate ISession would be shared by every object -created during the lifetime of the nested container -- even if the ISession was resolved lazily after the intial -resolution of the message handler. The result was what is now the nested container feature -of StructureMap.

Why Nested Containers over HttpContext or ThreadLocal Scoping?

Why not just use HttpContext based lifecycles like we've always done in the past? Because HttpContext is not supported by any -type of OWIN web host and will not be a part of ASP.Net vNext. Using a Nested Container per HTTP request is a better, lighterweight way -to scope services to an HTTP request without coupling your code to what will soon be legacy ASP.Net runtime code.

Who uses it?

At the time of this document, Nested Container's per HTTP request are supported by frameworks like FubuMVC, -ASP.Net MVC through the StructureMap.MVC5 nuget package, and Web API with the StructureMap.WebApi2 nuget. Several service bus frameworks also use a StructureMap nested container per message invocation including FubuTransportation, -MassTransit, and NServiceBus.

Creation

Creating a nested container is as simple as calling the IContainer.GetNestedContainer() method as shown below:


-        public interface IWorker
-        {
-            void DoWork();
-        }
-
-        public class Worker : IWorker, IDisposable
-        {
-            public void DoWork()
-            {
-                // do stuff!
-            }
-
-            public void Dispose()
-            {
-                // clean up
-            }
-        }
-
-        [Fact]
-        public void creating_a_nested_container()
-        {
-            // From an IContainer object
-            var container = new Container(_ => { _.For<IWorker>().Use<Worker>(); });
-
-            using (var nested = container.GetNestedContainer())
-            {
-                // This object is disposed when the nested container
-                // is disposed
-                var worker = nested.GetInstance<IWorker>();
-                worker.DoWork();
-            }
-        }
-
-

Lifecycle Rules

While StructureMap supports several object instance lifecycles out of the box, in idiomatic usage of StructureMap the only common lifecyles are:

Transient - The default lifecycle. A new object is created for a configured Instance on each request to the container
Singleton - One instance is constructed and used over the entire Container lifetime

In the context of a Nested Container however, the Transient scoping now applies to the Nested Container itself:


-        [Fact]
-        public void nested_container_behavior_of_transients()
-        {
-            // "Transient" is the default lifecycle
-            // in StructureMap
-            var container = new Container(_ => { _.For<IColor>().Use<Green>(); });
-
-            // In a normal Container, a "transient" lifecycle
-            // Instance will be built up once in every request
-            // to the Container
-            container.GetInstance<IColor>()
-                .ShouldNotBeTheSameAs(container.GetInstance<IColor>());
-
-            // From a nested container, the "transient" lifecycle
-            // is tracked to the nested container
-            using (var nested = container.GetNestedContainer())
-            {
-                nested.GetInstance<IColor>()
-                    .ShouldBeTheSameAs(nested.GetInstance<IColor>());
-
-                // One more time
-                nested.GetInstance<IColor>()
-                    .ShouldBeTheSameAs(nested.GetInstance<IColor>());
-            }
-        }
-
-

Instances scoped to anything but Transient or AlwaysUnique are resolved as normal, but through the parent container:


-        [Fact]
-        public void nested_container_usage_of_singletons()
-        {
-            var container = new Container(_ => { _.ForSingletonOf<IColorCache>().Use<ColorCache>(); });
-
-            var singleton = container.GetInstance<IColorCache>();
-
-            // SingletonThing's are resolved from the parent container
-            using (var nested = container.GetNestedContainer())
-            {
-                nested.GetInstance<IColorCache>()
-                    .ShouldBeTheSameAs(singleton);
-            }
-        }
-
-

See <linkto:object-lifecycle]> for more information on supported object lifecycles.

Overriding Services from the Parent

A nested container is a new Container object that still retains access to the parent container that created it so that it can -efficiently share registrations, policies, and cached build plans. You can, however, register services into the nested container that override the parent container.

There is no need to recreate registrations from the parent container -into the nested container and doing so makes StructureMap work less efficiently.

The FubuMVC web framework uses a nested container per HTTP request. During an HTTP request, FubuMVC injects services -for the current HTTP request and response to a nested container before creating the actual services that will handle the request. The -FubuMVC mechanics are conceptually similar to this code sample:


-        [Fact]
-        public void overriding_services_in_a_nested_container()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IHttpRequest>().Use<StandInHttpRequest>();
-                _.For<IHttpResponse>().Use<StandInHttpResponse>();
-            });
-
-            var request = new HttpRequest();
-            var response = new HttpResponse();
-
-            using (var nested = container.GetNestedContainer())
-            {
-                // Override the HTTP request and response for this
-                // nested container
-                nested.Configure(_ =>
-                {
-                    _.For<IHttpRequest>().Use(request);
-                    _.For<IHttpResponse>().Use(response);
-                });
-
-                var handler = nested.GetInstance<HttpRequestHandler>();
-                handler.Request.ShouldBeTheSameAs(request);
-                handler.Response.ShouldBeTheSameAs(response);
-            }
-
-            // Outside the nested container, we still have the original
-            // registrations
-            container.GetInstance<IHttpRequest>()
-                .ShouldBeOfType<StandInHttpRequest>();
-
-            container.GetInstance<IHttpResponse>()
-                .ShouldBeOfType<StandInHttpResponse>();
-        }
-
-

The StructureMap team strongly cautions against altering the configuration of the main application container, but overriding services in a nested container is useful (but please upgrade to at least version 3.1.2) and should not incur any problems with locking across threads.

When handling requests for new services, a nested container first checks its own configuration if it has its own explicit registration for the request. If the nested container does have an explicit registration, it uses that registration. Otherwise, a nested container will attempt to build -an object using the registered configuration of its parent container.

While the 3.0 version of nested containers acts like a Chain of Responsibility pattern to apply its own overrides, the earlier version - of StructureMap made a complete copy of the underlying Container configuration. This crime against computer science was removed in 3.0 and hence, the 100X - improvement in the time it takes StructureMap to create a nested container.

Lazy Resolution

Nested container object lifecycles equally apply to objects resolved lazily with -either Lazy<T>, Func<T>, or Func<string, T> as shown below:


-        public class Foo
-        {
-        }
-
-        public class FooHolder
-        {
-            public IContainer Container { get; set; }
-            public Func<Foo> Func { get; set; }
-            public Lazy<Foo> Lazy { get; set; }
-
-            public FooHolder(IContainer container, Func<Foo> func, Lazy<Foo> lazy)
-            {
-                Container = container;
-                Func = func;
-                Lazy = lazy;
-            }
-        }
-
-        [Fact]
-        public void service_location_and_container_resolution_inside_nested_containers()
-        {
-            var container = new Container();
-
-            using (var nested = container.GetNestedContainer())
-            {
-                var holder = nested.GetInstance<FooHolder>();
-
-                // The injected IContainer is the nested container
-                holder.Container.ShouldBeTheSameAs(nested);
-
-                // Func<T> and Lazy<T> values will be built by
-                // the nested container w/ the nested container
-                // scoping
-                var nestedFoo = nested.GetInstance<Foo>();
-
-                holder.Func().ShouldBeTheSameAs(nestedFoo);
-                holder.Lazy.Value.ShouldBeTheSameAs(nestedFoo);
-            }
-        }
-
-

Do note that the IContainer object injected above was the nested container that -created the FooHandler object. If you do want to use service location within an object, just take in -IContainer as a constructor dependency and you will always get the correctly scoped IContainer.

Profiles

You can created nested containers from profile containers as shown in the sample below:

<sample:nested-profiles]>

See Profiles and Child Containers for more information about using profiles.

Disposing Services

As stated above, disposing a nested container will also dispose all objects created with the default Transient lifecycle by the -nested container that implement the IDisposable interface. That behavior is demonstrated -below:


-        [Fact]
-        public void nested_container_disposal()
-        {
-            var container = new Container(_ =>
-            {
-                // A SingletonThing scoped service
-                _.ForSingletonOf<IColorCache>().Use<ColorCache>();
-
-                // A transient scoped service
-                _.For<IColor>().Use<Green>();
-
-                // An AlwaysUnique scoped service
-                _.For<Purple>().AlwaysUnique();
-            });
-
-            ColorCache singleton = null;
-            Green nestedGreen = null;
-            Blue nestedBlue = null;
-            Purple nestedPurple = null;
-
-            using (var nested = container.GetNestedContainer())
-            {
-                // SingletonThing's are really built by the parent
-                singleton = nested.GetInstance<IColorCache>()
-                    .ShouldBeOfType<ColorCache>();
-
-                nestedGreen = nested.GetInstance<IColor>()
-                    .ShouldBeOfType<Green>();
-
-                nestedBlue = nested.GetInstance<Blue>();
-
-                nestedPurple = nested.GetInstance<Purple>();
-            }
-
-            // Transients created by the Nested Container
-            // are disposed
-            nestedGreen.WasDisposed.ShouldBeTrue();
-            nestedBlue.WasDisposed.ShouldBeTrue();
-
-            // Unique's created by the Nested Container
-            // are disposed
-            nestedPurple.WasDisposed.ShouldBeTrue();
-
-            // NOT disposed because it's owned by
-            // the parent container
-            singleton.WasDisposed.ShouldBeFalse();
-        }
-
-

For the sake of clarity, the classes used in the sample above are:


-    public interface IColor
-    {
-    }
-
-    public class Red : IColor
-    {
-    }
-
-    public class Purple : Blue { }
-
-    public class Blue : IColor, IDisposable
-    {
-        public bool WasDisposed;
-
-        public void Dispose()
-        {
-            WasDisposed = true;
-        }
-    }
-
-    public class Green : IColor, IDisposable
-    {
-        public bool WasDisposed;
-
-        public void Dispose()
-        {
-            WasDisposed = true;
-        }
-    }
-
-    public interface IColorCache
-    {
-    }
-
-    public class ColorCache : IColorCache, IDisposable
-    {
-        public bool WasDisposed;
-
-        public void Dispose()
-        {
-            WasDisposed = true;
-        }
-    }
-
-

- + + +

Nested Containers are not interchangeable with Child Containers. See Profiles and Child Containers for more information on child containers.

Nested Container's are a powerful feature in StructureMap for service resolution and clean object disposal in the +context of short lived operations. Nested Container's were introduced in version 2.6, but greatly improved in both performance (100X reduction in the time to create a nested container in a large application) and ahem lifecycle +mechanics as a major goal of the 3.0 release.

History

The original use case and impetus for building this feature was a simplistic message handling system that dequeued +messages from a Sql Server table (please forget for a second the wisdom of using Sql Server as a queueing system), deserialized +the contents into a .Net object, then created the proper handler object for that message type and executed that handler -- all within +a single transaction. What we wanted at the time was a way to track and clean up all IDisposable objects created during the lifespan of each +transaction. We also wanted a new type of object lifecycle where objects like the NHibernate ISession would be shared by every object +created during the lifetime of the nested container -- even if the ISession was resolved lazily after the intial +resolution of the message handler. The result was what is now the nested container feature +of StructureMap.

Why Nested Containers over HttpContext or ThreadLocal Scoping?

Why not just use HttpContext based lifecycles like we've always done in the past? Because HttpContext is not supported by any +type of OWIN web host and will not be a part of ASP.Net vNext. Using a Nested Container per HTTP request is a better, lighterweight way +to scope services to an HTTP request without coupling your code to what will soon be legacy ASP.Net runtime code.

Who uses it?

At the time of this document, Nested Container's per HTTP request are supported by frameworks like FubuMVC, +ASP.Net MVC through the StructureMap.MVC5 nuget package, and Web API with the StructureMap.WebApi2 nuget. Several service bus frameworks also use a StructureMap nested container per message invocation including FubuTransportation, +MassTransit, and NServiceBus.

Creation

Creating a nested container is as simple as calling the IContainer.GetNestedContainer() method as shown below:


public interface IWorker
{
    void DoWork();
}

public class Worker : IWorker, IDisposable
{
    public void DoWork()
    {
        // do stuff!
    }

    public void Dispose()
    {
        // clean up
    }
}

[Fact]
public void creating_a_nested_container()
{
    // From an IContainer object
    var container = new Container(_ => { _.For<IWorker>().Use<Worker>(); });

    using (var nested = container.GetNestedContainer())
    {
        // This object is disposed when the nested container
        // is disposed
        var worker = nested.GetInstance<IWorker>();
        worker.DoWork();
    }
}

Lifecycle Rules

While StructureMap supports several object instance lifecycles out of the box, in idiomatic usage of StructureMap the only common lifecyles are:

Transient - The default lifecycle. A new object is created for a configured Instance on each request to the container
Singleton - One instance is constructed and used over the entire Container lifetime

In the context of a Nested Container however, the Transient scoping now applies to the Nested Container itself:


[Fact]
public void nested_container_behavior_of_transients()
{
    // "Transient" is the default lifecycle
    // in StructureMap
    var container = new Container(_ => { _.For<IColor>().Use<Green>(); });

    // In a normal Container, a "transient" lifecycle
    // Instance will be built up once in every request
    // to the Container
    container.GetInstance<IColor>()
        .ShouldNotBeTheSameAs(container.GetInstance<IColor>());

    // From a nested container, the "transient" lifecycle
    // is tracked to the nested container
    using (var nested = container.GetNestedContainer())
    {
        nested.GetInstance<IColor>()
            .ShouldBeTheSameAs(nested.GetInstance<IColor>());

        // One more time
        nested.GetInstance<IColor>()
            .ShouldBeTheSameAs(nested.GetInstance<IColor>());
    }
}

Instances scoped to anything but Transient or AlwaysUnique are resolved as normal, but through the parent container:


[Fact]
public void nested_container_usage_of_singletons()
{
    var container = new Container(_ => { _.ForSingletonOf<IColorCache>().Use<ColorCache>(); });

    var singleton = container.GetInstance<IColorCache>();

    // SingletonThing's are resolved from the parent container
    using (var nested = container.GetNestedContainer())
    {
        nested.GetInstance<IColorCache>()
            .ShouldBeTheSameAs(singleton);
    }
}

See Object Lifecycles for more information on supported object lifecycles.

Overriding Services from the Parent

A nested container is a new Container object that still retains access to the parent container that created it so that it can +efficiently share registrations, policies, and cached build plans. You can, however, register services into the nested container that override the parent container.

There is no need to recreate registrations from the parent container +into the nested container and doing so makes StructureMap work less efficiently.

The FubuMVC web framework uses a nested container per HTTP request. During an HTTP request, FubuMVC injects services +for the current HTTP request and response to a nested container before creating the actual services that will handle the request. The +FubuMVC mechanics are conceptually similar to this code sample:


[Fact]
public void overriding_services_in_a_nested_container()
{
    var container = new Container(_ =>
    {
        _.For<IHttpRequest>().Use<StandInHttpRequest>();
        _.For<IHttpResponse>().Use<StandInHttpResponse>();
    });

    var request = new HttpRequest();
    var response = new HttpResponse();

    using (var nested = container.GetNestedContainer())
    {
        // Override the HTTP request and response for this
        // nested container
        nested.Configure(_ =>
        {
            _.For<IHttpRequest>().Use(request);
            _.For<IHttpResponse>().Use(response);
        });

        var handler = nested.GetInstance<HttpRequestHandler>();
        handler.Request.ShouldBeTheSameAs(request);
        handler.Response.ShouldBeTheSameAs(response);
    }

    // Outside the nested container, we still have the original
    // registrations
    container.GetInstance<IHttpRequest>()
        .ShouldBeOfType<StandInHttpRequest>();

    container.GetInstance<IHttpResponse>()
        .ShouldBeOfType<StandInHttpResponse>();
}

When handling requests for new services, a nested container first checks its own configuration if it has its own explicit registration for the request. If the nested container does have an explicit registration, it uses that registration. Otherwise, a nested container will attempt to build +an object using the registered configuration of its parent container.

While the 3.0 version of nested containers acts like a Chain of Responsibility pattern to apply its own overrides, the earlier version + of StructureMap made a complete copy of the underlying Container configuration. This crime against computer science was removed in 3.0 and hence, the 100X + improvement in the time it takes StructureMap to create a nested container.

Lazy Resolution

Nested container object lifecycles equally apply to objects resolved lazily with +either Lazy<T>, Func<T>, or Func<string, T> as shown below:


public class Foo
{
}

public class FooHolder
{
    public IContainer Container { get; set; }
    public Func<Foo> Func { get; set; }
    public Lazy<Foo> Lazy { get; set; }

    public FooHolder(IContainer container, Func<Foo> func, Lazy<Foo> lazy)
    {
        Container = container;
        Func = func;
        Lazy = lazy;
    }
}

[Fact]
public void service_location_and_container_resolution_inside_nested_containers()
{
    var container = new Container();

    using (var nested = container.GetNestedContainer())
    {
        var holder = nested.GetInstance<FooHolder>();

        // The injected IContainer is the nested container
        holder.Container.ShouldBeTheSameAs(nested);

        // Func<T> and Lazy<T> values will be built by
        // the nested container w/ the nested container
        // scoping
        var nestedFoo = nested.GetInstance<Foo>();

        holder.Func().ShouldBeTheSameAs(nestedFoo);
        holder.Lazy.Value.ShouldBeTheSameAs(nestedFoo);
    }
}

Do note that the IContainer object injected above was the nested container that +created the FooHandler object. If you do want to use service location within an object, just take in +IContainer as a constructor dependency and you will always get the correctly scoped IContainer.

Profiles

You can created nested containers from profile containers as shown in the sample below:


[Fact]
public void nested_container_from_profile_container()
{
    var container = new Container(x =>
    {
        x.For<IColor>().Use<Red>();

        x.Profile("Blue", _ => _.For<IColor>().Use<Blue>());
        x.Profile("Green", _ => _.For<IColor>().Use<Green>());
    });

    using (var nested = container.GetProfile("Blue").GetNestedContainer())
    {
        nested.GetInstance<IColor>().ShouldBeOfType<Blue>();
    }

    using (var nested = container.GetNestedContainer("Green"))
    {
        nested.GetInstance<IColor>().ShouldBeOfType<Green>();
    }
}

See Profiles and Child Containers for more information about using profiles.

Disposing Services

As stated above, disposing a nested container will also dispose all objects created with the default Transient lifecycle by the +nested container that implement the IDisposable interface. That behavior is demonstrated +below:


[Fact]
public void nested_container_disposal()
{
    var container = new Container(_ =>
    {
        // A SingletonThing scoped service
        _.ForSingletonOf<IColorCache>().Use<ColorCache>();

        // A transient scoped service
        _.For<IColor>().Use<Green>();

        // An AlwaysUnique scoped service
        _.For<Purple>().AlwaysUnique();
    });

    ColorCache singleton = null;
    Green nestedGreen = null;
    Blue nestedBlue = null;
    Purple nestedPurple = null;

    using (var nested = container.GetNestedContainer())
    {
        // SingletonThing's are really built by the parent
        singleton = nested.GetInstance<IColorCache>()
            .ShouldBeOfType<ColorCache>();

        nestedGreen = nested.GetInstance<IColor>()
            .ShouldBeOfType<Green>();

        nestedBlue = nested.GetInstance<Blue>();

        nestedPurple = nested.GetInstance<Purple>();
    }

    // Transients created by the Nested Container
    // are disposed
    nestedGreen.WasDisposed.ShouldBeTrue();
    nestedBlue.WasDisposed.ShouldBeTrue();

    // Unique's created by the Nested Container
    // are disposed
    nestedPurple.WasDisposed.ShouldBeTrue();

    // NOT disposed because it's owned by
    // the parent container
    singleton.WasDisposed.ShouldBeFalse();
}

For the sake of clarity, the classes used in the sample above are:


public interface IColor
{
}

public class Red : IColor
{
}

public class Purple : Blue { }

public class Blue : IColor, IDisposable
{
    public bool WasDisposed;

    public void Dispose()
    {
        WasDisposed = true;
    }
}

public class Green : IColor, IDisposable
{
    public bool WasDisposed;

    public void Dispose()
    {
        WasDisposed = true;
    }
}

public interface IColorCache
{
}

public class ColorCache : IColorCache, IDisposable
{
    public bool WasDisposed;

    public void Dispose()
    {
        WasDisposed = true;
    }
}

@@ -94,110 +94,23 @@

Working with Primitive Types inline dependencies.

To make this concrete, if you ask StructureMap to build a concrete type that has dependencies on simple types without like this example, StructureMap will throw an exception telling you that it cannot build the instance:


-        public class GuyWithNoDefaultName
-        {
-            // StructureMap will not use any kind of auto-wiring
-            // on name
-            public GuyWithNoDefaultName(string name)
-            {
-            }
-        }
-
-        [Fact]
-        public void cannot_build_simple_arguments()
-        {
-            var container = new Container();
-
-            Exception<StructureMapBuildPlanException>.ShouldBeThrownBy(() =>
-            {
-                container.GetInstance<GuyWithNoDefaultName>();
-            });
-        }
-
-


public class GuyWithNoDefaultName
{
    // StructureMap will not use any kind of auto-wiring
    // on name
    public GuyWithNoDefaultName(string name)
    {
    }
}

[Fact]
public void cannot_build_simple_arguments()
{
    var container = new Container();

    Exception<StructureMapBuildPlanException>.ShouldBeThrownBy(() =>
    {
        container.GetInstance<GuyWithNoDefaultName>();
    });
}

Part of the exception message thrown in the unit test shown above is the erroneous build plan showing you that the name parameter has to be defined:

-    new GuyWithNoDefaultName(String name)
-      ┗ String name = Required primitive dependency is not explicitly defined
+	new GuyWithNoDefaultName(String name)
+	  ┗ String name = Required primitive dependency is not explicitly defined

We can build GuyWithNoDefaultName by supplying a value for name as I did in the following sample:


-        [Fact]
-        public void can_build_with_explicit_argument()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForConcreteType<GuyWithNoDefaultName>()
-                    .Configure.Ctor<string>("name").Is("Steve Winwood");
-            });
-
-            container.GetInstance<GuyWithNoDefaultName>()
-                .ShouldNotBeNull();
-        }
-
-


[Fact]
public void can_build_with_explicit_argument()
{
    var container = new Container(_ =>
    {
        _.ForConcreteType<GuyWithNoDefaultName>()
            .Configure.Ctor<string>("name").Is("Steve Winwood");
    });

    container.GetInstance<GuyWithNoDefaultName>()
        .ShouldNotBeNull();
}

See Construction Policies for an example of using a constructor policy to set a dependency on a "connectionString" argument in a conventional way.

Default Values

As a new feature in the 4.0 release, StructureMap can finally take advantage of default parameter arguments to derive the values for a primitive argument (or setter value) while still allowing you to explicitly define that parameter or setter value:


-        // I was listening to Jim Croce's "I've got a Name" song
-        // when I wrote this feature;)
-        public class GuyWithName
-        {
-            public GuyWithName(string name = "Jim Croce")
-            {
-                Name = name;
-            }
-
-            public string Name { get; set; }
-        }
-
-        [Fact]
-        public void uses_the_default_value_if_one_exists()
-        {
-            var container = new Container();
-
-            // Should happily build with the default
-            // value of 'name'
-            container.GetInstance<GuyWithName>()
-                .Name.ShouldBe("Jim Croce");
-        }
-
-        [Fact]
-        public void uses_the_default_value_if_one_exists_2()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForConcreteType<GuyWithName>();
-            });
-
-            // Should happily build with the default
-            // value of 'name'
-            container.GetInstance<GuyWithName>()
-                .Name.ShouldBe("Jim Croce");
-        }
-
-        [Fact]
-        public void use_explicit_dependency_if_one_exists()
-        {
-            var container = new Container(_ =>
-            {
-                _.ForConcreteType<GuyWithName>()
-                    .Configure.Ctor<string>("name").Is("Eric Clapton");
-            });
-
-            container.GetInstance<GuyWithName>()
-                .Name.ShouldBe("Eric Clapton");
-        }
-
-

- +


// I was listening to Jim Croce's "I've got a Name" song
// when I wrote this feature;)
public class GuyWithName
{
    public GuyWithName(string name = "Jim Croce")
    {
        Name = name;
    }

    public string Name { get; set; }
}

[Fact]
public void uses_the_default_value_if_one_exists()
{
    var container = new Container();

    // Should happily build with the default
    // value of 'name'
    container.GetInstance<GuyWithName>()
        .Name.ShouldBe("Jim Croce");
}

[Fact]
public void uses_the_default_value_if_one_exists_2()
{
    var container = new Container(_ =>
    {
        _.ForConcreteType<GuyWithName>();
    });

    // Should happily build with the default
    // value of 'name'
    container.GetInstance<GuyWithName>()
        .Name.ShouldBe("Jim Croce");
}

[Fact]
public void use_explicit_dependency_if_one_exists()
{
    var container = new Container(_ =>
    {
        _.ForConcreteType<GuyWithName>()
            .Configure.Ctor<string>("name").Is("Eric Clapton");
    });

    container.GetInstance<GuyWithName>()
        .Name.ShouldBe("Eric Clapton");
}

@@ -88,182 +88,51 @@

Profiles and Child Containers - - -
Child Containers are not interchangeable with Nested Containers. See for more information on nested containers.
-
The single best source for information about the particulars of child container behavior is to look through the acceptance tests for child containers and -profiles. -from the code in GitHub.
-

Child Containers

The easiest way to explain a child container is to just show it in action:


-        [Fact]
-        public void show_a_child_container_in_action()
-        {
-            var parent = new Container(_ =>
-            {
-                _.For<IWidget>().Use<AWidget>();
-                _.For<IService>().Use<AService>();
-            });
-
-            // Create a child container and override the
-            // IService registration
-            var child = parent.CreateChildContainer();
-            child.Configure(_ =>
-            {
-                _.For<IService>().Use<ChildSpecialService>();
-            });
-
-            // The child container has a specific registration
-            // for IService, so use that one
-            child.GetInstance<IService>()
-                .ShouldBeOfType<ChildSpecialService>();
-
-            // The child container does not have any
-            // override of IWidget, so it uses its parent's
-            // configuration to resolve IWidget
-            child.GetInstance<IWidget>()
-                .ShouldBeOfType<AWidget>();
-        }
-
-

Child Container's are a mechanism to make a completely new Container that can override some of the parent Container's registrations but still -fall back to the parent Container to fulfill any request that is not explicitly configured to the child container. The behavior of a child container -in how it resolves services and allows you to override the parent container is very similar to a nested container, but the crucial difference is in how the two concepts handle lifecycles and calling IDisposable.Dispose().

A couple salient facts about child containers that should (knock on wood) dispel the confusion about when and why to use them versus a nested container:

Child Containers do not change how the default transient lifecycle behaves.
Child Containers (and Profiles) were intended to be used to establish different service resolutions for different subsystems of the running system or -to isolate registration overrides for specific types of users or customers (multi-tenancy).

Profiles

Profiles were completely redesigned as part of the big 3.0 release.

Profiles are just named child containers that may be configured upfront through Registry configurations. -Profiles are one of the oldest features that date back to the very beginning of StructureMap. Originally profile's were conceived of as -a way to vary StructureMap registrations by development environment as the code moved from running locally on a developer's box to testing -servers to production. While that usage is still valid, it is probably more common to use profiles to define overrides for how StructureMap -should resolve services in different modes of the application (connected vs offline) or different types of system users.


-        [Fact]
-        public void Add_default_instance_with_concrete_type()
-        {
-            IContainer container = new Container(registry =>
-            {
-                registry.Profile("something", p =>
-                {
-                    p.For<IWidget>().Use<AWidget>();
-                    p.For<Rule>().Use<DefaultRule>();
-                });
-            });
-
-            var profile = container.GetProfile("something");
-
-            profile.GetInstance<IWidget>().ShouldBeOfType<AWidget>();
-            profile.GetInstance<Rule>().ShouldBeOfType<DefaultRule>();
-        }
-
-

Child Containers and Singletons

If you register a new Instance directly to a child container, that registration is really scoped as a -singleton within the usage of that particular child container:


-        [Fact]
-        public void singletons_to_child_container_are_isolated()
-        {
-            var parentContainer = new Container(_ =>
-            {
-                _.For<IDependency>().Use<Dependency>();
-            });
-
-            var child1 = parentContainer.CreateChildContainer();
-            child1.Configure(x =>
-            {
-                x.ForSingletonOf<IRoot>().Use<Root>();
-            });
-
-            var child2 = parentContainer.CreateChildContainer();
-            child2.Configure(x =>
-            {
-                x.ForSingletonOf<IRoot>().Use<Root>();
-            });
-
-            // IRoot is a "singleton" within child1 usage
-            child1.GetInstance<IRoot>().ShouldBeSameAs(child1.GetInstance<IRoot>());
-
-            // IRoot is a "singleton" within child2 usage
-            child2.GetInstance<IRoot>().ShouldBeSameAs(child2.GetInstance<IRoot>());
-
-            // but, child1 and child2 both have a different IRoot
-            child1.GetInstance<IRoot>()
-                .ShouldNotBeTheSameAs(child2.GetInstance<IRoot>());
-        }
-
-

Creating a Nested Container from a Child Container

It is perfectly valid to create a nested container from a child container for short-lived requests or transactions:


-        [Fact]
-        public void nested_container_from_child()
-        {
-            var parent = new Container(_ =>
-            {
-                _.For<IWidget>().Use<AWidget>();
-                _.For<IService>().Use<AService>();
-            });
-
-            // Create a child container and override the
-            // IService registration
-            var child = parent.CreateChildContainer();
-            child.Configure(_ =>
-            {
-                _.For<IService>().Use<ChildSpecialService>();
-            });
-
-            using (var nested = child.GetNestedContainer())
-            {
-                nested.GetInstance<IService>()
-                    .ShouldBeOfType<ChildSpecialService>();
-            }
-        }
-
-

Example: Child Containers in Automated Testing

My shop has been somewhat successful in writing automated integration tests in a whitebox testing style -where we happily "swap out" a handful of external services with a stubbed service that we can happily control -to either setup system state or measure the interaction of our system with the stub (outgoing emails etc) -- with the canonical -example being a web service that our biggest application has to call for authentication purposes that is frequently unavailable during -our development efforts and not quite reliable even when it is available:.

That's great, and the stubs certainly help the testing efforts be more productive. Until the stateful stubs we inject in one test end up bleeding into -another test as de facto shared state and making those tests fail in ways that were very difficult to diagnose. To combat this problem of test isolation, -we've introduced the idea of using a clean child container per integration test so that the test harness tools can happily -swap in stubs without impacting other tests in the test suite.

In action, that usage looks something like this:


-        public class TheRealService : IService { }
-
-        public class StubbedService : IService { }
-
-        [Fact]
-        public void in_testing()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IService>().Use<TheRealService>();
-            });
-
-            // Create a new child container for only this test
-            var testContainer = container.CreateChildContainer();
-
-            // Override a service with a stub that's easier to control
-            var stub = new StubbedService();
-            testContainer.Inject<IService>(stub);
-
-            // Now, continue with the test resolving application
-            // services through the new child container....
-        }
-
-

- + + +

Child Containers are not interchangeable with Nested Containers. See Nested Containers (Per Request/Transaction) for more information on nested containers.

The single best source for information about the particulars of child container behavior is to look through the acceptance tests for child containers and +profiles. +from the code in GitHub.

Child Containers

The easiest way to explain a child container is to just show it in action:


[Fact]
public void show_a_child_container_in_action()
{
    var parent = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();
        _.For<IService>().Use<AService>();
    });

    // Create a child container and override the
    // IService registration
    var child = parent.CreateChildContainer();
    child.Configure(_ =>
    {
        _.For<IService>().Use<ChildSpecialService>();
    });

    // The child container has a specific registration
    // for IService, so use that one
    child.GetInstance<IService>()
        .ShouldBeOfType<ChildSpecialService>();

    // The child container does not have any
    // override of IWidget, so it uses its parent's
    // configuration to resolve IWidget
    child.GetInstance<IWidget>()
        .ShouldBeOfType<AWidget>();
}

Child Containers are a mechanism to make a completely new Container that can override some of the parent Container's registrations but still +fall back to the parent Container to fulfill any request that is not explicitly configured to the child container. The behavior of a child container +in how it resolves services and allows you to override the parent container is very similar to a nested container, but the crucial difference is in how the two concepts handle lifecycles and calling IDisposable.Dispose().

A couple salient facts about child containers that should (knock on wood) dispel the confusion about when and why to use them versus a nested container:

Child Containers do not change how the default transient lifecycle behaves.
Child Containers (and Profiles) were intended to be used to establish different service resolutions for different subsystems of the running system or +to isolate registration overrides for specific types of users or customers (multi-tenancy).

Profiles

Profiles were completely redesigned as part of the big 3.0 release.

Profiles are just named child containers that may be configured upfront through Registry configurations. +Profiles are one of the oldest features that date back to the very beginning of StructureMap. Originally profiles were conceived of as +a way to vary StructureMap registrations by development environment as the code moved from running locally on a developer's box to testing +servers to production. While that usage is still valid, it is probably more common to use profiles to define overrides for how StructureMap +should resolve services in different modes of the application (connected vs offline) or different types of system users.


[Fact]
public void Add_default_instance_with_concrete_type()
{
    IContainer container = new Container(registry =>
    {
        registry.Profile("something", p =>
        {
            p.For<IWidget>().Use<AWidget>();
            p.For<Rule>().Use<DefaultRule>();
        });
    });

    var profile = container.GetProfile("something");

    profile.GetInstance<IWidget>().ShouldBeOfType<AWidget>();
    profile.GetInstance<Rule>().ShouldBeOfType<DefaultRule>();
}

Child Containers and Singletons

If you register a new Instance directly to a child container, that registration is really scoped as a +singleton within the usage of that particular child container:


[Fact]
public void singletons_to_child_container_are_isolated()
{
    var parentContainer = new Container(_ =>
    {
        _.For<IDependency>().Use<Dependency>();
    });

    var child1 = parentContainer.CreateChildContainer();
    child1.Configure(x =>
    {
        x.ForSingletonOf<IRoot>().Use<Root>();
    });

    var child2 = parentContainer.CreateChildContainer();
    child2.Configure(x =>
    {
        x.ForSingletonOf<IRoot>().Use<Root>();
    });

    // IRoot is a "singleton" within child1 usage
    child1.GetInstance<IRoot>().ShouldBeSameAs(child1.GetInstance<IRoot>());

    // IRoot is a "singleton" within child2 usage
    child2.GetInstance<IRoot>().ShouldBeSameAs(child2.GetInstance<IRoot>());

    // but, child1 and child2 both have a different IRoot
    child1.GetInstance<IRoot>()
        .ShouldNotBeTheSameAs(child2.GetInstance<IRoot>());
}

Creating a Nested Container from a Child Container

It is perfectly valid to create a nested container from a child container for short-lived requests or transactions:


[Fact]
public void nested_container_from_child()
{
    var parent = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();
        _.For<IService>().Use<AService>();
    });

    // Create a child container and override the
    // IService registration
    var child = parent.CreateChildContainer();
    child.Configure(_ =>
    {
        _.For<IService>().Use<ChildSpecialService>();
    });

    using (var nested = child.GetNestedContainer())
    {
        nested.GetInstance<IService>()
            .ShouldBeOfType<ChildSpecialService>();
    }
}

Example: Child Containers in Automated Testing

My shop has been somewhat successful in writing automated integration tests in a whitebox testing style +where we happily "swap out" a handful of external services with a stubbed service that we can happily control +to either setup system state or measure the interaction of our system with the stub (outgoing emails etc) -- with the canonical +example being a web service that our biggest application has to call for authentication purposes that is frequently unavailable during +our development efforts and not quite reliable even when it is available:.

That's great, and the stubs certainly help the testing efforts be more productive. Until the stateful stubs we inject in one test end up bleeding into +another test as de facto shared state and making those tests fail in ways that were very difficult to diagnose. To combat this problem of test isolation, +we've introduced the idea of using a clean child container per integration test so that the test harness tools can happily +swap in stubs without impacting other tests in the test suite.

In action, that usage looks something like this:


public class TheRealService : IService { }

public class StubbedService : IService { }

[Fact]
public void in_testing()
{
    var container = new Container(_ =>
    {
        _.For<IService>().Use<TheRealService>();
    });

    // Create a new child container for only this test
    var testContainer = container.CreateChildContainer();

    // Override a service with a stub that's easier to control
    var stub = new StubbedService();
    testContainer.Inject<IService>(stub);

    // Now, continue with the test resolving application
    // services through the new child container....
}

StructureMap - StructureMap Assumptions

- -

- - -

StructureMap 3.1.6

-
- - - -

Auto Wiring

The Container

- -

- - -

StructureMap Assumptions

- -

- - -

TODO(Write some content!)

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index 0aa762e..9ce8cd5 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -31,7 +31,7 @@

@@ -88,112 +88,36 @@

Working with Enumerable Types - - -

While you can certainly use any IEnumerable type as a plugin type with your own explicit configuration, -StructureMap has some built in support for these specific enumerable types:

IEnumerable<T>
IList<T>
List<T>
ICollection<T>
T[]

Specifically, if you request one of these types either directly with GetInstance<IList<IWidget>>() or as a declared -dependency in a constructor or setter (new WidgetUser(IList<IWidgets> widgets) for example) and you have no -specific registration for the enumerable types, StructureMap has a built in policy to return all the registered instances -of IWidget in the exact order that the registrations were made to StructureMap.

Note, if there are not any registrations for whatever T is, you'll get an empty enumeration.

Here's an acceptance test from the StructureMap codebase that demonstrates this:


-        [Fact]
-        public void collection_types_are_all_possible_by_default()
-        {
-            // NOTE that we do NOT make any explicit registration of
-            // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[]
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Add<AWidget>();
-                _.For<IWidget>().Add<BWidget>();
-                _.For<IWidget>().Add<CWidget>();
-            });
-
-            // IList<T>
-            container.GetInstance<IList<IWidget>>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-
-            // ICollection<T>
-            container.GetInstance<ICollection<IWidget>>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-
-            // Array of T
-            container.GetInstance<IWidget[]>()
-                .Select(x => x.GetType())
-                .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
-        }
-
-

And another showing how you can override this behavior with explicit configuration:


-        [Fact]
-        public void override_enumeration_behavior()
-        {
-            var container = new Container(_ =>
-            {
-                _.For<IWidget>().Add<AWidget>();
-                _.For<IWidget>().Add<BWidget>();
-                _.For<IWidget>().Add<CWidget>();
-
-                // Explicit registration should have precedence over the default
-                // behavior
-                _.For<IWidget[]>().Use(new IWidget[] { new DefaultWidget() });
-            });
-
-            container.GetInstance<IWidget[]>()
-                .Single().ShouldBeOfType<DefaultWidget>();
-        }
-
-

Sample Usage: Validation Rules

One of the ways that I have used the built in IEnumerable handling is for extensible validation rules. Say that we are -building a system to process IWidget objects. As part of processing a widget, we first need to validate that widget with a -series of rules that we might model with the IWidgetValidator interface shown below and used within the main -WidgetProcessor class:


-        public interface IWidgetValidator
-        {
-            IEnumerable<string> Validate(IWidget widget);
-        }
-
-        public class WidgetProcessor
-        {
-            private readonly IEnumerable<IWidgetValidator> _validators;
-
-            public WidgetProcessor(IEnumerable<IWidgetValidator> validators)
-            {
-                _validators = validators;
-            }
-
-            public void Process(IWidget widget)
-            {
-                var validationMessages = _validators.SelectMany(x => x.Validate(widget))
-                    .ToArray();
-
-                if (validationMessages.Any())
-                {
-                    // don't process the widget
-                }
-            }
-        }
-
-

We could simply configure all of the IWidgetValidator rules in one place with an explicit registration of IEnumerable<IWidgetValidator>, -but what if we need to have an extensibility to add more validation rules later? What if we want to add these additional rules in addon packages? Or we -just don't want to continuously break into the centralized Registry class every single time we add a new validation rule?

By relying on StructureMap's IEnumerable behavior, we're able to split our IWidgetValidatior registration across multiple Registry classes and that's not infrequently useful to do.

- + + +

While you can certainly use any IEnumerable type as a plugin type with your own explicit configuration, +StructureMap has some built in support for these specific enumerable types:

IEnumerable<T>
IList<T>
List<T>
ICollection<T>
T[]

Specifically, if you request one of these types either directly with GetInstance<IList<IWidget>>() or as a declared +dependency in a constructor or setter (new WidgetUser(IList<IWidgets> widgets) for example) and you have no +specific registration for the enumerable types, StructureMap has a built in policy to return all the registered instances +of IWidget in the exact order that the registrations were made to StructureMap.

Note, if there are not any registrations for whatever T is, you'll get an empty enumeration.

Here's an acceptance test from the StructureMap codebase that demonstrates this:


[Fact]
public void collection_types_are_all_possible_by_default()
{
    // NOTE that we do NOT make any explicit registration of
    // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[]
    var container = new Container(_ =>
    {
        _.For<IWidget>().Add<AWidget>();
        _.For<IWidget>().Add<BWidget>();
        _.For<IWidget>().Add<CWidget>();
    });

    // IList<T>
    container.GetInstance<IList<IWidget>>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // ICollection<T>
    container.GetInstance<ICollection<IWidget>>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // Array of T
    container.GetInstance<IWidget[]>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
}

And another showing how you can override this behavior with explicit configuration:


[Fact]
public void override_enumeration_behavior()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Add<AWidget>();
        _.For<IWidget>().Add<BWidget>();
        _.For<IWidget>().Add<CWidget>();

        // Explicit registration should have precedence over the default
        // behavior
        _.For<IWidget[]>().Use(new IWidget[] { new DefaultWidget() });
    });

    container.GetInstance<IWidget[]>()
        .Single().ShouldBeOfType<DefaultWidget>();
}

Sample Usage: Validation Rules

One of the ways that I have used the built in IEnumerable handling is for extensible validation rules. Say that we are +building a system to process IWidget objects. As part of processing a widget, we first need to validate that widget with a +series of rules that we might model with the IWidgetValidator interface shown below and used within the main +WidgetProcessor class:


public interface IWidgetValidator
{
    IEnumerable<string> Validate(IWidget widget);
}

public class WidgetProcessor
{
    private readonly IEnumerable<IWidgetValidator> _validators;

    public WidgetProcessor(IEnumerable<IWidgetValidator> validators)
    {
        _validators = validators;
    }

    public void Process(IWidget widget)
    {
        var validationMessages = _validators.SelectMany(x => x.Validate(widget))
            .ToArray();

        if (validationMessages.Any())
        {
            // don't process the widget
        }
    }
}

We could simply configure all of the IWidgetValidator rules in one place with an explicit registration of IEnumerable<IWidgetValidator>, +but what if we need to have an extensibility to add more validation rules later? What if we want to add these additional rules in addon packages? Or we +just don't want to continuously break into the centralized Registry class every single time we add a new validation rule?

By relying on StructureMap's IEnumerable behavior, we're able to split our IWidgetValidatior registration across multiple Registry classes and that's not infrequently useful to do.

diff --git a/the-container/working-with-generic-types/index.html b/the-container/working-with-generic-types/index.html deleted file mode 100644 index 2473013..0000000 --- a/the-container/working-with-generic-types/index.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - - StructureMap - Working with Generic Types - - - - - - - - - - - - - - - - - - - -

- -

- - -

StructureMap 3.1.6

-
- - - -

Working with Enumerable Types

Nested Containers (Per Request/Transaction)

- -

- - -

Working with Generic Types

- -

- - -

TODO(Write some content!)

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index 46b5320..e85d24b 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -31,7 +31,7 @@

@@ -88,241 +88,46 @@

Working with the IContext at Build Time - - -

The IContext usage shown in this topic is certainly not going away in future versions of StructureMap, but if at all possible, the StructureMap team -strongly recommends using Construction Policies to accomplish customized object building instead of relying -on conditional logic using IContext at runtime.

The IContext interface is what StructureMap uses to expose the current state of the internal "build session" for -the current object creation operation for usage in user-supplied lambda builders or -interceptors. IContext allows you to:

Retrieve other services from the current Container to use in a Lambda
"BuildUp" objects with setter dependencies
Retrieve all the objects created inside the current build session that could be cast to a certain interface or base class
If an object is being built as a dependency to another object, see the parent type
See the root type of the top level object that StructureMap is building in this request

The entire IContext interface is shown below:


-    /// <summary>
-    /// Access to the state and type resolution of the current "build session"
-    /// during a request to a StructureMap container
-    /// </summary>
-    public interface IContext
-    {
-        /// <summary>
-        /// The requested instance name of the object graph
-        /// </summary>
-        string RequestedName { get; }
-
-        /// <summary>
-        /// The "BuildUp" method takes in an already constructed object
-        /// and uses Setter Injection to push in configured dependencies
-        /// of that object
-        /// </summary>
-        /// <param name="target"></param>
-        void BuildUp(object target);
-
-        /// <summary>
-        /// Get the object of type T that is valid for this build session.
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <returns></returns>
-        T GetInstance<T>();
-
-        /// <summary>
-        /// Get the object of type T that is valid for this build session by name.
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <returns></returns>
-        T GetInstance<T>(string name);
-
-        /// <summary>
-        /// Get a service from the current build session by type
-        /// </summary>
-        /// <param name="pluginType"></param>
-        /// <returns></returns>
-        object GetInstance(Type pluginType);
-
-        /// <summary>
-        /// Creates or finds the named instance of the pluginType
-        /// </summary>
-        /// <param name="pluginType"></param>
-        /// <param name="instanceKey"></param>
-        /// <returns></returns>
-        object GetInstance(Type pluginType, string instanceKey);
-
-        /// <summary>
-        /// Same as GetInstance, but can gracefully return null if 
-        /// the Type does not already exist
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <returns></returns>
-        T TryGetInstance<T>() where T : class;
-
-        /// <summary>
-        /// Same as GetInstance(name), but can gracefully return null if 
-        /// the Type and name does not already exist
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <param name="name"></param>
-        /// <returns></returns>
-        T TryGetInstance<T>(string name) where T : class;
-
-        /// <summary>
-        /// Creates or finds the default instance of the pluginType. Returns null if the pluginType is not known to the container.
-        /// </summary>
-        /// <param name="pluginType"></param>
-        /// <returns></returns>
-        object TryGetInstance(Type pluginType);
-
-        /// <summary>
-        /// Creates or finds the named instance of the pluginType. Returns null if the named instance is not known to the container.
-        /// </summary>
-        /// <param name="pluginType"></param>
-        /// <param name="instanceKey"></param>
-        /// <returns></returns>
-        object TryGetInstance(Type pluginType, string instanceKey);
-
-        /// <summary>
-        /// Gets all objects in the current object graph that can be cast
-        /// to T that have already been created
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <returns></returns>
-        IEnumerable<T> All<T>() where T : class;
-
-
-        /// <summary>
-        /// Creates/Resolves every configured instance of PlutinType T
-        /// </summary>
-        /// <typeparam name="T"></typeparam>
-        /// <returns></returns>
-        IEnumerable<T> GetAllInstances<T>();
-
-        /// <summary>
-        /// Creates or resolves all registered instances of the pluginType
-        /// </summary>
-        /// <param name="pluginType"></param>
-        /// <returns></returns>
-        IEnumerable<object> GetAllInstances(Type pluginType);
-
-        /// <summary>
-        /// The type of the parent object.  Useful for constructing
-        /// contextual logging dependencies
-        /// </summary>
-        Type ParentType { get; }
-
-        /// <summary>
-        /// The type of the requested object at the very top of the 
-        /// object graph
-        /// </summary>
-        Type RootType { get; }
-    }
-

Example 1: Contextual Logging

All of the sample code in this example is in Github.

One of the canonical examples of using IContext is the integration of logging frameworks like NLog or Log4net -that allow you to create logging policies by concrete type. With these tools, you generally have a static class (boo!) -where you ask for the proper logging service for a type of object like this one:


-    public static class LoggerFactory
-    {
-        public static Logger LoggerFor(Type type)
-        {
-            return new Logger(type);
-        }
-    }
-
-

Now, say you would want to have the proper Logger injected into every object that StructureMap creates that depends on Logger matching -the concrete type of the object being created. That registration is shown below in a unit test from StructureMap's codebase:


-        [Fact]
-        public void can_happily_use_the_parent_type()
-        {
-            var container = new Container(x =>
-            {
-                // AlwaysUnique() is important so that every object created will get
-                // their own Logger instead of sharing whichever one is created first
-                x.For<Logger>().Use(c => LoggerFactory.LoggerFor(c.ParentType)).AlwaysUnique();
-            });
-
-            var top = container.GetInstance<LoggedClass1>();
-            top.Logger.ParentType.ShouldBe(typeof(LoggedClass1));
-            top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2));
-            top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3));
-        }
-
-

Just for fun, here's the equivalent with the new construction policies from 4.0:


-        public class LoggerConvention : ConfiguredInstancePolicy
-        {
-            protected override void apply(Type pluginType, IConfiguredInstance instance)
-            {
-                instance.Constructor
-                    .GetParameters()
-                    .Where(param => param.ParameterType == typeof(Logger))
-                    .Each(param => instance.Dependencies.Add(LoggerFactory.LoggerFor(instance.PluggedType)));
-            }
-        }
-
-        [Fact]
-        public void use_logger_convention()
-        {
-            var container = new Container(_ =>
-            {
-                _.Policies.Add<LoggerConvention>();
-            });
-
-            var top = container.GetInstance<LoggedClass1>();
-            top.Logger.ParentType.ShouldBe(typeof(LoggedClass1));
-            top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2));
-            top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3));
-        }
-
-

The LoggerConvention way of accomplishing the logging integration is technically more code and possibly harder to understand, -but it's significantly more efficient at runtime because the decision about which Logger to use is only done once upfront. -The conventional approach should also be more evident in StructureMap diagnostics.

Example 2: NHibernate Integration

It's been several years since I used NHibernate, so I might not have the technical details exactly right here:)

If you're developing a system with NHibernate managed by StructureMap, you will frequently need to inject -NHibernate's ISession service into your concrete classes. There's a little catch though, to create an ISession object -you have to use NHibernate's ISessionFactory service:


-    public interface ISession { }
-
-    public interface ISessionFactory
-    {
-        ISession Build();
-    }
-

Sidestepping the issue of how to build an ISessionFactory, here's a possible way to enable a StructureMap -Container to build and resolve dependencies of ISession with a lambda builder:


-    public class SessionFactoryRegistry : Registry
-    {
-        // Let's not worry about how ISessionFactory is built
-        // in this example
-        public SessionFactoryRegistry(ISessionFactory factory)
-        {
-            For<ISessionFactory>().Use(factory);
-
-            // Build ISession with a lambda:
-            For<ISession>().Use("Build ISession from ISessionFactory", c =>
-            {
-                // To resolve ISession, I first pull out
-                // ISessionFactory from the IContext and use that
-                // to build a new ISession. 
-                return c.GetInstance<ISessionFactory>().Build();
-            });
-        }
-    }
-

- + + +

The IContext usage shown in this topic is certainly not going away in future versions of StructureMap, but if at all possible, the StructureMap team +strongly recommends using Construction Policies to accomplish customized object building instead of relying +on conditional logic using IContext at runtime.

The IContext interface is what StructureMap uses to expose the current state of the internal "build session" for +the current object creation operation for usage in user-supplied lambda builders or +interceptors. IContext allows you to:

Retrieve other services from the current Container to use in a Lambda
"BuildUp" objects with setter dependencies
Retrieve all the objects created inside the current build session that could be cast to a certain interface or base class
If an object is being built as a dependency to another object, see the parent type
See the root type of the top level object that StructureMap is building in this request

The entire IContext interface is shown below:


/// <summary>
/// Access to the state and type resolution of the current "build session"
/// during a request to a StructureMap container
/// </summary>
public interface IContext
{
    /// <summary>
    /// The requested instance name of the object graph
    /// </summary>
    string RequestedName { get; }

    /// <summary>
    /// The "BuildUp" method takes in an already constructed object
    /// and uses Setter Injection to push in configured dependencies
    /// of that object
    /// </summary>
    /// <param name="target"></param>
    void BuildUp(object target);

    /// <summary>
    /// Get the object of type T that is valid for this build session.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    T GetInstance<T>();

    /// <summary>
    /// Get the object of type T that is valid for this build session by name.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    T GetInstance<T>(string name);

    /// <summary>
    /// Get a service from the current build session by type
    /// </summary>
    /// <param name="pluginType"></param>
    /// <returns></returns>
    object GetInstance(Type pluginType);

    /// <summary>
    /// Creates or finds the named instance of the pluginType
    /// </summary>
    /// <param name="pluginType"></param>
    /// <param name="instanceKey"></param>
    /// <returns></returns>
    object GetInstance(Type pluginType, string instanceKey);

    /// <summary>
    /// Same as GetInstance, but can gracefully return null if 
    /// the Type does not already exist
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    T TryGetInstance<T>() where T : class;

    /// <summary>
    /// Same as GetInstance(name), but can gracefully return null if 
    /// the Type and name does not already exist
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="name"></param>
    /// <returns></returns>
    T TryGetInstance<T>(string name) where T : class;

    /// <summary>
    /// Creates or finds the default instance of the pluginType. Returns null if the pluginType is not known to the container.
    /// </summary>
    /// <param name="pluginType"></param>
    /// <returns></returns>
    object TryGetInstance(Type pluginType);

    /// <summary>
    /// Creates or finds the named instance of the pluginType. Returns null if the named instance is not known to the container.
    /// </summary>
    /// <param name="pluginType"></param>
    /// <param name="instanceKey"></param>
    /// <returns></returns>
    object TryGetInstance(Type pluginType, string instanceKey);

    /// <summary>
    /// Gets all objects in the current object graph that can be cast
    /// to T that have already been created
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    IEnumerable<T> All<T>() where T : class;


    /// <summary>
    /// Creates/Resolves every configured instance of PlutinType T
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    IEnumerable<T> GetAllInstances<T>();

    /// <summary>
    /// Creates or resolves all registered instances of the pluginType
    /// </summary>
    /// <param name="pluginType"></param>
    /// <returns></returns>
    IEnumerable<object> GetAllInstances(Type pluginType);

    /// <summary>
    /// The type of the parent object.  Useful for constructing
    /// contextual logging dependencies
    /// </summary>
    Type ParentType { get; }

    /// <summary>
    /// The type of the requested object at the very top of the 
    /// object graph
    /// </summary>
    Type RootType { get; }
}

Example 1: Contextual Logging

All of the sample code in this example is in Github.

One of the canonical examples of using IContext is the integration of logging frameworks like NLog or Log4net +that allow you to create logging policies by concrete type. With these tools, you generally have a static class (boo!) +where you ask for the proper logging service for a type of object like this one:


public static class LoggerFactory
{
    public static Logger LoggerFor(Type type)
    {
        return new Logger(type);
    }
}

Now, say you would want to have the proper Logger injected into every object that StructureMap creates that depends on Logger matching +the concrete type of the object being created. That registration is shown below in a unit test from StructureMap's codebase:


[Fact]
public void can_happily_use_the_parent_type()
{
    var container = new Container(x =>
    {
        // AlwaysUnique() is important so that every object created will get
        // their own Logger instead of sharing whichever one is created first
        x.For<Logger>().Use(c => LoggerFactory.LoggerFor(c.ParentType)).AlwaysUnique();
    });

    var top = container.GetInstance<LoggedClass1>();
    top.Logger.ParentType.ShouldBe(typeof(LoggedClass1));
    top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2));
    top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3));
}

Just for fun, here's the equivalent with the new construction policies from 4.0:


public class LoggerConvention : ConfiguredInstancePolicy
{
    protected override void apply(Type pluginType, IConfiguredInstance instance)
    {
        instance.Constructor
            .GetParameters()
            .Where(param => param.ParameterType == typeof(Logger))
            .Each(param => instance.Dependencies.Add(LoggerFactory.LoggerFor(instance.PluggedType)));
    }
}

[Fact]
public void use_logger_convention()
{
    var container = new Container(_ =>
    {
        _.Policies.Add<LoggerConvention>();
    });

    var top = container.GetInstance<LoggedClass1>();
    top.Logger.ParentType.ShouldBe(typeof(LoggedClass1));
    top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2));
    top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3));
}

The LoggerConvention way of accomplishing the logging integration is technically more code and possibly harder to understand, +but it's significantly more efficient at runtime because the decision about which Logger to use is only done once upfront. +The conventional approach should also be more evident in StructureMap diagnostics.

Example 2: NHibernate Integration

It's been several years since I used NHibernate, so I might not have the technical details exactly right here:)

If you're developing a system with NHibernate managed by StructureMap, you will frequently need to inject +NHibernate's ISession service into your concrete classes. There's a little catch though, to create an ISession object +you have to use NHibernate's ISessionFactory service:


public interface ISession { }

public interface ISessionFactory
{
    ISession Build();
}

Sidestepping the issue of how to build an ISessionFactory, here's a possible way to enable a StructureMap +Container to build and resolve dependencies of ISession with a lambda builder:


public class SessionFactoryRegistry : Registry
{
    // Let's not worry about how ISessionFactory is built
    // in this example
    public SessionFactoryRegistry(ISessionFactory factory)
    {
        For<ISessionFactory>().Use(factory);

        // Build ISession with a lambda:
        For<ISession>().Use("Build ISession from ISessionFactory", c =>
        {
            // To resolve ISession, I first pull out
            // ISessionFactory from the IContext and use that
            // to build a new ISession. 
            return c.GetInstance<ISessionFactory>().Build();
        });
    }
}

Date: Mon, 20 Feb 2017 14:53:00 -0600 Subject: [PATCH 43/55] Documentation Update for 4.4.3 --- autofactory/index.html | 41 ++++++++++++++++--- best-practices/index.html | 10 ++--- diagnostics/build-plans/index.html | 4 +- diagnostics/environment-tests/index.html | 4 +- diagnostics/index.html | 4 +- diagnostics/type-scanning/index.html | 4 +- .../using-the-container-model/index.html | 4 +- .../index.html | 4 +- diagnostics/whatdoihave/index.html | 4 +- documentation/index.html | 6 +-- dynamic-interception/index.html | 10 ++--- features/index.html | 4 +- generics/index.html | 4 +- get-structuremap/index.html | 4 +- glossary/index.html | 6 +-- history/index.html | 4 +- instances/index.html | 4 +- integrations/index.html | 6 +-- interception-and-decorators/index.html | 4 +- interpreting-exceptions/index.html | 4 +- .../configuring-lifecycles/index.html | 4 +- object-lifecycle/custom-lifecycles/index.html | 4 +- object-lifecycle/index.html | 4 +- .../supported-lifecycles/index.html | 4 +- quickstart/index.html | 6 +-- registration/attributes/index.html | 4 +- .../index.html | 4 +- .../index.html | 4 +- registration/clear-or-replace/index.html | 4 +- registration/configured-instance/index.html | 4 +- registration/constructor-selection/index.html | 4 +- registration/existing-objects/index.html | 4 +- registration/fallback-services/index.html | 4 +- registration/index.html | 4 +- registration/inline-dependencies/index.html | 4 +- .../on-missing-family-policies/index.html | 4 +- registration/policies/index.html | 4 +- registration/registry-dsl/index.html | 4 +- release-notes/index.html | 4 +- .../index.html | 4 +- .../get-a-service-by-plugintype/index.html | 4 +- .../index.html | 4 +- resolving/index.html | 4 +- .../passing-arguments-at-runtime/index.html | 4 +- .../requesting-a-concrete-type/index.html | 4 +- .../index.html | 4 +- .../index.html | 4 +- roadmap/index.html | 4 +- setter-injection/index.html | 4 +- software-design-concepts/index.html | 6 +-- the-container/auto-wiring/index.html | 4 +- the-container/disposing/index.html | 4 +- .../index.html | 12 +++--- .../index.html | 4 +- the-container/index.html | 6 +-- the-container/lambdas/index.html | 4 +- the-container/lazy-resolution/index.html | 4 +- the-container/nested-containers/index.html | 4 +- the-container/primitives/index.html | 4 +- .../profiles-and-child-containers/index.html | 10 ++--- .../working-with-enumerable-types/index.html | 4 +- .../index.html | 10 ++--- 62 files changed, 179 insertions(+), 150 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index e584eef..9bc05cb 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -5,7 +5,7 @@ - StructureMap - StructureMap.AutoFactory + StructureMap - Auto-factories @@ -31,7 +31,7 @@

@@ -83,12 +83,41 @@

StructureMap.AutoFactory Edit on GitHub

Auto-factories Edit on GitHub

- + +

You need to install StructureMap.Autofactory package to use the functionality described below.

When you need to implement Abstract Factory, StructureMap offers a way to do it for you. Let's say you have


public interface IDummyService
{
    string Name { get; }
}

+with implementation +


public class DummyService : IDummyService
{
    public string Name { get; set; }
}

Now you declare an interface for your factory:

Missing code sample 'ISimpleDummyFactory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

All you need to do is to call CreateFactory when configuring the container as shown below:

Missing code sample 'simple-factory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

Default convention

As for now, Auto-factories support two types of methods:

Methods to list all names of registered implementations.
Methods to create object instances i.e. factory methods.

To declare a method that has to return the names of registered implementations, the method signature must satisfy the following conditions:

The name has to start with GetNames
It must be a generic method.
The method return type must be assignable from List<string> e.g. IList<string>, IEnumerable<string>

Any other method that has the return type (i.e. doesn't return void), is treated as a factory method. In addition, if the method name starts with GetNamed, the first method argument is used as the name for the named instance. All the rest arguments are passed as explicit arguments to the implementation constructor.

It is much easier to see it on an example:


public interface IDummyFactory
{
    // This method will return the names of all registered implementations of TService.
    IList<string> GetNames<TService>();

    // This method will just create the default IDummyService implementation.
    IDummyService CreateDummyService();

    // This method will just create the default IDummyService implementation and pass namePart1 and namePart2 as
    // dependencies.
    IDummyService CreateDummyService(string namePart1, string namePart2);

    // This method will create IDummyService implementation with serviceName name.
    IDummyService GetNamedDummyService(string serviceName, string namePart1, string namePart2);

    // Generic methods are also allowed as factory methods.
    TService CreateService<TService>();

    // Something that is common for event-sourcing implementations.
    IHandler<TMessage> CreateHandler<TMessage>();
}

Custom convention

If the default convention doesn't work for you, you can create and use your custom convention. All you need is to implement IAutoFactoryConventionProvider and use the corresponding CreateFactory overload. IAutoFactoryConventionProvider has a single method to implement:

Missing code sample 'IAutoFactoryConventionProvider-GetMethodDefinition' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

IAutoFactoryMethodDefinition is defined as follows:


/// <summary>
/// Describes how AutoFactory should treat the specific method declared in an abstract factory interface.
/// </summary>
public interface IAutoFactoryMethodDefinition
{
    /// <summary>
    /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values.
    /// </summary>
    AutoFactoryMethodType MethodType { get; }

    /// <summary>
    /// The instance type to create.
    /// </summary>
    Type InstanceType { get; }

    /// <summary>
    /// The instance name if available.
    /// </summary>
    string InstanceName { get; }

    /// <summary>
    /// Explicit arguments if available.
    /// </summary>
    ExplicitArguments ExplicitArguments { get; }
}

diff --git a/best-practices/index.html b/best-practices/index.html index b68501a..edd6135 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -31,7 +31,7 @@

@@ -74,9 +74,9 @@

@@ -133,7 +133,7 @@

Favor Build Pol

- Previous: StructureMap.AutoFactory + Previous: Auto-factories diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index f127753..f0eca72 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html index 094ef42..95ee2d1 100644 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/index.html b/diagnostics/index.html index 4ebd4cd..e9aed9e 100644 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html index 5842de6..0b5e426 100644 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index 0a731e3..6bdea95 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index 4e503dc..482ad07 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html index 0844f6d..e3a31b8 100644 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -31,7 +31,7 @@

diff --git a/documentation/index.html b/documentation/index.html index 4a87e05..78b64d3 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -31,7 +31,7 @@

@@ -89,7 +89,7 @@

Documentation
The documentation may never be exhaustive, but here are the major sections so far:
-
Documentation
Roadmap
A Gentle Quickstart
Glossary
Get StructureMap
Features
Software Design Concepts
Setter Injection
Registration
Registry DSL
Inline Dependencies
Auto-Registration and Conventions
Working with IConfiguredInstance
Construction Policies
Changing Configuration at Runtime
On Missing Family Policies
Constructor Selection
Fallback Services
Registering Existing Objects
Replace or Clear Out Previous Registrations
Using Attributes for Configuration
Resolving Services
Get a Service by PluginType
Get a Service by Plugin Type and Name
Get all Services by Plugin Type
Try Getting an Optional Service by Plugin Type
Try Geting an Optional Service by Plugin Type and Name
Passing Arguments at Runtime
Auto Resolving Concrete Types
The Container
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Registering a Single Instance Against Multiple PluginType's
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Lazy Resolution
StructureMap and IDisposable
Working with Primitive Types
Object Lifecycles
Supported Lifecycles
Configuring Lifecycles
Custom Lifecycles
Generic Types
Interception and Decorators
Interpreting Exceptions
Diagnostics
WhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
Aspect Oriented Programming with StructureMap.DynamicInterception
StructureMap.AutoFactory
Best Practices
History
Release Notes
Custom Instance Types
Integrating StructureMap into Common .Net Frameworks
+
Documentation
Roadmap
A Gentle Quickstart
Glossary
Get StructureMap
Features
Software Design Concepts
Setter Injection
Registration
Registry DSL
Inline Dependencies
Auto-Registration and Conventions
Working with IConfiguredInstance
Construction Policies
Changing Configuration at Runtime
On Missing Family Policies
Constructor Selection
Fallback Services
Registering Existing Objects
Replace or Clear Out Previous Registrations
Using Attributes for Configuration
Resolving Services
Get a Service by PluginType
Get a Service by Plugin Type and Name
Get all Services by Plugin Type
Try Getting an Optional Service by Plugin Type
Try Geting an Optional Service by Plugin Type and Name
Passing Arguments at Runtime
Auto Resolving Concrete Types
The Container
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Registering a Single Instance Against Multiple PluginTypes
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Lazy Resolution
StructureMap and IDisposable
Working with Primitive Types
Object Lifecycles
Supported Lifecycles
Configuring Lifecycles
Custom Lifecycles
Generic Types
Interception and Decorators
Interpreting Exceptions
Diagnostics
WhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
Aspect Oriented Programming with StructureMap.DynamicInterception
Auto-factories
Best Practices
History
Release Notes
Custom Instance Types
Integrating StructureMap into Common .Net Frameworks

diff --git a/features/index.html b/features/index.html index 179a9c0..7d7aa3e 100644 --- a/features/index.html +++ b/features/index.html @@ -31,7 +31,7 @@

diff --git a/generics/index.html b/generics/index.html index c81bdff..71955f8 100644 --- a/generics/index.html +++ b/generics/index.html @@ -31,7 +31,7 @@

diff --git a/get-structuremap/index.html b/get-structuremap/index.html index 65d3113..03748dc 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -31,7 +31,7 @@

diff --git a/glossary/index.html b/glossary/index.html index f4486f9..b699daf 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -31,7 +31,7 @@

@@ -93,7 +93,7 @@

Glossary Container

Obviously there is more to a container then resolving services and managing their scope, but in the core that's just what it is. Before you can do so you need to tell StructureMap, the container, how it must compose those objects graphs and what their lifecycle is. This is called registration and can be done in various mixed ways. The strongly recommend way would be using the Registry DSL. In your registration you're basically mapping abstractions to concrete types and defining their lifecycle.

Obviously there is more to a container than resolving services and managing their scope, but in the core that's just what it is. Before you can do so you need to tell StructureMap, the container, how it must compose those objects graphs and what their lifecycle is. This is called registration and can be done in various mixed ways. The strongly recommend way would be using the Registry DSL. In your registration you're basically mapping abstractions to concrete types and defining their lifecycle.

A simple example of a container using the Registry DSL:


public class FooBarRegistry : Registry
{
    public FooBarRegistry()
    {
        For<IFoo>().Use<Foo>();
        For<IBar>().Use<Bar>();
    }
}


var container = new Container(c => { c.AddRegistry<FooBarRegistry>(); });

diff --git a/history/index.html b/history/index.html index aa94c2d..d73e872 100644 --- a/history/index.html +++ b/history/index.html @@ -31,7 +31,7 @@

diff --git a/instances/index.html b/instances/index.html index e2a3558..2d463eb 100644 --- a/instances/index.html +++ b/instances/index.html @@ -31,7 +31,7 @@

diff --git a/integrations/index.html b/integrations/index.html index 9709ea7..410678f 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -31,7 +31,7 @@

@@ -99,7 +99,7 @@

ASP.NET Web API

The IoC integration in Web API is somewhat better designed than ASP.NET MVC's bolt on mechanism and the StructureMap integration is quite a bit cleaner.

ASP.NET Core

See the StructureMap.Microsoft.DependencyInjection project and NuGet package for integration with ASP.NET Core.

NServiceBus

Use the NServiceBus StructureMap NuGet package for integrating StructureMap 3 into NServiceBus.

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index ed1056e..c1588bc 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -31,7 +31,7 @@

diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index 21ece0b..226e508 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index 1417769..37c43e5 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index ead2f94..66f591b 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index 945facd..66e631a 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 6024bca..c9dc907 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -31,7 +31,7 @@

diff --git a/quickstart/index.html b/quickstart/index.html index 80efd62..bf2d6a2 100644 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -31,7 +31,7 @@

@@ -115,7 +115,7 @@

Main Usage


var container = new Container(_ =>
{
    _.Scan(x =>
    {
        x.TheCallingAssembly();
        x.WithDefaultConventions();
    });
});

container.GetInstance<IFoo>()
    .ShouldBeOfType<Foo>()
    .Bar.ShouldBeOfType<Bar>();

Integrating StructureMap within your application

What to do when things go wrong?

diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index 33feb37..cbdbcf3 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -31,7 +31,7 @@

diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index 4f1b561..39b1c8b 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -31,7 +31,7 @@

diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index 404f006..c0dc3d7 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index cf712a2..a981950 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -31,7 +31,7 @@

diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index 8bec134..28476bd 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -31,7 +31,7 @@

diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html index 90ad551..de23a13 100644 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -31,7 +31,7 @@

diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index 891ba5b..639e20b 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -31,7 +31,7 @@

diff --git a/registration/index.html b/registration/index.html index 28fec02..f0813c0 100644 --- a/registration/index.html +++ b/registration/index.html @@ -31,7 +31,7 @@

diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index 528b573..40e325b 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index 7e5c526..abd3129 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/policies/index.html b/registration/policies/index.html index cb5af8b..cdfea68 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 0f1ab4b..990c047 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -31,7 +31,7 @@

diff --git a/release-notes/index.html b/release-notes/index.html index 9c6c764..e667933 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html index 63d9c93..0255667 100644 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html index 7b29e58..f165e88 100644 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html index f324136..c5c3796 100644 --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/index.html b/resolving/index.html index 5e49a65..cd42b8d 100644 --- a/resolving/index.html +++ b/resolving/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html index 26e1e0d..bd75663 100644 --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index 468e659..a62324b 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html index 561e083..4ef0c59 100644 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html index 7688fb2..d9f5b55 100644 --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -31,7 +31,7 @@

diff --git a/roadmap/index.html b/roadmap/index.html index 65448d2..85f47dd 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -31,7 +31,7 @@

diff --git a/setter-injection/index.html b/setter-injection/index.html index 57022ef..aad8366 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -31,7 +31,7 @@

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index efd4db3..2c6c88b 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -31,7 +31,7 @@

@@ -91,7 +91,7 @@

Software Design Concepts Inversion of Control

Years ago I consulted for a company that had developed a successful software engine for pricing and analyzing potential energy trades. The next step for them was to adapt their pricing engine so that it could be embedded in other software packages or even a simple spreadsheet so that analysts could quickly try out "what if" scenarios before making any kind of deal. The immediate problem this firm had was that their pricing engine was architected such that the pricing engine business logic directly invoked their proprietary database schema and configuration files. The strategic pricing engine logic was effectively useless without all the rest of their system, so forget embedding the logic into spreadsheet logic.

An IoC container like StructureMap uses the Inversion of Control concept to simplify your internal services by freeing them from having to know how to find, build, or clean up their dependencies.

Dependency Injection

diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index 9636c62..bf4d146 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index bcbf79d..9a3fdc2 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index 0dc8de0..2fee73e 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -5,7 +5,7 @@ - StructureMap - Registering a Single Instance Against Multiple PluginType's + StructureMap - Registering a Single Instance Against Multiple PluginTypes @@ -31,7 +31,7 @@

@@ -83,12 +83,12 @@

Registering a Single Instance Against Multiple PluginType's Edit on GitHub

Registering a Single Instance Against Multiple PluginTypes Edit on GitHub

- +

It's not uncommon to want a single instance registration in StructureMap to be mapped to multiple plugin type interfaces, especially if you have a class that implements multiple role interfaces diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index 9f4fd0b..461dc84 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/index.html b/the-container/index.html index 9b6d390..8360f2a 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 6aa70b1..41c8a92 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html index a14ebc1..5c53fa4 100644 --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 38bc84d..8278337 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index 64a06a9..f844bdd 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index 151e81a..e7be927 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -31,7 +31,7 @@

@@ -74,9 +74,9 @@

@@ -140,7 +140,7 @@

Example: Child Containers

- Previous: Registering a Single Instance Against Multiple PluginType's + Previous: Registering a Single Instance Against Multiple PluginTypes diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index 9ce8cd5..deb50e8 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index e85d24b..2d75002 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -31,7 +31,7 @@

From ecb0d4c539c86c1378c64ad8b5c497cb6b81a5de Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Thu, 2 Mar 2017 10:55:38 -0600 Subject: [PATCH 44/55] Documentation Update for 4.4.3 --- dynamic-interception/index.html | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html index 482786c..dda9850 100644 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -89,6 +89,25 @@

Aspect Oriented Programming with StructureMap.DynamicInterception +
You need to install StructureMap.DynamicInterception package to use the functionality described below.
+
The Interception and Decorators page describes how to use "static" interception of created instances, mainly allowing to apply the Decorator pattern. It is "static" in a sense that you need know what interfaces you want to implement and you need to create decorators implementing all appropriate interfaces. It is almost always fine, but there are cases when you want to implement the same decorating logic for many interfaces which easily breaks the DRY principle. The most common examples are cross-cutting concerns such as logging, caching etc.
+

Dynamic proxy interceptor

Let's see it in action. Let's say we have


public interface IMathService
{
    int GetSquareRoot(int value);

    Task<int> GetSquareRootAsync(int value);
}

+with implementation +


private class MathService : IMathService
{
    public int GetSquareRoot(int value)
    {
        return (int)Math.Sqrt(value);
    }

    public async Task<int> GetSquareRootAsync(int value)
    {
        await Task.Yield();
        return (int)Math.Sqrt(value);
    }
}

If you need to apply dynamic interception to IMathService, first you implement either ISyncInterceptionBehavior or IAsyncInterceptionBehavior depending if your interception code needs to use async/await or not. For demonstration purposes, let's have


private class NegatingInterceptor : ISyncInterceptionBehavior
{
    public IMethodInvocationResult Intercept(ISyncMethodInvocation methodInvocation)
    {
        var argument = methodInvocation.GetArgument("value");
        var argumentValue = (int)argument.Value;
        if (argumentValue < 0)
        {
            argument.Value = -argumentValue;
        }
        return methodInvocation.InvokeNext();
    }
}

+and +


private class AsyncCachingInterceptor : IAsyncInterceptionBehavior
{
    private static readonly IDictionary<int, int> PrecalculatedValues = new Dictionary<int, int>
    {
        { 16, 4444 },
        { 10, 5555 },
    };

    public async Task<IMethodInvocationResult> InterceptAsync(IAsyncMethodInvocation methodInvocation)
    {
        var argument = methodInvocation.GetArgument("value");
        var argumentValue = (int)argument.Value;

        int result;
        return PrecalculatedValues.TryGetValue(argumentValue, out result)
            ? methodInvocation.CreateResult(result)
            : await methodInvocation.InvokeNextAsync().ConfigureAwait(false);
    }
}

Finally, we register interceptors with help of DynamicProxyInterceptor as follows:


[Theory]
[InlineData(111, 10)]
[InlineData(16, 4444)]
[InlineData(-16, 4444)]
public void CallSyncMethodWithSyncThenAsyncInterceptors(int value, int expectedResult)
{
    var container = new Container(x =>
    {
        x.For<IMathService>().Use<MathService>()
            .InterceptWith(new DynamicProxyInterceptor<IMathService>(new IInterceptionBehavior[]
            {
                new NegatingInterceptor(),
                new AsyncCachingInterceptor()
            }));
    });

    var service = container.GetInstance<IMathService>();

    service.GetSquareRoot(value).ShouldBe(expectedResult);
}

The idea is simple - for each method call of the intercepted instance, Intercept/InterceptAsync is called passing an IMethodInvocation instance allowing to get information about the intercepted method and modify arguments if needed before passing to the next interceptor. You have a choice to call the next interceptor in the chain via methodInvocation.InvokeNext/methodInvocation.InvokeNextAsync. Alternatively, you can return the result directly from the interceptor via methodInvocation.CreateResult.

Finally, you can also throw exceptions from interceptors either directly or by returning methodInvocation.CreateExceptionResult.

Dynamic proxy policy

As described on the Interception and Decorators page, you can create an interception policy if you need to apply interceptors to many types by certain filter. DynamicProxyInterceptorPolicy makes it easier when it comes to dynamic interceptors. See the example below:


[Fact]
public void UseInterceptionPolicy()
{
    var container = new Container(x =>
    {
        x.Policies.Interceptors(new DynamicProxyInterceptorPolicy(new NegatingInterceptor(), new CachingInterceptor()));

        x.For<IMathService>().Use<MathService>();
    });

    var service = container.GetInstance<IMathService>();

    service.GetSquareRoot(-10).ShouldBe(5555);
}

Check DynamicProxyInterceptorPolicy constructors to find the most suitable overload for your purposes.

From c616a3df2deb56a65329974988d7ce1991a2e92b Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Thu, 2 Mar 2017 11:20:41 -0600 Subject: [PATCH 45/55] Documentation Update for 4.4.3 --- autofactory/index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/autofactory/index.html b/autofactory/index.html index 9bc05cb..b76307f 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -115,7 +115,8 @@

Default convention


public interface IDummyFactory
{
    // This method will return the names of all registered implementations of TService.
    IList<string> GetNames<TService>();

    // This method will just create the default IDummyService implementation.
    IDummyService CreateDummyService();

    // This method will just create the default IDummyService implementation and pass namePart1 and namePart2 as
    // dependencies.
    IDummyService CreateDummyService(string namePart1, string namePart2);

    // This method will create IDummyService implementation with serviceName name.
    IDummyService GetNamedDummyService(string serviceName, string namePart1, string namePart2);

    // Generic methods are also allowed as factory methods.
    TService CreateService<TService>();

    // Something that is common for event-sourcing implementations.
    IHandler<TMessage> CreateHandler<TMessage>();
}

Custom convention

Missing code sample 'IAutoFactoryConventionProvider-GetMethodDefinition' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);
+

IAutoFactoryMethodDefinition is defined as follows:


/// <summary>
/// Describes how AutoFactory should treat the specific method declared in an abstract factory interface.
/// </summary>
public interface IAutoFactoryMethodDefinition
{
    /// <summary>
    /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values.
    /// </summary>
    AutoFactoryMethodType MethodType { get; }

    /// <summary>
    /// The instance type to create.
    /// </summary>
    Type InstanceType { get; }

    /// <summary>
    /// The instance name if available.
    /// </summary>
    string InstanceName { get; }

    /// <summary>
    /// Explicit arguments if available.
    /// </summary>
    ExplicitArguments ExplicitArguments { get; }
}

From ed1c9ae1fd8609c5f3ea2fb2c40ca390aecfb697 Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Thu, 2 Mar 2017 12:09:21 -0600 Subject: [PATCH 46/55] Documentation Update for 4.4.3 --- autofactory/index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index b76307f..ad2fff9 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -95,9 +95,9 @@

Auto-factories public class DummyService : IDummyService { public string Name { get; set; } }

Now you declare an interface for your factory:

Missing code sample 'ISimpleDummyFactory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh


public interface ISimpleDummyFactory
{
    IDummyService CreateDummyService();
}

All you need to do is to call CreateFactory when configuring the container as shown below:

Missing code sample 'simple-factory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh


[Fact]
public void Simple_factory_creation()
{
    var container = new Container(cfg =>
    {
        cfg.For<IDummyService>().Use<DummyService>();
        cfg.For<ISimpleDummyFactory>().CreateFactory();
    });

    var factory = container.GetInstance<ISimpleDummyFactory>();

    var component = factory.CreateDummyService();

    component.ShouldNotBeNull();
    component.ShouldBeOfType<DummyService>();
}

Default convention

As for now, Auto-factories support two types of methods:

From a0e53f5d887be08c26c61d7d76f280d045bb28dd Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Thu, 2 Mar 2017 12:11:16 -0600 Subject: [PATCH 47/55] Documentation Update for 4.4.3 --- autofactory/index.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index ad2fff9..81b04d4 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -115,8 +115,7 @@

Default convention


public interface IDummyFactory
{
    // This method will return the names of all registered implementations of TService.
    IList<string> GetNames<TService>();

    // This method will just create the default IDummyService implementation.
    IDummyService CreateDummyService();

    // This method will just create the default IDummyService implementation and pass namePart1 and namePart2 as
    // dependencies.
    IDummyService CreateDummyService(string namePart1, string namePart2);

    // This method will create IDummyService implementation with serviceName name.
    IDummyService GetNamedDummyService(string serviceName, string namePart1, string namePart2);

    // Generic methods are also allowed as factory methods.
    TService CreateService<TService>();

    // Something that is common for event-sourcing implementations.
    IHandler<TMessage> CreateHandler<TMessage>();
}

Custom convention

IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);
-


IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);

IAutoFactoryMethodDefinition is defined as follows:


/// <summary>
/// Describes how AutoFactory should treat the specific method declared in an abstract factory interface.
/// </summary>
public interface IAutoFactoryMethodDefinition
{
    /// <summary>
    /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values.
    /// </summary>
    AutoFactoryMethodType MethodType { get; }

    /// <summary>
    /// The instance type to create.
    /// </summary>
    Type InstanceType { get; }

    /// <summary>
    /// The instance name if available.
    /// </summary>
    string InstanceName { get; }

    /// <summary>
    /// Explicit arguments if available.
    /// </summary>
    ExplicitArguments ExplicitArguments { get; }
}

@@ -95,9 +95,9 @@

Auto-factories public class DummyService : IDummyService { public string Name { get; set; } }

Now you declare an interface for your factory:


public interface ISimpleDummyFactory
{
    IDummyService CreateDummyService();
}

Missing code sample 'ISimpleDummyFactory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

All you need to do is to call CreateFactory when configuring the container as shown below:


[Fact]
public void Simple_factory_creation()
{
    var container = new Container(cfg =>
    {
        cfg.For<IDummyService>().Use<DummyService>();
        cfg.For<ISimpleDummyFactory>().CreateFactory();
    });

    var factory = container.GetInstance<ISimpleDummyFactory>();

    var component = factory.CreateDummyService();

    component.ShouldNotBeNull();
    component.ShouldBeOfType<DummyService>();
}

Missing code sample 'simple-factory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

Default convention

As for now, Auto-factories support two types of methods:

@@ -115,7 +115,8 @@

Default convention


public interface IDummyFactory
{
    // This method will return the names of all registered implementations of TService.
    IList<string> GetNames<TService>();

    // This method will just create the default IDummyService implementation.
    IDummyService CreateDummyService();

    // This method will just create the default IDummyService implementation and pass namePart1 and namePart2 as
    // dependencies.
    IDummyService CreateDummyService(string namePart1, string namePart2);

    // This method will create IDummyService implementation with serviceName name.
    IDummyService GetNamedDummyService(string serviceName, string namePart1, string namePart2);

    // Generic methods are also allowed as factory methods.
    TService CreateService<TService>();

    // Something that is common for event-sourcing implementations.
    IHandler<TMessage> CreateHandler<TMessage>();
}

Custom convention


IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);

IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);
+

IAutoFactoryMethodDefinition is defined as follows:


/// <summary>
/// Describes how AutoFactory should treat the specific method declared in an abstract factory interface.
/// </summary>
public interface IAutoFactoryMethodDefinition
{
    /// <summary>
    /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values.
    /// </summary>
    AutoFactoryMethodType MethodType { get; }

    /// <summary>
    /// The instance type to create.
    /// </summary>
    Type InstanceType { get; }

    /// <summary>
    /// The instance name if available.
    /// </summary>
    string InstanceName { get; }

    /// <summary>
    /// Explicit arguments if available.
    /// </summary>
    ExplicitArguments ExplicitArguments { get; }
}

diff --git a/best-practices/index.html b/best-practices/index.html index edd6135..a5e05b7 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index f0eca72..8adb7cf 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html index 95ee2d1..fd75492 100644 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/index.html b/diagnostics/index.html index e9aed9e..695912a 100644 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html index 0b5e426..801b93a 100644 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index 6bdea95..820aa0a 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index 482ad07..7b23547 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html index e3a31b8..66ad809 100644 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -31,7 +31,7 @@

diff --git a/documentation/index.html b/documentation/index.html index 78b64d3..56656af 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -31,7 +31,7 @@

diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html index dda9850..b8fb076 100644 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -31,7 +31,7 @@

diff --git a/features/index.html b/features/index.html index 7d7aa3e..88fab86 100644 --- a/features/index.html +++ b/features/index.html @@ -31,7 +31,7 @@

diff --git a/generics/index.html b/generics/index.html index 71955f8..d1a7871 100644 --- a/generics/index.html +++ b/generics/index.html @@ -31,7 +31,7 @@

diff --git a/get-structuremap/index.html b/get-structuremap/index.html index 03748dc..10fd05a 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -31,7 +31,7 @@

diff --git a/glossary/index.html b/glossary/index.html index b699daf..a8e5830 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -31,7 +31,7 @@

diff --git a/history/index.html b/history/index.html index d73e872..021aca5 100644 --- a/history/index.html +++ b/history/index.html @@ -31,7 +31,7 @@

diff --git a/instances/index.html b/instances/index.html index 2d463eb..ee4c7e4 100644 --- a/instances/index.html +++ b/instances/index.html @@ -31,7 +31,7 @@

diff --git a/integrations/index.html b/integrations/index.html index 410678f..8eb4bd8 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -31,7 +31,7 @@

@@ -95,9 +95,8 @@

ASP.NET MVC 5

StructureMap into ASP.NET MVC. The design is necessarily odd to work around ASP.NET limitations, but you do get the all important "nested container per HTTP request" pattern that we recommend.

ASP.NET Web API

The StructureMap team recommends the StructureMap.WebApi2 NuGet package. -The IoC integration in Web API is somewhat better designed than ASP.NET MVC's bolt on mechanism and the StructureMap integration -is quite a bit cleaner.

The easiest way to integrate StructureMap with ASP.NET Web API is with the WebApi.StructureMap NuGet package. This package requires StructureMap 4.1 or higher. +Use the StructureMap.WebApi2 NuGet package for older versions of StructureMap or combined ASP.NET MVC and Web API projects where you already use the StructureMap.MVC5 NuGet package.

ASP.NET Core

See the StructureMap.Microsoft.DependencyInjection project and NuGet package for integration with ASP.NET Core.

NServiceBus

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index c1588bc..f28ff6e 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -31,7 +31,7 @@

diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index 226e508..fd43081 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index 37c43e5..608d01d 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index 66f591b..1fa5c87 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index 66e631a..42060ec 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -31,7 +31,7 @@

diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index c9dc907..fc8836a 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -31,7 +31,7 @@

diff --git a/quickstart/index.html b/quickstart/index.html index bf2d6a2..79a1d88 100644 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -31,7 +31,7 @@

diff --git a/registration/attributes/index.html b/registration/attributes/index.html index 72853d6..c58a0ff 100644 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -31,7 +31,7 @@

diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index cbdbcf3..53a3258 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -31,7 +31,7 @@

diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index 39b1c8b..71e67df 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -31,7 +31,7 @@

diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index c0dc3d7..7ebcd7a 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index a981950..43b919d 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -31,7 +31,7 @@

diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index 28476bd..42e1dc2 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -31,7 +31,7 @@

diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html index de23a13..2fd14b8 100644 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -31,7 +31,7 @@

diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index 639e20b..78a3980 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -31,7 +31,7 @@

diff --git a/registration/index.html b/registration/index.html index f0813c0..eafdac2 100644 --- a/registration/index.html +++ b/registration/index.html @@ -31,7 +31,7 @@

diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index 40e325b..1319aaf 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index abd3129..66a1932 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/policies/index.html b/registration/policies/index.html index cdfea68..7b77fbf 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 990c047..15dd898 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -31,7 +31,7 @@

diff --git a/release-notes/index.html b/release-notes/index.html index e667933..b5980f9 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html index 0255667..a768e3e 100644 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html index f165e88..00f5490 100644 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html index c5c3796..75ef9f1 100644 --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -31,7 +31,7 @@

@@ -94,7 +94,7 @@

Get all Services by Plugin Type GetAllInstances() method shown below:


[Fact]
public void get_all_instances()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Add<AWidget>().Named("A");
        x.For<IWidget>().Add<BWidget>().Named("B");
        x.For<IWidget>().Add<CWidget>().Named("C");
    });

    container.GetAllInstances<IWidget>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // or

    container.GetAllInstances(typeof(IWidget))
        .OfType<IWidget>() // returns an IEnumerable, so I'm casting here
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
}

GetAllInstances() respects the order in which the actual instances are configured in the Container. Be warned that some other IoC tools make different assumptions if you are coming from a different tool.

diff --git a/resolving/index.html b/resolving/index.html index cd42b8d..ea4bac3 100644 --- a/resolving/index.html +++ b/resolving/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html index bd75663..d42c6dd 100644 --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index a62324b..0a154ae 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html index 4ef0c59..f37d625 100644 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html index d9f5b55..416de1f 100644 --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -31,7 +31,7 @@

diff --git a/roadmap/index.html b/roadmap/index.html index 85f47dd..c428f22 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -31,7 +31,7 @@

diff --git a/setter-injection/index.html b/setter-injection/index.html index aad8366..20f5564 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -31,7 +31,7 @@

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index 2c6c88b..dc8fde2 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index bf4d146..d5b9d22 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index 9a3fdc2..afed293 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index 461dc84..b1c2ce5 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/index.html b/the-container/index.html index 8360f2a..a477e24 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 41c8a92..770d517 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html index 5c53fa4..95a6b37 100644 --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 8278337..457ef15 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index f844bdd..e8cfe06 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index e7be927..1cf5948 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index deb50e8..eb2d7fa 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index 2d75002..4ee3f4d 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -31,7 +31,7 @@

From 745337314c6b7fc872458cb2eb7af1c4657caac0 Mon Sep 17 00:00:00 2001 From: Jeremy Miller Date: Wed, 9 Aug 2017 06:46:12 -0500 Subject: [PATCH 49/55] Documentation Update for 4.5.1 --- autofactory/index.html | 4 +- best-practices/index.html | 298 +++++++++--------- diagnostics/build-plans/index.html | 298 +++++++++--------- diagnostics/environment-tests/index.html | 298 +++++++++--------- diagnostics/index.html | 298 +++++++++--------- diagnostics/type-scanning/index.html | 4 +- .../using-the-container-model/index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- diagnostics/whatdoihave/index.html | 298 +++++++++--------- documentation/index.html | 4 +- dynamic-interception/index.html | 4 +- features/index.html | 298 +++++++++--------- generics/index.html | 4 +- get-structuremap/index.html | 298 +++++++++--------- glossary/index.html | 298 +++++++++--------- history/index.html | 298 +++++++++--------- instances/index.html | 4 +- integrations/index.html | 298 +++++++++--------- interception-and-decorators/index.html | 298 +++++++++--------- interpreting-exceptions/index.html | 298 +++++++++--------- .../configuring-lifecycles/index.html | 298 +++++++++--------- object-lifecycle/custom-lifecycles/index.html | 298 +++++++++--------- object-lifecycle/index.html | 298 +++++++++--------- .../supported-lifecycles/index.html | 298 +++++++++--------- quickstart/index.html | 298 +++++++++--------- registration/attributes/index.html | 6 +- .../index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- registration/clear-or-replace/index.html | 4 +- registration/configured-instance/index.html | 4 +- registration/constructor-selection/index.html | 298 +++++++++--------- registration/existing-objects/index.html | 4 +- registration/fallback-services/index.html | 298 +++++++++--------- registration/index.html | 298 +++++++++--------- registration/inline-dependencies/index.html | 298 +++++++++--------- .../on-missing-family-policies/index.html | 298 +++++++++--------- registration/policies/index.html | 4 +- registration/registry-dsl/index.html | 298 +++++++++--------- release-notes/index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- .../get-a-service-by-plugintype/index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- resolving/index.html | 298 +++++++++--------- .../passing-arguments-at-runtime/index.html | 298 +++++++++--------- .../requesting-a-concrete-type/index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- roadmap/index.html | 298 +++++++++--------- setter-injection/index.html | 4 +- software-design-concepts/index.html | 298 +++++++++--------- the-container/auto-wiring/index.html | 298 +++++++++--------- the-container/disposing/index.html | 4 +- .../index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- the-container/index.html | 298 +++++++++--------- the-container/lambdas/index.html | 4 +- the-container/lazy-resolution/index.html | 4 +- the-container/nested-containers/index.html | 298 +++++++++--------- the-container/primitives/index.html | 4 +- .../profiles-and-child-containers/index.html | 298 +++++++++--------- .../working-with-enumerable-types/index.html | 298 +++++++++--------- .../index.html | 298 +++++++++--------- 62 files changed, 6887 insertions(+), 6887 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index 436d201..0df9539 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -31,7 +31,7 @@

diff --git a/best-practices/index.html b/best-practices/index.html index a5e05b7..f076300 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Best Practices - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Best Practices Edit on GitHub

- -

+ + + + + + + + StructureMap - Best Practices + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Best Practices Edit on GitHub

+ +

All of these recommendations are the opinions and sole responsiblity of one Jeremy D. Miller. The single best advice I can give you @@ -126,62 +126,62 @@

Favor Build Pol
While there are many powerful things you can do with StructureMap at runtime for conditional object resolution with lambdas and IContext, I recommend trying to "bake in" building decisions upfront with build policies for more efficient object resolution and so that the container behavior is surfaced through diagnostics like the build plan visualization.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index 8adb7cf..5a6b2b8 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Build Plans - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Build Plans Edit on GitHub

- -

+ + + + + + + + StructureMap - Build Plans + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Build Plans Edit on GitHub

+ +

StructureMap 3.0 introduced the concept of the "Build Plan." The build plan is a textual representation of exactly how StructureMap will build a given Instance, including:

@@ -119,62 +119,62 @@

Build Plans var description = theContainer.Model.For<IDevice>() .Find("A") .DescribeBuildPlan();
See Using the Container Model for more information on using `Container.Model`.

You can find many more examples of finding the build plan description from `Container.Model` from the unit tests in the StructureMap codebase.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html index fd75492..6ebca53 100644 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Environment Tests - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Environment Tests Edit on GitHub

- -

+ + + + + + + + StructureMap - Environment Tests + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Environment Tests Edit on GitHub

+ +

@@ -100,62 +100,62 @@

Environment Tests [ValidationMethod] attribute as shown below:


public class Database : IDatabase
{
    [ValidationMethod]
    public void TryToConnect()
    {
        // try to open a connection to the configured
        // database connection string

        // throw an exception if the database cannot
        // be reached
    }
}

Used in conjunction with StructureMap's ability to validate a container, you can use this technique to quickly support environment tests embedded into your system code.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/diagnostics/index.html b/diagnostics/index.html index 695912a..02befc8 100644 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -1,153 +1,153 @@ - - - - - - - - StructureMap - Diagnostics - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Diagnostics Edit on GitHub

- -

+ + + + + + + + StructureMap - Diagnostics + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Diagnostics Edit on GitHub

+ +

Improving StructureMap's ability to diagnose and explain both configuration and runtime problems was a very big goal for the big 3.0 release and improved with additional type scanning diagnostics for 4.0.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html index 801b93a..49c0fd1 100644 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -31,7 +31,7 @@

diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index 820aa0a..be27c2b 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Using the Container Model - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Using the Container Model Edit on GitHub

- -

+ + + + + + + + StructureMap - Using the Container Model + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Using the Container Model Edit on GitHub

+ +

@@ -127,62 +127,62 @@

Finding all Possible

Working with Individual Instances

You can manipulate an individual instance in several ways:


// First, find the model for a single Instance
var instance = container.Model.For<IDevice>().Default;

// build or resolve an object for this Instance cast to
// the type specified to the Get() method
instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>();

// if the instance is configured as a SingletonThing, test
// if the SingletonThing object has already been created
var hasSingletonBeenCreated = instance.ObjectHasBeenCreated();

if (hasSingletonBeenCreated)
{
    // remove the SingletonThing object from the cache so that
    // StructureMap will be forced to rebuild this object
    instance.EjectObject();
}

// test the lifecycle of this instance
instance.Lifecycle.ShouldBeOfType<SingletonLifecycle>();

// Visualize the build plan no more than 3 levels deep
Debug.WriteLine(instance.DescribeBuildPlan(3));

// Get at the underlying Instance model that StructureMap itself
// uses. Be cautious using this.
var rawModel = instance.Instance;

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index 7b23547..d545c6a 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Validating Container Configuration - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Validating Container Configuration Edit on GitHub

- -

+ + + + + + + + StructureMap - Validating Container Configuration + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Validating Container Configuration Edit on GitHub

+ +

@@ -117,62 +117,62 @@

Validating Container Configuration Standin Dependencies for Runtime Dependencies

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html index 66ad809..62dc49a 100644 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - WhatDoIHave() - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

WhatDoIHave() Edit on GitHub

- -

+ + + + + + + + StructureMap - WhatDoIHave() + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

WhatDoIHave() Edit on GitHub

+ +

The IContainer.WhatDoIHave() method can give you a quick textual report of the current configuration of a running Container:

@@ -103,62 +103,62 @@

WhatDoIHave() Filtering WhatDoIHave()

Filtering the WhatDoIHave() results can be done in these ways:


var container = new Container();

// Filter by the Assembly of the Plugin Type
var byAssembly = container.WhatDoIHave(assembly: typeof(IWidget).GetAssembly());

// Only report on the specified Plugin Type
var byPluginType = container.WhatDoIHave(typeof(IWidget));

// Filter to Plugin Type's in the named namespace
// The 'IsInNamespace' test will include child namespaces
var byNamespace = container.WhatDoIHave(@namespace: "StructureMap.Testing.Widget");

// Filter by a case insensitive string.Contains() match
// against the Plugin Type name
var byType = container.WhatDoIHave(typeName: "Widget");

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/documentation/index.html b/documentation/index.html index 56656af..632d899 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -31,7 +31,7 @@

diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html index b8fb076..720b21e 100644 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -31,7 +31,7 @@

diff --git a/features/index.html b/features/index.html index 88fab86..b9b779e 100644 --- a/features/index.html +++ b/features/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Features - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Features Edit on GitHub

- -

+ + + + + + + + StructureMap - Features + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Features Edit on GitHub

+ +

Note! The StructureMap team will accept pull requests if there's something missing from this list that you'd like to add. @@ -126,62 +126,62 @@

Things StructureMap does not have

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/generics/index.html b/generics/index.html index d1a7871..122be94 100644 --- a/generics/index.html +++ b/generics/index.html @@ -31,7 +31,7 @@

diff --git a/get-structuremap/index.html b/get-structuremap/index.html index 10fd05a..99814fe 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Get StructureMap - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Get StructureMap Edit on GitHub

- -

+ + + + + + + + StructureMap - Get StructureMap + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Get StructureMap Edit on GitHub

+ +

Current Release

@@ -106,62 +106,62 @@

Binaries

Source

StructureMap's source is hosted on GitHub. If you want to fix a bug or just want to tinker with an idea, we love receiving pull requests! Start by creating your own fork on Github.

The StructureMap build tooling has recently changed. See the GitHub README for more information on how to build and work with the StructureMap codebase.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/glossary/index.html b/glossary/index.html index a8e5830..e921a54 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Glossary - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Glossary Edit on GitHub

- -

+ + + + + + + + StructureMap - Glossary + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Glossary Edit on GitHub

+ +

Container

@@ -154,62 +154,62 @@

Auto wiring

rules and fill those dependencies with the default configuration for the declared dependency type.

Let's just see it in action:


public interface Xman
{
}

public class Cyclops : Xman
{
}

public interface Avenger
{
}

public class IronMan : Avenger
{
}

public class CrossoverEvent
{
    public Xman Xman { get; set; }
    public Avenger Avenger { get; set; }

    public CrossoverEvent(Xman xman, Avenger avenger)
    {
        Xman = xman;
        Avenger = avenger;
    }
}

public class UsingCrossover
{
    [Fact]
    public void showing_auto_wiring()
    {
        var container = new Container(x =>
        {
            x.For<Xman>().Use<Cyclops>();
            x.For<Avenger>().Use<IronMan>();
        });

        // Notice that at no point did we define how to
        // build CrossoverEvent.
        var @event = container.GetInstance<CrossoverEvent>();
        @event.Avenger.ShouldBeOfType<IronMan>();
        @event.Xman.ShouldBeOfType<Cyclops>();
    }
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/history/index.html b/history/index.html index 021aca5..8b8340f 100644 --- a/history/index.html +++ b/history/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - History - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

History Edit on GitHub

- -

+ + + + + + + + StructureMap - History + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

History Edit on GitHub

+ +

StructureMap was originally conceived in 2002 as the world's greatest object/relational mapping tool (and frankly a way for me to @@ -100,62 +100,62 @@

History Joys and Pains of a Long Lived Codebase on InfoQ from QCon 2008, or check out Jeremy Miller's updated retrospective talk at CodeMash 2015.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/instances/index.html b/instances/index.html index ee4c7e4..4017357 100644 --- a/instances/index.html +++ b/instances/index.html @@ -31,7 +31,7 @@

diff --git a/integrations/index.html b/integrations/index.html index 8eb4bd8..8c8d41f 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Integrating StructureMap into Common .Net Frameworks - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Integrating StructureMap into Common .Net Frameworks Edit on GitHub

- -

+ + + + + + + + StructureMap - Integrating StructureMap into Common .Net Frameworks + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Integrating StructureMap into Common .Net Frameworks Edit on GitHub

+ +

ASP.NET MVC 5

@@ -113,62 +113,62 @@

Entity Framework

The best example is this blog post from Jimmy Bogard.

AutoMapper

See My AutoMapper setup for StructureMap from Martijn Burgers.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index f28ff6e..114c2be 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Interception and Decorators - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Interception and Decorators Edit on GitHub

- -

+ + + + + + + + StructureMap - Interception and Decorators + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Interception and Decorators Edit on GitHub

+ +

All of the samples from this topic are part of the user acceptance tests in the main codebase. There is also another example of using an interception policy with @@ -183,62 +183,62 @@

Add Interception to a Single Inst OnCreation() and DecorateWith methods or the more generic Instance.AddInterceptor() method. Here is some sample usage from StructureMap's unit tests on interception:


_container = new Container(r =>
{
    r.For<ContextRecorder>().Use(recorder);

    r.For<IService>().AddInstances(x =>
    {
        x.Type<ColorService>()
            // Registers an activation action on this Instance
            .OnCreation("last service", s => _lastService = s)
            .Named("Intercepted")
            .Ctor<string>("color").Is("Red");

        x.Type<ColorService>()
            // Activation using IContext
            .OnCreation("last touched", (c, s) => c.GetInstance<ContextRecorder>().WasTouched = true)
            .Named("InterceptedWithContext")
            .Ctor<string>("color").Is("Red");

        x.Type<ColorService>()
            .Named("NotIntercepted")
            .Ctor<string>("color").Is("Blue");

        x.Object(new ColorService("Yellow"))
            .Named("Yellow")
            .OnCreation("set the last service", s => _lastService = s);

        x.ConstructedBy(() => new ColorService("Purple")).Named("Purple")
            // Applies a decorator to this instance. Not sure *why*
            // you'd want to do it this way
            .DecorateWith(s => new DecoratorService(s));

        x.ConstructedBy(() => new ColorService("Purple")).Named("DecoratedWithContext")
            // Fancier decorator
            .DecorateWith("decorated with context", (c, s) =>
            {
                c.GetInstance<ContextRecorder>().WasTouched = true;
                return new DecoratorService(s);
            });

        x.Type<ColorService>().Named("Decorated").DecorateWith(
            s => new DecoratorService(s))
            .Ctor<string>("color").Is("Orange");

        x.Object(new ColorService("Yellow")).Named("Bad")
            .OnCreation("throw exception", obj => { throw new Exception("Bad!"); });
    });

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index fd43081..642d2b6 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Interpreting Exceptions - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Interpreting Exceptions Edit on GitHub

- -

+ + + + + + + + StructureMap - Interpreting Exceptions + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Interpreting Exceptions Edit on GitHub

+ +

Improving the exception messages was one of the primary goals of the big StructureMap 3.0 release. StructureMap exceptions should @@ -105,62 +105,62 @@

Interpreting Exceptions container validation mechanism

- -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index 608d01d..09709a3 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Configuring Lifecycles - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Configuring Lifecycles Edit on GitHub

- -

+ + + + + + + + StructureMap - Configuring Lifecycles + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Configuring Lifecycles Edit on GitHub

+ +

Unless designated otherwise, StructureMap uses Transient as the default scope for all configured Instance's.

@@ -106,62 +106,62 @@

Using Attributes

The usage is shown below:


[AlwaysUnique]
public interface IShouldBeUnique { }

[Singleton] // because the most wonderful thing about Tiggers is that I'm the only one....
public class Tigger { }

See Using Attributes for Configuration for information about adding your own custom attibutes for other lifecycles.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index 1fa5c87..470558d 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Custom Lifecycles - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Custom Lifecycles Edit on GitHub

- -

+ + + + + + + + StructureMap - Custom Lifecycles + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Custom Lifecycles Edit on GitHub

+ +

Lifecycles in StructureMap are pluggable. To create your own custom lifecycle, make an implementation of the ILifecycle interface like this one:

@@ -95,62 +95,62 @@

Custom Lifecycles public class UsingCustomLifecycle : Registry { public UsingCustomLifecycle() { // at the Plugin Type level For<IService>().LifecycleIs<CustomLifecycle>(); // at the Instance level For<IService>().Use<AService>() .LifecycleIs<CustomLifecycle>(); } }
Most of the built in `ILifecycle` implementations use `LifecycleObjectCache` internally, but you may also need to create your own `IObjectCache` implementation.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index 42060ec..e41905b 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Object Lifecycles - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Object Lifecycles Edit on GitHub

- -

+ + + + + + + + StructureMap - Object Lifecycles + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Object Lifecycles Edit on GitHub

+ +

One of the most valuable functions of using an IoC container tool is its ability to manage the object lifecycle (creating and disposing objects) and scoping (shared objects) @@ -108,62 +108,62 @@

Motivation for Container Managed


public class SingletonService { }

public class SingletonUser
{
    public SingletonUser(SingletonService singleton)
    {
    }
}

public class SingletonScopeRegistry : Registry
{
    public SingletonScopeRegistry()
    {
        For<SingletonService>().Singleton();
    }
}

The big advantage to the second, StructureMap-managed singleton scoping is that my DependencyUser class does not have to have any knowledge of how the ISingletonDependency object is built and certainly no coupling to the hard Singleton mechanics from the first sample that was so harmful in the past.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index fc8836a..18602e7 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Supported Lifecycles - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Supported Lifecycles Edit on GitHub

- -

+ + + + + + + + StructureMap - Supported Lifecycles + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Supported Lifecycles Edit on GitHub

+ +

Out of the box, the core StructureMap assembly supports these lifecycles:

@@ -145,62 +145,62 @@

Legacy ASP.Net Lifecycles

If you do use any of the HttpContext lifecycles, make sure you also do:

Missing code sample 'clean-up-http-context' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh

at the end of your HTTP request.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/quickstart/index.html b/quickstart/index.html index 79a1d88..77eeca9 100644 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - A Gentle Quickstart - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

A Gentle Quickstart Edit on GitHub

- -

+ + + + + + + + StructureMap - A Gentle Quickstart + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

A Gentle Quickstart Edit on GitHub

+ +

The first thing you should know is that StructureMap (and other IoC tools like it) are designed to @@ -127,62 +127,62 @@

Need Help?

There is a google group for StructureMap support.

You can ask questions on StackOverflow with the tag "structuremap."

- -

- - - -

- - - - - - - - - -

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/attributes/index.html b/registration/attributes/index.html index c58a0ff..0019ba7 100644 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -31,7 +31,7 @@

@@ -89,7 +89,7 @@

Using Attributes for Configuration -

In the early days of StructureMap we had several attibutes for basic configuration that we'd just as soon +

In the early days of StructureMap we had several attributes for basic configuration that we'd just as soon forget ever existed. Further more, the StructureMap strongly believes that the usage of StructureMap should have as little impact on application code as possible -- and forcing users to spray .Net attributes all over their own code is in clear violation of this philosophy. In other words, we don't want to be MEF.

diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index 53a3258..d29093d 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Auto-Registration and Conventions - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Auto-Registration and Conventions Edit on GitHub

- -

+ + + + + + + + StructureMap - Auto-Registration and Conventions + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Auto-Registration and Conventions Edit on GitHub

+ +

@@ -169,62 +169,62 @@

The last built in registration convention is a mechanism to register all concrete types that implement at least one interface against the first interface that they implement.


container = new Container(x =>
{
    x.Scan(o =>
    {
        o.TheCallingAssembly();
        o.RegisterConcreteTypesAgainstTheFirstInterface();

        o.Exclude(t => t.CanBeCastTo(typeof(IGateway)));
    });
});

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index 71e67df..23d4307 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Changing Configuration at Runtime - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Changing Configuration at Runtime Edit on GitHub

- -

+ + + + + + + + StructureMap - Changing Configuration at Runtime + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Changing Configuration at Runtime Edit on GitHub

+ +

Use the technique shown here with caution.

@@ -102,62 +102,62 @@

Best Practices

There's a potential performance hit from using Configure() at runtime because StructureMap has to recycle its internal Build Plan's based on the potential new configuration.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index 7ebcd7a..92eceb6 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index 43b919d..60233d2 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -31,7 +31,7 @@

diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index 42e1dc2..c379d83 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Constructor Selection - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Constructor Selection Edit on GitHub

- -

+ + + + + + + + StructureMap - Constructor Selection + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Constructor Selection Edit on GitHub

+ +

StructureMap 3.* greatly improves the control over the selection of constructor functions to build concrete types @@ -127,62 +127,62 @@

Custom Constructor Selection Rule


public class ThingCtorRule : IConstructorSelector
{
    public ConstructorInfo Find(Type pluggedType, DependencyCollection dependencies, PluginGraph graph)
    {
        // if this rule does not apply to the pluggedType,
        // just return null to denote "not applicable"
        if (!pluggedType.CanBeCastTo<BaseThing>()) return null;

        return pluggedType.GetConstructor(new[] { typeof(IWidget) });
    }
}

Finally, you can register your custom rule as shown below:


[Fact]
public void use_a_custom_constructor_selector()
{
    var container = new Container(_ =>
    {
        _.For<IWidget>().Use<AWidget>();

        _.Policies.ConstructorSelector<ThingCtorRule>();
    });

    container.GetInstance<Thing1>()
        .CorrectCtorWasUsed.ShouldBeTrue();

    container.GetInstance<Thing2>()
        .CorrectCtorWasUsed.ShouldBeTrue();
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html index 2fd14b8..5da4b01 100644 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -31,7 +31,7 @@

diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index 78a3980..9424b71 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Fallback Services - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Fallback Services Edit on GitHub

- -

+ + + + + + + + StructureMap - Fallback Services + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Fallback Services Edit on GitHub

+ +

The following is a technique that was stolen from FubuMVC where we used @@ -101,62 +101,62 @@

Fallback Services [AttributeUsage(AttributeTargets.Assembly)] public class ProductModuleAttribute : Attribute { } public class ApplicationRegistry : Registry { public ApplicationRegistry() { // Use the default services as fallbacks IncludeRegistry<DefaultServices>(); // Dependending on what assemblies are present, // this might find specific registrations that // will take precedence over the UseIfNone() // registrations in DefaultServices Scan(_ => { _.AssembliesFromApplicationBaseDirectory( assem => assem.HasAttribute<ProductModuleAttribute>()); _.LookForRegistries(); }); } } [Fact] public void see_use_if_none_in_action() { var container1 = Container.For<DefaultServices>(); // No other registrations, so fallback // to AWidget container1.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); var container2 = new Container(_ => { // add both registries above // NOTE: the order does not matter for IWidget _.IncludeRegistry<SpecificServices>(); _.IncludeRegistry<DefaultServices>(); }); // The registration in SpecificServices // should win out container2.GetInstance<IWidget>() .ShouldBeOfType<BWidget>(); } - -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/index.html b/registration/index.html index eafdac2..8d71c46 100644 --- a/registration/index.html +++ b/registration/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Registration - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Registration Edit on GitHub

- -

+ + + + + + + + StructureMap - Registration + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Registration Edit on GitHub

+ +

As of the 3.0 release, StructureMap provides a streamlined fluent interface called the Registry DSL to configure a StructureMap @@ -115,62 +115,62 @@

Registration var container = new Container(c => { //just for demo purposes, normally you don't want to embed the connection string directly into code. c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING"); //a better way would be providing a delegate that retrieves the value from your app config. });
So far you have seen an couple of ways to work with the Registry DSL and configure a `Container` object. We have seen examples of configuration that allow us to build objects that don't depend on anything like the `Bar` class, or do depend on other types like the `Foo` class needs an instance of `IBar`. In our last example we have seen configuration for objects that need some primitive types like strings in its constructor function.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index 1319aaf..97ad4f9 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Inline Dependencies - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Inline Dependencies Edit on GitHub

- -

+ + + + + + + + StructureMap - Inline Dependencies + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Inline Dependencies Edit on GitHub

+ +

While you generally allow StructureMap to just use auto-wiring to fill the dependencies of a concrete type, there are times @@ -134,62 +134,62 @@

Programmatic Con

It's frequently useful to explicitly configure all the elements for an enumerable argument (arrays, IEnumerable, or IList). StructureMap provides this syntax to do just that:


public class BigRule : IEventRule
{
    private readonly IEnumerable<ICondition> _conditions;
    private readonly IEnumerable<IAction> _actions;

    public BigRule(IEnumerable<ICondition> conditions, IEnumerable<IAction> actions)
    {
        _conditions = conditions;
        _actions = actions;
    }

    public void ProcessEvent(SomeEvent @event)
    {
        if (_conditions.Any(x => x.Matches(@event)))
        {
            _actions.Each(x => x.PerformWork(@event));
        }
    }
}

public class BigRuleRegistry : Registry
{
    public BigRuleRegistry()
    {
        For<IEventRule>().Use<BigRule>()

            // Each line in the nested closure adds another
            // ICondition to the enumerable dependency in
            // the order in which they are configured
            .EnumerableOf<ICondition>().Contains(_ =>
            {
                _.Type<Condition1>();
                _.Type<Condition2>();
            })
            .EnumerableOf<IAction>().Contains(_ =>
            {
                _.Type<Action1>();
                _.Object(new Action2());
            });
    }
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index 66a1932..488c16c 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - On Missing Family Policies - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

On Missing Family Policies Edit on GitHub

- -

+ + + + + + + + StructureMap - On Missing Family Policies + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

On Missing Family Policies Edit on GitHub

+ +

New for StructureMap 3.0 is a feature to create missing service registrations at runtime based on pluggable rules using the new IFamilyPolicy @@ -130,62 +130,62 @@

Using a Custom IFamilyPolicy"

To use register the custom SettingPolicy, use one of the Registry.Policies.OnMissingFamily() methods:


public class SettingsRegistry : Registry
{
    public SettingsRegistry()
    {
        For<ISettingsProvider>().Use<AppSettingsProvider>();
        Policies.OnMissingFamily<SettingPolicy>();
    }
}

You can see the real implementation of the SettingPolicy in action in its integration tests on GitHub.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/policies/index.html b/registration/policies/index.html index 7b77fbf..154e1e0 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -31,7 +31,7 @@

diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 15dd898..fbbe6e8 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Registry DSL - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Registry DSL Edit on GitHub

- -

+ + + + + + + + StructureMap - Registry DSL + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Registry DSL Edit on GitHub

+ +

Creating Registry classes is the recommended way of using the Registry DSL.

@@ -137,62 +137,62 @@

Named Instances


[Fact]
public void SimpleCaseWithNamedInstance()
{
    container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("MyInstance"); });
    // retrieve an instance by name
    var widget = (AWidget)container.GetInstance<IWidget>("MyInstance");
    widget.ShouldNotBeNull();
}

You can also register named instances with the following shorthand:


[Fact]
public void A_concrete_type_is_available_by_name_when_it_is_added_by_the_shorthand_mechanism()
{
    IContainer container = new Container(r => r.For<IAddTypes>().AddInstances(x =>
    {
        x.Type<RedAddTypes>().Named("Red");
        x.Type<GreenAddTypes>().Named("Green");
        x.Type<BlueAddTypes>().Named("Blue");
        x.Type<PurpleAddTypes>();
    }));
    // retrieve the instances by name
    container.GetInstance<IAddTypes>("Red").IsType<RedAddTypes>();
    container.GetInstance<IAddTypes>("Green").IsType<GreenAddTypes>();
    container.GetInstance<IAddTypes>("Blue").IsType<BlueAddTypes>();
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/release-notes/index.html b/release-notes/index.html index b5980f9..424f805 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Release Notes - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Release Notes Edit on GitHub

- -

+ + + + + + + + StructureMap - Release Notes + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Release Notes Edit on GitHub

+ +

StructureMap is attempting to follow a strict SemVer versioning policy.

@@ -191,62 +191,62 @@

Release Notes 3.0

http://jeremydmiller.com/2013/02/22/big-update-on-structuremap-3-0-progress/

http://jeremydmiller.com/2013/01/30/lets-try-this-again-structuremap-3-0-in-en-route-as-of-now/

- -

- - - -

- - - - - - - - - -

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Get a Service by Plugin Type and Name

- -

- - -

Get a Service by Plugin Type and Name Edit on GitHub

- -

+ + + + + + + + StructureMap - Get a Service by Plugin Type and Name + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Get a Service by Plugin Type and Name Edit on GitHub

+ +

You can also request a named configuration for a given PluginType by using the overloads of IContainer.GetInstance() that take in a name like this:


[Fact]
public void get_a_named_instance()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Add<AWidget>().Named("A");
        x.For<IWidget>().Add<BWidget>().Named("B");
        x.For<IWidget>().Add<CWidget>().Named("C");
    });

    container.GetInstance<IWidget>("A").ShouldBeOfType<AWidget>();
    container.GetInstance<IWidget>("B").ShouldBeOfType<BWidget>();
    container.GetInstance<IWidget>("C").ShouldBeOfType<CWidget>();

    // or

    container.GetInstance(typeof(IWidget), "A").ShouldBeOfType<AWidget>();
    container.GetInstance(typeof(IWidget), "B").ShouldBeOfType<BWidget>();
    container.GetInstance(typeof(IWidget), "C").ShouldBeOfType<CWidget>();
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Get a Service by PluginType

- -

- - -

Get a Service by PluginType Edit on GitHub

- -

+ + + + + + + + StructureMap - Get a Service by PluginType + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Get a Service by PluginType Edit on GitHub

+ +

Requesting the default configured object of a plugin type is done through the IContainer.GetInstance() method shown below:


[Fact]
public void get_the_default_instance()
{
    var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); });

    container.GetInstance<IWidget>()
        .ShouldBeOfType<AWidget>();

    // or

    container.GetInstance(typeof(IWidget))
        .ShouldBeOfType<AWidget>();
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Get all Services by Plugin Type

- -

- - -

Get all Services by Plugin Type Edit on GitHub

- -

+ + + + + + + + StructureMap - Get all Services by Plugin Type + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Get all Services by Plugin Type Edit on GitHub

+ +

Please see Working with Enumerable Types for a lot more information about what's going on behind the @@ -95,62 +95,62 @@

Get all Services by Plugin Type GetAllInstances() method shown below:


[Fact]
public void get_all_instances()
{
    var container = new Container(x =>
    {
        x.For<IWidget>().Add<AWidget>().Named("A");
        x.For<IWidget>().Add<BWidget>().Named("B");
        x.For<IWidget>().Add<CWidget>().Named("C");
    });

    container.GetAllInstances<IWidget>()
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));

    // or

    container.GetAllInstances(typeof(IWidget))
        .OfType<IWidget>() // returns an IEnumerable, so I'm casting here
        .Select(x => x.GetType())
        .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget));
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Resolving Services

- -

- - -

Resolving Services Edit on GitHub

- -

+ + + + + + + + StructureMap - Resolving Services + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Resolving Services Edit on GitHub

+ +

This will be the easy part of interacting with StructureMap. During application execution, you will need to resolve the services you previously registered in the container. When you ask StructureMap to resolve a service, StructureMap either creates a new object instance or finds the previously built object for the correct Object Lifecycles.

While in many systems you will probably only resolve the default service of a type or a named instance of a service, there are far more ways to resolve services exposed by StructureMap. The IContainer interface acts as a Service Locator to build and resolve configured services on demand.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Passing Arguments at Runtime

- -

- - -

Passing Arguments at Runtime Edit on GitHub

- -

+ + + + + + + + StructureMap - Passing Arguments at Runtime + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Passing Arguments at Runtime Edit on GitHub

+ +

Most of the time you will be using StructureMap to build objects based on pre-canned configuration established upfront, but StructureMap @@ -119,62 +119,62 @@

Using the ExplicitArguments objectFinally, you can also pass an object of type ExplicitArguments directly to an overload of the IContainer.GetInstance() method:


var widget = new BWidget();
var service = new BService();

var args = new ExplicitArguments();
args.Set<IWidget>(widget);
args.Set<IService>(service);

var guyWithWidgetAndService = container
    .GetInstance<GuyWithWidgetAndService>(args);

guyWithWidgetAndService
    .Widget.ShouldBeTheSameAs(widget);

guyWithWidgetAndService
    .Service.ShouldBeTheSameAs(service);

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Auto Resolving Concrete Types

- -

- - -

Auto Resolving Concrete Types Edit on GitHub

- -

+ + + + + + + + StructureMap - Auto Resolving Concrete Types + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Auto Resolving Concrete Types Edit on GitHub

+ +

StructureMap allows you to resolve instances of concrete classes without configuring that concrete type with a few provisos:

@@ -104,62 +104,62 @@

Auto Resolving Concrete Types Auto Wiring. It's basically a smart way of building instances of types by looking to the constructors of the requested and all the needed underlaying types. During this inspection StructureMap also uses any provided configuration to help building the requested service or dependency.

In our example, where there isn't any configuration available, StructureMap looks at the constructor of the requested `Weather` type. It sees that it depends on four concrete types which all have a default constructor. StructureMap is therefore able to create an instance for all of them and inject them into the `Weather` constructor. After that the `Weather` instance is returned to the caller.

Most of the time you will be mapping abstractions to concrete types, but as you have seen StructureMap supports other use cases as well.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Try Geting an Optional Service by Plugin Type and Name

- -

- - -

Try Geting an Optional Service by Plugin Type and Name Edit on GitHub

- -

+ + + + + + + + StructureMap - Try Geting an Optional Service by Plugin Type and Name + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Try Geting an Optional Service by Plugin Type and Name Edit on GitHub

+ +

Just use the IContainer.TryGetInstance<T>(name) or IContainer.TryGetInstance(Type pluginType, string name) method as shown below:


[Fact]
public void TryGetInstanceViaNameAndGeneric_ReturnsInstance_WhenTypeFound()
{
    addColorInstance("Red");
    addColorInstance("Orange");
    addColorInstance("Blue");

    // "Orange" exists, so an object should be returned
    var instance = _container.TryGetInstance<Rule>("Orange");
    instance.ShouldBeOfType(typeof(ColorRule));
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - Try Getting an Optional Service by Plugin Type

- -

- - -

Try Getting an Optional Service by Plugin Type Edit on GitHub

- -

+ + + + + + + + StructureMap - Try Getting an Optional Service by Plugin Type + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Try Getting an Optional Service by Plugin Type Edit on GitHub

+ +

The StructureMap team does not recommend using "optional" dependencies as shown in this topic, but @@ -115,62 +115,62 @@

Optional Generic Types

If you are using open generic types, the TryGetInstance() mechanism can close the open generic registration to satisfy the optional dependency like this sample:


public interface IThing<T>
{
}

public class Thing<T> : IThing<T>
{
}

[Fact]
public void can_try_get_open_type_resolution()
{
    var container = new Container(_ => { _.For(typeof(IThing<>)).Use(typeof(Thing<>)); });

    container.TryGetInstance<IThing<string>>()
        .ShouldBeOfType<Thing<string>>();
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/roadmap/index.html b/roadmap/index.html index c428f22..85e797a 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Roadmap - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Roadmap Edit on GitHub

- -

+ + + + + + + + StructureMap - Roadmap + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Roadmap Edit on GitHub

+ +

StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's. The 4.0 release was @@ -100,62 +100,62 @@

Ongoing and upcoming work

StructureMap.AutoFactory

Auto Mocking updates and modernization

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/setter-injection/index.html b/setter-injection/index.html index 20f5564..7f11f58 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -31,7 +31,7 @@

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index dc8fde2..5ef23a9 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Software Design Concepts - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Software Design Concepts Edit on GitHub

- -

+ + + + + + + + StructureMap - Software Design Concepts + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Software Design Concepts Edit on GitHub

+ +

Inversion of Control

@@ -101,62 +101,62 @@

Service Locator

StructureMap also fills the role of a service locator. In this usage, your code would directly access StructureMap's Container class to build or resolve services upon demand like this sample:


public class ThirdDatabaseUser
{
    private IDatabase _database;

    public ThirdDatabaseUser(IContainer container)
    {
        // This is service location
        _database = container.GetInstance<IDatabase>();
    }
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index d5b9d22..d889ce8 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Auto Wiring - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Auto Wiring Edit on GitHub

- -

+ + + + + + + + StructureMap - Auto Wiring + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Auto Wiring Edit on GitHub

+ +

@@ -120,62 +120,62 @@

Auto Wiring Working with Primitive Types for more information on how StructureMap deals with primitive types like numbers, strings, enums, and dates in auto-wiring.
- -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index afed293..948da72 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index a043cfc..5ea38dd 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Registering a Single Instance Against Multiple PluginTypes - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Registering a Single Instance Against Multiple PluginTypes Edit on GitHub

- -

+ + + + + + + + StructureMap - Registering a Single Instance Against Multiple PluginTypes + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Registering a Single Instance Against Multiple PluginTypes Edit on GitHub

+ +

It's not uncommon to want a single instance registration in StructureMap to be mapped to multiple @@ -105,62 +105,62 @@

Registering a Single Instance Against Multiple PluginTypes lambda registrations:


[Fact]
public void equivalent()
{
    var container = new Container(_ =>
    {
        // Let's make StatefulCache a SingletonThing in the container
        _.ForConcreteType<StatefulCache>().Configure.Singleton();

        _.For<IReader>().Use(c => c.GetInstance<StatefulCache>());
        _.For<IWriter>().Use(c => c.GetInstance<StatefulCache>());
    });

    container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
    container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index b1c2ce5..cd85861 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Handling Missing Named Instances - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Handling Missing Named Instances Edit on GitHub

- -

+ + + + + + + + StructureMap - Handling Missing Named Instances + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Handling Missing Named Instances Edit on GitHub

+ +

Let's say that something asks StructureMap to resolve a named instance of a type that StructureMap does not know about. What if instead @@ -120,62 +120,62 @@

Multi-Tenancy

to construct the rules object. The code below is a partial sample of how you might use the missing named instance feature to do data lookups inside of StructureMap:


public interface IClientRulesRepsitory
{
    ClientRulesData Find(string clientName);
}

public class ClientRulesData
{
}

public class DataUsingRule : Rule
{
    private readonly ClientRulesData _data;

    public DataUsingRule(ClientRulesData data)
    {
        _data = data;
    }
}

[Fact]
public void register_by_looking_up_data()
{
    var container = new Container(_ =>
    {
        _.For<Rule>().MissingNamedInstanceIs.ConstructedBy(
            "Building client rules by looking up client data", c =>
            {
                var data = c.GetInstance<IClientRulesRepsitory>()
                    .Find(c.RequestedName);

                return new DataUsingRule(data);
            });
    });
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/index.html b/the-container/index.html index a477e24..5e537c6 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -1,154 +1,154 @@ - - - - - - - - StructureMap - The Container - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

The Container Edit on GitHub

- -

+ + + + + + + + StructureMap - The Container + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

The Container Edit on GitHub

+ +

The primary way to interact with StructureMap is through the IContainer interface and Container class. The following topics discuss some of the features and internal workings of the Container.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 770d517..06c7df0 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html index 95a6b37..72ebf2f 100644 --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 457ef15..cb4e648 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Nested Containers (Per Request/Transaction) - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Nested Containers (Per Request/Transaction) Edit on GitHub

- -

+ + + + + + + + StructureMap - Nested Containers (Per Request/Transaction) + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Nested Containers (Per Request/Transaction) Edit on GitHub

+ +

Nested Containers are not interchangeable with Child Containers. See Profiles and Child Containers for more information on child containers.

@@ -158,62 +158,62 @@

Disposing Services


[Fact]
public void nested_container_disposal()
{
    var container = new Container(_ =>
    {
        // A SingletonThing scoped service
        _.ForSingletonOf<IColorCache>().Use<ColorCache>();

        // A transient scoped service
        _.For<IColor>().Use<Green>();

        // An AlwaysUnique scoped service
        _.For<Purple>().AlwaysUnique();
    });

    ColorCache singleton = null;
    Green nestedGreen = null;
    Blue nestedBlue = null;
    Purple nestedPurple = null;

    using (var nested = container.GetNestedContainer())
    {
        // SingletonThing's are really built by the parent
        singleton = nested.GetInstance<IColorCache>()
            .ShouldBeOfType<ColorCache>();

        nestedGreen = nested.GetInstance<IColor>()
            .ShouldBeOfType<Green>();

        nestedBlue = nested.GetInstance<Blue>();

        nestedPurple = nested.GetInstance<Purple>();
    }

    // Transients created by the Nested Container
    // are disposed
    nestedGreen.WasDisposed.ShouldBeTrue();
    nestedBlue.WasDisposed.ShouldBeTrue();

    // Unique's created by the Nested Container
    // are disposed
    nestedPurple.WasDisposed.ShouldBeTrue();

    // NOT disposed because it's owned by
    // the parent container
    singleton.WasDisposed.ShouldBeFalse();
}

For the sake of clarity, the classes used in the sample above are:


public interface IColor
{
}

public class Red : IColor
{
}

public class Purple : Blue { }

public class Blue : IColor, IDisposable
{
    public bool WasDisposed;

    public void Dispose()
    {
        WasDisposed = true;
    }
}

public class Green : IColor, IDisposable
{
    public bool WasDisposed;

    public void Dispose()
    {
        WasDisposed = true;
    }
}

public interface IColorCache
{
}

public class ColorCache : IColorCache, IDisposable
{
    public bool WasDisposed;

    public void Dispose()
    {
        WasDisposed = true;
    }
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index e8cfe06..8e2afc0 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -31,7 +31,7 @@

diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index 1cf5948..dd890a4 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Profiles and Child Containers - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Profiles and Child Containers Edit on GitHub

- -

+ + + + + + + + StructureMap - Profiles and Child Containers + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Profiles and Child Containers Edit on GitHub

+ +

Child Containers are not interchangeable with Nested Containers. See Nested Containers (Per Request/Transaction) for more information on nested containers.

@@ -133,62 +133,62 @@

Example: Child Containers swap in stubs without impacting other tests in the test suite.

In action, that usage looks something like this:


public class TheRealService : IService { }

public class StubbedService : IService { }

[Fact]
public void in_testing()
{
    var container = new Container(_ =>
    {
        _.For<IService>().Use<TheRealService>();
    });

    // Create a new child container for only this test
    var testContainer = container.CreateChildContainer();

    // Override a service with a stub that's easier to control
    var stub = new StubbedService();
    testContainer.Inject<IService>(stub);

    // Now, continue with the test resolving application
    // services through the new child container....
}

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index eb2d7fa..ff250af 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Working with Enumerable Types - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Working with Enumerable Types Edit on GitHub

- -

+ + + + + + + + StructureMap - Working with Enumerable Types + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Working with Enumerable Types Edit on GitHub

+ +

While you can certainly use any IEnumerable type as a plugin type with your own explicit configuration, @@ -118,62 +118,62 @@

Sample Usage: Validation Rules

but what if we need to have an extensibility to add more validation rules later? What if we want to add these additional rules in addon packages? Or we just don't want to continuously break into the centralized Registry class every single time we add a new validation rule?

By relying on StructureMap's IEnumerable behavior, we're able to split our IWidgetValidatior registration across multiple Registry classes and that's not infrequently useful to do.

- -

- - - -

- - - - - - - - - - - - - - - - - - + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index 4ee3f4d..d20d188 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -1,93 +1,93 @@ - - - - - - - - StructureMap - Working with the IContext at Build Time - - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

Working with the IContext at Build Time Edit on GitHub

- -

+ + + + + + + + StructureMap - Working with the IContext at Build Time + + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

Working with the IContext at Build Time Edit on GitHub

+ +

The IContext usage shown in this topic is certainly not going away in future versions of StructureMap, but if at all possible, the StructureMap team @@ -128,62 +128,62 @@

Example 2: NHibernate Integration

Sidestepping the issue of how to build an ISessionFactory, here's a possible way to enable a StructureMap Container to build and resolve dependencies of ISession with a lambda builder:

public class SessionFactoryRegistry : Registry { // Let's not worry about how ISessionFactory is built // in this example public SessionFactoryRegistry(ISessionFactory factory) { For<ISessionFactory>().Use(factory); // Build ISession with a lambda: For<ISession>().Use("Build ISession from ISessionFactory", c => { // To resolve ISession, I first pull out // ISessionFactory from the IContext and use that // to build a new ISession. return c.GetInstance<ISessionFactory>().Build(); }); } }
- -

- -
- -
- - Previous: Building Objects with Lambdas - - - - - Next: Registering a Single Instance Against Multiple PluginTypes - - -
- -

- - - - - - - - - - - - - - - - - - + +

+ +
+ +
+ + Previous: Building Objects with Lambdas + + + + + Next: Registering a Single Instance Against Multiple PluginTypes + + +
+ +

+ + + + + + + + + + + + + + + + + + From 24fd284b59c47461d083d42b8efbee8f22526efe Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Tue, 26 Sep 2017 16:14:36 -0500 Subject: [PATCH 50/55] Documentation Update for 4.5.1 --- autofactory/index.html | 4 ++-- glossary/index.html | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index 0df9539..45c2b86 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -95,9 +95,9 @@
Auto-factories public class DummyService : IDummyService { public string Name { get; set; } }
Now you declare an interface for your factory:
-
Missing code sample 'ISimpleDummyFactory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh
+
public interface ISimpleDummyFactory { IDummyService CreateDummyService(); }

All you need to do is to call CreateFactory when configuring the container as shown below:
-
Missing code sample 'simple-factory' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh
+
[Fact] public void Simple_factory_creation() { var container = new Container(cfg => { cfg.For<IDummyService>().Use<DummyService>(); cfg.For<ISimpleDummyFactory>().CreateFactory(); }); var factory = container.GetInstance<ISimpleDummyFactory>(); var component = factory.CreateDummyService(); component.ShouldNotBeNull(); component.ShouldBeOfType<DummyService>(); }

Default convention

As for now, Auto-factories support two types of methods:

diff --git a/glossary/index.html b/glossary/index.html index e921a54..7b503c5 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -92,7 +92,7 @@
Glossary
Container

Tools like StructureMap are generally known as Inversion of Control (IoC) Containers or Dependency Injection (DI) Containers. In the Java world they are also known as Lightweight Containers to differentiate them from the older EJB Containers.
-
A container is a tool that can help you composing object graphs and managing their scope (lifecycle). Altough you can do Inversion of Control and Dependecy Injection manually, using tools like StructureMap makes you far more productive and succesfull in doing so.
+
A container is a tool that can help you composing object graphs and managing their scope (lifecycle). Altough you can do Inversion of Control and Dependency Injection manually, using tools like StructureMap makes you far more productive and succesfull in doing so.

Obviously there is more to a container than resolving services and managing their scope, but in the core that's just what it is. Before you can do so you need to tell StructureMap, the container, how it must compose those objects graphs and what their lifecycle is. This is called registration and can be done in various mixed ways. The strongly recommend way would be using the Registry DSL. In your registration you're basically mapping abstractions to concrete types and defining their lifecycle.

A simple example of a container using the Registry DSL:

public class FooBarRegistry : Registry { public FooBarRegistry() { For<IFoo>().Use<Foo>(); For<IBar>().Use<Bar>(); } }
From 82270d2a3b69314fe8d07a77d5b452da351260d4 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Tue, 14 Nov 2017 07:57:15 -0600 Subject: [PATCH 51/55] Documentation Update for 4.5.3 --- autofactory/index.html | 4 ++-- best-practices/index.html | 4 ++-- diagnostics/build-plans/index.html | 4 ++-- diagnostics/environment-tests/index.html | 4 ++-- diagnostics/index.html | 4 ++-- diagnostics/type-scanning/index.html | 4 ++-- diagnostics/using-the-container-model/index.html | 4 ++-- diagnostics/validating-container-configuration/index.html | 4 ++-- diagnostics/whatdoihave/index.html | 4 ++-- documentation/index.html | 4 ++-- dynamic-interception/index.html | 4 ++-- features/index.html | 4 ++-- generics/index.html | 4 ++-- get-structuremap/index.html | 4 ++-- glossary/index.html | 4 ++-- history/index.html | 4 ++-- instances/index.html | 4 ++-- integrations/index.html | 4 ++-- interception-and-decorators/index.html | 4 ++-- interpreting-exceptions/index.html | 4 ++-- object-lifecycle/configuring-lifecycles/index.html | 4 ++-- object-lifecycle/custom-lifecycles/index.html | 4 ++-- object-lifecycle/index.html | 4 ++-- object-lifecycle/supported-lifecycles/index.html | 4 ++-- quickstart/index.html | 4 ++-- registration/attributes/index.html | 4 ++-- registration/auto-registration-and-conventions/index.html | 4 ++-- registration/changing-configuration-at-runtime/index.html | 4 ++-- registration/clear-or-replace/index.html | 4 ++-- registration/configured-instance/index.html | 4 ++-- registration/constructor-selection/index.html | 4 ++-- registration/existing-objects/index.html | 4 ++-- registration/fallback-services/index.html | 4 ++-- registration/index.html | 4 ++-- registration/inline-dependencies/index.html | 4 ++-- registration/on-missing-family-policies/index.html | 4 ++-- registration/policies/index.html | 4 ++-- registration/registry-dsl/index.html | 4 ++-- release-notes/index.html | 4 ++-- resolving/get-a-service-by-plugin-type-and-name/index.html | 4 ++-- resolving/get-a-service-by-plugintype/index.html | 4 ++-- resolving/get-all-services-by-plugin-type/index.html | 4 ++-- resolving/index.html | 4 ++-- resolving/passing-arguments-at-runtime/index.html | 4 ++-- resolving/requesting-a-concrete-type/index.html | 4 ++-- .../index.html | 4 ++-- .../try-getting-an-optional-service-by-plugin-type/index.html | 4 ++-- roadmap/index.html | 4 ++-- setter-injection/index.html | 4 ++-- software-design-concepts/index.html | 4 ++-- the-container/auto-wiring/index.html | 4 ++-- the-container/disposing/index.html | 4 ++-- .../forwarding-requests-for-a-type-to-another-type/index.html | 4 ++-- the-container/handling-missing-named-instances/index.html | 4 ++-- the-container/index.html | 4 ++-- the-container/lambdas/index.html | 4 ++-- the-container/lazy-resolution/index.html | 4 ++-- the-container/nested-containers/index.html | 4 ++-- the-container/primitives/index.html | 4 ++-- the-container/profiles-and-child-containers/index.html | 4 ++-- the-container/working-with-enumerable-types/index.html | 4 ++-- .../working-with-the-icontext-at-build-time/index.html | 4 ++-- 62 files changed, 124 insertions(+), 124 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index 45c2b86..21fbdc2 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Best Practices

Previous
Aspect Oriented Programming with StructureMap.DynamicInterception

diff --git a/best-practices/index.html b/best-practices/index.html index f076300..07fdd19 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
History

Previous
Auto-factories

diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index 5a6b2b8..34d28ec 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Using the Container Model

Previous
Environment Tests

diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html index 6ebca53..299aff2 100644 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Build Plans

Previous
Validating Container Configuration

diff --git a/diagnostics/index.html b/diagnostics/index.html index 02befc8..a15e128 100644 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
WhatDoIHave()

Previous
Interpreting Exceptions

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html index 49c0fd1..f206cf0 100644 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Aspect Oriented Programming with StructureMap.DynamicInterception

Previous
Using the Container Model

diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index be27c2b..d14af88 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Type Scanning Diagnostics

Previous
Build Plans

diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index d545c6a..8534266 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Environment Tests

Previous
WhatDoIHave()

diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html index 62dc49a..5b5993f 100644 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Validating Container Configuration

Previous
Diagnostics

diff --git a/documentation/index.html b/documentation/index.html index 632d899..dffecaf 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Roadmap

Previous
StructureMap

diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html index 720b21e..0f0451d 100644 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Auto-factories

Previous
Diagnostics

diff --git a/features/index.html b/features/index.html index b9b779e..6206297 100644 --- a/features/index.html +++ b/features/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Software Design Concepts

Previous
Get StructureMap

diff --git a/generics/index.html b/generics/index.html index 122be94..0bd5fbb 100644 --- a/generics/index.html +++ b/generics/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Interception and Decorators

Previous
Object Lifecycles

diff --git a/get-structuremap/index.html b/get-structuremap/index.html index 99814fe..5f6eb8d 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Features

Previous
Glossary

diff --git a/glossary/index.html b/glossary/index.html index 7b503c5..f741276 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Get StructureMap

Previous
A Gentle Quickstart

diff --git a/history/index.html b/history/index.html index 8b8340f..a55ae0a 100644 --- a/history/index.html +++ b/history/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Release Notes

Previous
Best Practices

diff --git a/instances/index.html b/instances/index.html index 4017357..1d909a1 100644 --- a/instances/index.html +++ b/instances/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Integrating StructureMap into Common .Net Frameworks

Previous
Release Notes

diff --git a/integrations/index.html b/integrations/index.html index 8c8d41f..0836d36 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Previous
Custom Instance Types

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index 114c2be..31e6b73 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Interpreting Exceptions

Previous
Generic Types

diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index 642d2b6..387c4b3 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Diagnostics

Previous
Interception and Decorators

diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index 09709a3..90e2a5d 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Custom Lifecycles

Previous
Supported Lifecycles

diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index 470558d..6cf99c2 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Generic Types

Previous
Configuring Lifecycles

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index e41905b..12e404e 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Supported Lifecycles

Previous
The Container

diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 18602e7..16f47d1 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Configuring Lifecycles

Previous
Object Lifecycles

diff --git a/quickstart/index.html b/quickstart/index.html index 77eeca9..f0be9d8 100644 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Glossary

Previous
Roadmap

diff --git a/registration/attributes/index.html b/registration/attributes/index.html index 0019ba7..af0ad3c 100644 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Resolving Services

Previous
Replace or Clear Out Previous Registrations

diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index d29093d..c62e566 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Working with IConfiguredInstance

Previous
Inline Dependencies

diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index 23d4307..5576737 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
On Missing Family Policies

Previous
Construction Policies

diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index 92eceb6..29eacdf 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Using Attributes for Configuration

Previous
Registering Existing Objects

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index 60233d2..45fe8c8 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Construction Policies

Previous
Auto-Registration and Conventions

diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index c379d83..bc85bff 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Fallback Services

Previous
On Missing Family Policies

diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html index 5da4b01..bf22380 100644 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Replace or Clear Out Previous Registrations

Previous
Fallback Services

diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index 9424b71..e8e787a 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Registering Existing Objects

Previous
Constructor Selection

diff --git a/registration/index.html b/registration/index.html index 8d71c46..7689824 100644 --- a/registration/index.html +++ b/registration/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Registry DSL

Previous
Setter Injection

diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index 97ad4f9..b176071 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Auto-Registration and Conventions

Previous
Registry DSL

diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index 488c16c..ec20884 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Constructor Selection

Previous
Changing Configuration at Runtime

diff --git a/registration/policies/index.html b/registration/policies/index.html index 154e1e0..f0abfb8 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Changing Configuration at Runtime

Previous
Working with IConfiguredInstance

diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index fbbe6e8..7317691 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Inline Dependencies

Previous
Registration

diff --git a/release-notes/index.html b/release-notes/index.html index 424f805..ceb9fc6 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Custom Instance Types

Previous
History

diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html index a5e76c9..d1d6780 100644 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Get all Services by Plugin Type

Previous
Get a Service by PluginType

diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html index 8d3c01e..4273ae0 100644 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Get a Service by Plugin Type and Name

Previous
Resolving Services

diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html index c6466bf..a7fb8ff 100644 --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Try Getting an Optional Service by Plugin Type

Previous
Get a Service by Plugin Type and Name

diff --git a/resolving/index.html b/resolving/index.html index cbaf68c..209cf07 100644 --- a/resolving/index.html +++ b/resolving/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Get a Service by PluginType

Previous
Registration

diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html index 3b136f3..c575bd5 100644 --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Auto Resolving Concrete Types

Previous
Try Geting an Optional Service by Plugin Type and Name

diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index 108686a..24ab808 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
The Container

Previous
Passing Arguments at Runtime

diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html index 5e6b9a3..1c68576 100644 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Passing Arguments at Runtime

Previous
Try Getting an Optional Service by Plugin Type

diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html index 742f27c..6bed72c 100644 --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Try Geting an Optional Service by Plugin Type and Name

Previous
Get all Services by Plugin Type

diff --git a/roadmap/index.html b/roadmap/index.html index 85e797a..192dfbf 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
A Gentle Quickstart

Previous
Documentation

diff --git a/setter-injection/index.html b/setter-injection/index.html index 7f11f58..1cc9840 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Registration

Previous
Software Design Concepts

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index 5ef23a9..22d3038 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Setter Injection

Previous
Features

diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index d889ce8..c837df4 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Building Objects with Lambdas

Previous
The Container

diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index 948da72..9a4f115 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Working with Primitive Types

Previous
Lazy Resolution

diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index 5ea38dd..904161f 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Profiles and Child Containers

Previous
Working with the IContext at Build Time

diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index cd85861..fef38af 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Lazy Resolution

Previous
Working with Enumerable Types

diff --git a/the-container/index.html b/the-container/index.html index 5e537c6..2d3b6ad 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Auto Wiring

Previous
Resolving Services

diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 06c7df0..f7120cd 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Working with the IContext at Build Time

Previous
Auto Wiring

diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html index 72ebf2f..774f7cc 100644 --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
StructureMap and IDisposable

Previous
Handling Missing Named Instances

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index cb4e648..53b70e9 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Working with Enumerable Types

Previous
Profiles and Child Containers

diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index 8e2afc0..41470f2 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Object Lifecycles

Previous
StructureMap and IDisposable

diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index dd890a4..5a40d5e 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Nested Containers (Per Request/Transaction)

Previous
Registering a Single Instance Against Multiple PluginTypes

diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index ff250af..a996a1f 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Handling Missing Named Instances

Previous
Nested Containers (Per Request/Transaction)

diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index d20d188..4484658 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.1 + StructureMap 4.5.3

@@ -74,7 +74,7 @@

-
+

Next
Registering a Single Instance Against Multiple PluginTypes

Previous
Building Objects with Lambdas

From bb4f92b8994bdd553c502b8be4cb1da68a2dd9d2 Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Tue, 16 Jan 2018 07:23:22 -0600 Subject: [PATCH 52/55] Documentation Update for 4.6.0 --- autofactory/index.html | 16 +++---- best-practices/index.html | 4 +- diagnostics/build-plans/index.html | 8 ++-- diagnostics/environment-tests/index.html | 6 +-- diagnostics/index.html | 4 +- diagnostics/type-scanning/index.html | 10 ++-- .../using-the-container-model/index.html | 24 +++++----- .../index.html | 6 +-- diagnostics/whatdoihave/index.html | 12 ++--- documentation/index.html | 4 +- dynamic-interception/index.html | 16 +++---- features/index.html | 4 +- generics/index.html | 48 +++++++++---------- get-structuremap/index.html | 7 +-- glossary/index.html | 24 +++++----- history/index.html | 4 +- instances/index.html | 8 ++-- integrations/index.html | 4 +- interception-and-decorators/index.html | 38 +++++++-------- interpreting-exceptions/index.html | 4 +- .../configuring-lifecycles/index.html | 8 ++-- object-lifecycle/custom-lifecycles/index.html | 8 ++-- object-lifecycle/index.html | 8 ++-- .../supported-lifecycles/index.html | 18 +++---- quickstart/index.html | 10 ++-- registration/attributes/index.html | 16 +++---- .../index.html | 28 +++++------ .../index.html | 6 +-- registration/clear-or-replace/index.html | 8 ++-- registration/configured-instance/index.html | 20 ++++---- registration/constructor-selection/index.html | 18 +++---- registration/existing-objects/index.html | 6 +-- registration/fallback-services/index.html | 8 ++-- registration/index.html | 16 +++---- registration/inline-dependencies/index.html | 24 +++++----- .../on-missing-family-policies/index.html | 18 +++---- registration/policies/index.html | 30 ++++++------ registration/registry-dsl/index.html | 18 +++---- release-notes/index.html | 4 +- .../index.html | 6 +-- .../get-a-service-by-plugintype/index.html | 6 +-- .../index.html | 6 +-- resolving/index.html | 4 +- .../passing-arguments-at-runtime/index.html | 16 +++---- .../requesting-a-concrete-type/index.html | 8 ++-- .../index.html | 6 +-- .../index.html | 16 +++---- roadmap/index.html | 4 +- setter-injection/index.html | 12 ++--- software-design-concepts/index.html | 8 ++-- the-container/auto-wiring/index.html | 10 ++-- the-container/disposing/index.html | 10 ++-- .../index.html | 10 ++-- .../index.html | 18 +++---- the-container/index.html | 4 +- the-container/lambdas/index.html | 8 ++-- the-container/lazy-resolution/index.html | 12 ++--- the-container/nested-containers/index.html | 20 ++++---- the-container/primitives/index.html | 10 ++-- .../profiles-and-child-containers/index.html | 14 +++--- .../working-with-enumerable-types/index.html | 10 ++-- .../index.html | 16 +++---- 62 files changed, 379 insertions(+), 378 deletions(-) mode change 100644 => 100755 autofactory/index.html mode change 100644 => 100755 best-practices/index.html mode change 100644 => 100755 diagnostics/build-plans/index.html mode change 100644 => 100755 diagnostics/environment-tests/index.html mode change 100644 => 100755 diagnostics/index.html mode change 100644 => 100755 diagnostics/type-scanning/index.html mode change 100644 => 100755 diagnostics/using-the-container-model/index.html mode change 100644 => 100755 diagnostics/validating-container-configuration/index.html mode change 100644 => 100755 diagnostics/whatdoihave/index.html mode change 100644 => 100755 documentation/index.html mode change 100644 => 100755 dynamic-interception/index.html mode change 100644 => 100755 features/index.html mode change 100644 => 100755 generics/index.html mode change 100644 => 100755 get-structuremap/index.html mode change 100644 => 100755 glossary/index.html mode change 100644 => 100755 history/index.html mode change 100644 => 100755 instances/index.html mode change 100644 => 100755 integrations/index.html mode change 100644 => 100755 interception-and-decorators/index.html mode change 100644 => 100755 interpreting-exceptions/index.html mode change 100644 => 100755 object-lifecycle/configuring-lifecycles/index.html mode change 100644 => 100755 object-lifecycle/custom-lifecycles/index.html mode change 100644 => 100755 object-lifecycle/index.html mode change 100644 => 100755 object-lifecycle/supported-lifecycles/index.html mode change 100644 => 100755 quickstart/index.html mode change 100644 => 100755 registration/attributes/index.html mode change 100644 => 100755 registration/auto-registration-and-conventions/index.html mode change 100644 => 100755 registration/changing-configuration-at-runtime/index.html mode change 100644 => 100755 registration/clear-or-replace/index.html mode change 100644 => 100755 registration/configured-instance/index.html mode change 100644 => 100755 registration/constructor-selection/index.html mode change 100644 => 100755 registration/existing-objects/index.html mode change 100644 => 100755 registration/fallback-services/index.html mode change 100644 => 100755 registration/index.html mode change 100644 => 100755 registration/inline-dependencies/index.html mode change 100644 => 100755 registration/on-missing-family-policies/index.html mode change 100644 => 100755 registration/policies/index.html mode change 100644 => 100755 registration/registry-dsl/index.html mode change 100644 => 100755 release-notes/index.html mode change 100644 => 100755 resolving/get-a-service-by-plugin-type-and-name/index.html mode change 100644 => 100755 resolving/get-a-service-by-plugintype/index.html mode change 100644 => 100755 resolving/get-all-services-by-plugin-type/index.html mode change 100644 => 100755 resolving/index.html mode change 100644 => 100755 resolving/passing-arguments-at-runtime/index.html mode change 100644 => 100755 resolving/requesting-a-concrete-type/index.html mode change 100644 => 100755 resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html mode change 100644 => 100755 resolving/try-getting-an-optional-service-by-plugin-type/index.html mode change 100644 => 100755 roadmap/index.html mode change 100644 => 100755 setter-injection/index.html mode change 100644 => 100755 software-design-concepts/index.html mode change 100644 => 100755 the-container/auto-wiring/index.html mode change 100644 => 100755 the-container/disposing/index.html mode change 100644 => 100755 the-container/forwarding-requests-for-a-type-to-another-type/index.html mode change 100644 => 100755 the-container/handling-missing-named-instances/index.html mode change 100644 => 100755 the-container/index.html mode change 100644 => 100755 the-container/lambdas/index.html mode change 100644 => 100755 the-container/lazy-resolution/index.html mode change 100644 => 100755 the-container/nested-containers/index.html mode change 100644 => 100755 the-container/primitives/index.html mode change 100644 => 100755 the-container/profiles-and-child-containers/index.html mode change 100644 => 100755 the-container/working-with-enumerable-types/index.html mode change 100644 => 100755 the-container/working-with-the-icontext-at-build-time/index.html diff --git a/autofactory/index.html b/autofactory/index.html old mode 100644 new mode 100755 index 21fbdc2..ffdeb0a --- a/autofactory/index.html +++ b/autofactory/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Best Practices

Previous
Aspect Oriented Programming with StructureMap.DynamicInterception

@@ -91,13 +91,13 @@
Auto-factories You need to install StructureMap.Autofactory package to use the functionality described below.

When you need to implement Abstract Factory, StructureMap offers a way to do it for you. Let's say you have
-
public interface IDummyService { string Name { get; } }
+
public interface IDummyService { string Name { get; } }
with implementation -
public class DummyService : IDummyService { public string Name { get; set; } }
+
public class DummyService : IDummyService { public string Name { get; set; } }

Now you declare an interface for your factory:
-
public interface ISimpleDummyFactory { IDummyService CreateDummyService(); }
+
public interface ISimpleDummyFactory { IDummyService CreateDummyService(); }

All you need to do is to call CreateFactory when configuring the container as shown below:
-
[Fact] public void Simple_factory_creation() { var container = new Container(cfg => { cfg.For<IDummyService>().Use<DummyService>(); cfg.For<ISimpleDummyFactory>().CreateFactory(); }); var factory = container.GetInstance<ISimpleDummyFactory>(); var component = factory.CreateDummyService(); component.ShouldNotBeNull(); component.ShouldBeOfType<DummyService>(); }
+
[Fact] public void Simple_factory_creation() { var container = new Container(cfg => { cfg.For<IDummyService>().Use<DummyService>(); cfg.For<ISimpleDummyFactory>().CreateFactory(); }); var factory = container.GetInstance<ISimpleDummyFactory>(); var component = factory.CreateDummyService(); component.ShouldNotBeNull(); component.ShouldBeOfType<DummyService>(); }

Default convention

As for now, Auto-factories support two types of methods:

@@ -112,13 +112,13 @@
Default convention

Any other method that has the return type (i.e. doesn't return void), is treated as a factory method. In addition, if the method name starts with GetNamed, the first method argument is used as the name for the named instance. All the rest arguments are passed as explicit arguments to the implementation constructor.

It is much easier to see it on an example:
-
public interface IDummyFactory { // This method will return the names of all registered implementations of TService. IList<string> GetNames<TService>(); // This method will just create the default IDummyService implementation. IDummyService CreateDummyService(); // This method will just create the default IDummyService implementation and pass namePart1 and namePart2 as // dependencies. IDummyService CreateDummyService(string namePart1, string namePart2); // This method will create IDummyService implementation with serviceName name. IDummyService GetNamedDummyService(string serviceName, string namePart1, string namePart2); // Generic methods are also allowed as factory methods. TService CreateService<TService>(); // Something that is common for event-sourcing implementations. IHandler<TMessage> CreateHandler<TMessage>(); }
+
public interface IDummyFactory { // This method will return the names of all registered implementations of TService. IList<string> GetNames<TService>(); // This method will just create the default IDummyService implementation. IDummyService CreateDummyService(); // This method will just create the default IDummyService implementation and pass namePart1 and namePart2 as // dependencies. IDummyService CreateDummyService(string namePart1, string namePart2); // This method will create IDummyService implementation with serviceName name. IDummyService GetNamedDummyService(string serviceName, string namePart1, string namePart2); // Generic methods are also allowed as factory methods. TService CreateService<TService>(); // Something that is common for event-sourcing implementations. IHandler<TMessage> CreateHandler<TMessage>(); }

Custom convention

If the default convention doesn't work for you, you can create and use your custom convention. All you need is to implement IAutoFactoryConventionProvider and use the corresponding CreateFactory overload. IAutoFactoryConventionProvider has a single method to implement:

IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);

IAutoFactoryMethodDefinition is defined as follows:
-
/// <summary> /// Describes how AutoFactory should treat the specific method declared in an abstract factory interface. /// </summary> public interface IAutoFactoryMethodDefinition { /// <summary> /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values. /// </summary> AutoFactoryMethodType MethodType { get; } /// <summary> /// The instance type to create. /// </summary> Type InstanceType { get; } /// <summary> /// The instance name if available. /// </summary> string InstanceName { get; } /// <summary> /// Explicit arguments if available. /// </summary> ExplicitArguments ExplicitArguments { get; } }
+
/// <summary> /// Describes how AutoFactory should treat the specific method declared in an abstract factory interface. /// </summary> public interface IAutoFactoryMethodDefinition { /// <summary> /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values. /// </summary> AutoFactoryMethodType MethodType { get; } /// <summary> /// The instance type to create. /// </summary> Type InstanceType { get; } /// <summary> /// The instance name if available. /// </summary> string InstanceName { get; } /// <summary> /// Explicit arguments if available. /// </summary> ExplicitArguments ExplicitArguments { get; } }

diff --git a/best-practices/index.html b/best-practices/index.html old mode 100644 new mode 100755 index 07fdd19..23d04cb --- a/best-practices/index.html +++ b/best-practices/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
History

Previous
Auto-factories

diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html old mode 100644 new mode 100755 index 34d28ec..cf5b6da --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Using the Container Model

Previous
Environment Tests

@@ -101,7 +101,7 @@
Build Plans var container = Container.For<VisualizationRegistry>(); var description = container.Model.For<IDevice>().Default .DescribeBuildPlan(); Debug.WriteLine(description); +
var container = Container.For<VisualizationRegistry>(); var description = container.Model.For<IDevice>().Default .DescribeBuildPlan(); Debug.WriteLine(description);

The result of the code above is this textual representation of how StructureMap will build and/or resolve the default of the IDevice plugin type:

PluginType: StructureMap.Testing.Diagnostics.IDevice @@ -116,7 +116,7 @@
Build Plans var description = theContainer.Model.For<IDevice>() .Find("A") .DescribeBuildPlan();
+
var description = theContainer.Model.For<IDevice>() .Find("A") .DescribeBuildPlan();

See Using the Container Model for more information on using Container.Model.

You can find many more examples of finding the build plan description from Container.Model from the unit tests in the StructureMap codebase.
diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html old mode 100644 new mode 100755 index 299aff2..189b60c --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Build Plans

Previous
Validating Container Configuration

@@ -98,7 +98,7 @@
Environment Tests [ValidationMethod] attribute as shown below:
-
public class Database : IDatabase { [ValidationMethod] public void TryToConnect() { // try to open a connection to the configured // database connection string // throw an exception if the database cannot // be reached } }
+
public class Database : IDatabase { [ValidationMethod] public void TryToConnect() { // try to open a connection to the configured // database connection string // throw an exception if the database cannot // be reached } }

Used in conjunction with StructureMap's ability to validate a container, you can use this technique to quickly support environment tests embedded into your system code.

diff --git a/diagnostics/index.html b/diagnostics/index.html old mode 100644 new mode 100755 index a15e128..4891836 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
WhatDoIHave()

Previous
Interpreting Exceptions

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100644 new mode 100755 index f206cf0..ae46488 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Aspect Oriented Programming with StructureMap.DynamicInterception

Previous
Using the Container Model

@@ -93,15 +93,15 @@
Type Scanning Diagnostics
Assert for Assembly Loading Failures

At its root, most type scanning and auto-registration schemes in .Net frameworks rely on the Assembly.GetExportedTypes() method. Unfortunately, that method can be brittle and fail whenever any dependency of that Assembly cannot be loaded into the current process, even if your application has no need for that dependency. In StructureMap 3.* and before, that loading exception was essentially swallowed and lost. In StructureMap 4 and above, you can use this method to assert the presence of any assembly load exceptions during type scanning:
-
TypeRepository.AssertNoTypeScanningFailures();
+
TypeRepository.AssertNoTypeScanningFailures();

The method above will throw an exception listing all the Assembly's that failed during the call to GetExportedTypes() only if there were any failures. Use this method during your application bootstrapping if you want it to fail fast with any type scanning problems.

What did StructureMap scan?

Confusion of type scanning has been a constant problem with StructureMap usage over the years -- especially if users are trying to dynamically load assemblies from the file system for extensibility. In order to see into what StructureMap has done with type scanning, 4.0 introduces the Container.WhatDidIScan() method.

Let's say that you have a Container that is set up with at least two different scanning operations like this sample from the StructureMap unit tests:
-
var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.WithDefaultConventions(); x.RegisterConcreteTypesAgainstTheFirstInterface(); x.SingleImplementationsOfInterface(); }); _.Scan(x => { // Give your scanning operation a descriptive name // to help the diagnostics to be more useful x.Description = "Second Scanner"; x.AssembliesFromApplicationBaseDirectory(assem => assem.FullName.Contains("Widget")); x.ConnectImplementationsToTypesClosing(typeof(IService<>)); x.AddAllTypesOf<IWidget>(); }); }); Debug.WriteLine(container.WhatDidIScan());
+
var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.WithDefaultConventions(); x.RegisterConcreteTypesAgainstTheFirstInterface(); x.SingleImplementationsOfInterface(); }); _.Scan(x => { // Give your scanning operation a descriptive name // to help the diagnostics to be more useful x.Description = "Second Scanner"; x.AssembliesFromApplicationBaseDirectory(assem => assem.FullName.Contains("Widget")); x.ConnectImplementationsToTypesClosing(typeof(IService<>)); x.AddAllTypesOf<IWidget>(); }); }); Debug.WriteLine(container.WhatDidIScan());

The resulting textual report is shown below:

Sorry for the formatting and color of the text, but the markdown engine does not like the textual report
-
/* All Scanners ================================================================ Scanner #1 Assemblies ---------- * StructureMap.Testing, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null Conventions -------- * Default I[Name]/[Name] registration convention * Register all concrete types against the first interface (if any) that they implement * Register any single implementation of any interface against that interface Second Scanner Assemblies ---------- * StructureMap.Testing.GenericWidgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget2, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget3, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget4, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget5, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null Conventions -------- * Connect all implementations of open generic type IService<T> * Find and register all types implementing StructureMap.Testing.Widget.IWidget */
+
/* All Scanners ================================================================ Scanner #1 Assemblies ---------- * StructureMap.Testing, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null Conventions -------- * Default I[Name]/[Name] registration convention * Register all concrete types against the first interface (if any) that they implement * Register any single implementation of any interface against that interface Second Scanner Assemblies ---------- * StructureMap.Testing.GenericWidgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget2, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget3, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget4, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null * StructureMap.Testing.Widget5, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null Conventions -------- * Connect all implementations of open generic type IService<T> * Find and register all types implementing StructureMap.Testing.Widget.IWidget */

The textual report will show:

All the scanning operations (calls to Registry.Scan()) with a descriptive name, either one supplied by you or the Registry type and an order number.
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html old mode 100644 new mode 100755 index d14af88..f46a21f --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Type Scanning Diagnostics

Previous
Build Plans

@@ -93,40 +93,40 @@
Using the Container Model Querying for Plugin Types

The WhatDoIHave() mechanism works by just iterating over the Container.Model.PluginTypes collection as shown below:
-
container.Model.PluginTypes.Where(x => x.PluginType.Assembly == Assembly.GetExecutingAssembly()) .Each(pluginType => Debug.WriteLine(pluginType.PluginType));
+
container.Model.PluginTypes.Where(x => x.PluginType.Assembly == Assembly.GetExecutingAssembly()) .Each(pluginType => Debug.WriteLine(pluginType.PluginType));

Working with a Plugin Type

The IPluginTypeConfiguration interface allows you to query and manipulate all the configured Instance's for a given plugin type.

See the entire IPluginTypeConfiguration interface here.

Finding the Default for a Plugin Type

To simply find out what the default concrete type would be for a requested plugin type, use one of these two methods:
-
// Finding the concrete type of the default // IDevice service container.Model.DefaultTypeFor<IDevice>() .ShouldBe(typeof(DefaultDevice)); // Find the configuration model for the default // IDevice service container.Model.For<IDevice>().Default .ReturnedType.ShouldBe(typeof(DefaultDevice));
+
// Finding the concrete type of the default // IDevice service container.Model.DefaultTypeFor<IDevice>() .ShouldBe(typeof(DefaultDevice)); // Find the configuration model for the default // IDevice service container.Model.For<IDevice>().Default .ReturnedType.ShouldBe(typeof(DefaultDevice));

Finding an Instance by Type and Name

Use this syntax to find information about an Instance in a given plugin type and name:
-
var redRule = container.Model.Find<Rule>("Red");
+
var redRule = container.Model.Find<Rule>("Red");

All Instances for a Plugin Type

This sample shows how you could iterate or query over all the registered instances for a single plugin type:
-
container.Model.For<Rule>().Instances.Each(i => { Debug.WriteLine(i.Instance.Description); });
+
container.Model.For<Rule>().Instances.Each(i => { Debug.WriteLine(i.Instance.Description); });

Ejecting Services and/or Configuration

It's possible to remove singleton scoped objects from a running Container to force a new one to be built or even to completely remove configured instance objects and configuration permanently from a Container. This is typically only used in automated testing to flush static state between tests.

To remove and dispose previously built singleton scoped objects from a Container, use this code:
-
// ONLY ejects any built object for this Instance from the SingletonThing // cache container.Model.For<IDevice>().Default.EjectObject();
+
// ONLY ejects any built object for this Instance from the SingletonThing // cache container.Model.For<IDevice>().Default.EjectObject();

To completely eject any singletons and permanently remove all related configuration, use this code:
-
// Removes all configurations and objects already built as singletons // related to types in the current Assembly container.Model.EjectAndRemoveTypes(type => type.Assembly == Assembly.GetExecutingAssembly()); // Removes all configurations and objects already built as singletons // that were registered to IDevice container.Model.EjectAndRemove(typeof(IDevice));
+
// Removes all configurations and objects already built as singletons // related to types in the current Assembly container.Model.EjectAndRemoveTypes(type => type.Assembly == Assembly.GetExecutingAssembly()); // Removes all configurations and objects already built as singletons // that were registered to IDevice container.Model.EjectAndRemove(typeof(IDevice));

Testing for Registrations

To troubleshoot or automate testing of Container configuration, you can use code like the sample below to test for the presence of expected configurations:
-
// Is there a default instance for IDevice? container.Model.HasDefaultImplementationFor<IDevice>().ShouldBeTrue(); // Are there any configured instances for IDevice? container.Model.HasImplementationsFor<IDevice>().ShouldBeTrue();
+
// Is there a default instance for IDevice? container.Model.HasDefaultImplementationFor<IDevice>().ShouldBeTrue(); // Are there any configured instances for IDevice? container.Model.HasImplementationsFor<IDevice>().ShouldBeTrue();

Finding all Possible Implementors of an Interface

Forget about what types are registered for whatever plugin types and consider this, what if you have an interface called IStartable that just denotes objects that will need to be activated after the container is bootstrapped?

If our interface is this below:
-
public interface IStartable { bool WasStarted { get; } void Start(); }
+
public interface IStartable { bool WasStarted { get; } void Start(); }

We could walk through the entire StructureMap model and find every registered instance that implements this interface, create each, and call the Start() method like in this code below:
-
var allStartables = container.Model.GetAllPossible<IStartable>(); allStartables.ToArray() .Each(x => x.Start());
+
var allStartables = container.Model.GetAllPossible<IStartable>(); allStartables.ToArray() .Each(x => x.Start());

I've also used this mechanism in automated testing to reach out to all singleton services that may have state to clear out their data between tests.

Working with Individual Instances

You can manipulate an individual instance in several ways:
-
// First, find the model for a single Instance var instance = container.Model.For<IDevice>().Default; // build or resolve an object for this Instance cast to // the type specified to the Get() method instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>(); // if the instance is configured as a SingletonThing, test // if the SingletonThing object has already been created var hasSingletonBeenCreated = instance.ObjectHasBeenCreated(); if (hasSingletonBeenCreated) { // remove the SingletonThing object from the cache so that // StructureMap will be forced to rebuild this object instance.EjectObject(); } // test the lifecycle of this instance instance.Lifecycle.ShouldBeOfType<SingletonLifecycle>(); // Visualize the build plan no more than 3 levels deep Debug.WriteLine(instance.DescribeBuildPlan(3)); // Get at the underlying Instance model that StructureMap itself // uses. Be cautious using this. var rawModel = instance.Instance;
+
// First, find the model for a single Instance var instance = container.Model.For<IDevice>().Default; // build or resolve an object for this Instance cast to // the type specified to the Get() method instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>(); // if the instance is configured as a SingletonThing, test // if the SingletonThing object has already been created var hasSingletonBeenCreated = instance.ObjectHasBeenCreated(); if (hasSingletonBeenCreated) { // remove the SingletonThing object from the cache so that // StructureMap will be forced to rebuild this object instance.EjectObject(); } // test the lifecycle of this instance instance.Lifecycle.ShouldBeOfType<SingletonLifecycle>(); // Visualize the build plan no more than 3 levels deep Debug.WriteLine(instance.DescribeBuildPlan(3)); // Get at the underlying Instance model that StructureMap itself // uses. Be cautious using this. var rawModel = instance.Instance;

diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html old mode 100644 new mode 100755 index 8534266..f5d8ee4 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Environment Tests

Previous
WhatDoIHave()

@@ -91,7 +91,7 @@
Validating Container Configuration container.AssertConfigurationIsValid(); +
container.AssertConfigurationIsValid();

Running this method will walk over every single registration in your Container and:

Try to create a build plan for that Instance that will flush out any problems with missing dependencies or invalid inline configuration
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html old mode 100644 new mode 100755 index 5b5993f..e9bbbb8 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Validating Container Configuration

Previous
Diagnostics

@@ -91,18 +91,18 @@
WhatDoIHave() var container = new Container(); var report = container.WhatDoIHave(); Debug.WriteLine(report); +
var container = new Container(); var report = container.WhatDoIHave(); Debug.WriteLine(report);

If you're familiar with WhatDoIHave() from earlier versions of StructureMap, the usage has been enhanced for 3.0 to allow you to filter the results for easier usage. The format was also tweaked extensively to (hopefully) improve the usability of this feature.

Enough talk, say you have a Container with this configuration:
-
var container = new Container(x => { x.For<IEngine>().Use<Hemi>().Named("The Hemi"); x.For<IEngine>().Add<VEight>().Singleton().Named("V8"); x.For<IEngine>().Add<FourFiftyFour>().AlwaysUnique(); x.For<IEngine>().Add<StraightSix>().LifecycleIs<ThreadLocalStorageLifecycle>(); x.For<IEngine>().Add(() => new Rotary()).Named("Rotary"); x.For<IEngine>().Add(c => c.GetInstance<PluginElectric>()); x.For<IEngine>().Add(new InlineFour()); x.For<IEngine>().UseIfNone<VTwelve>(); x.For<IEngine>().MissingNamedInstanceIs.ConstructedBy(c => new NamedEngine(c.RequestedName)); });
+
var container = new Container(x => { x.For<IEngine>().Use<Hemi>().Named("The Hemi"); x.For<IEngine>().Add<VEight>().Singleton().Named("V8"); x.For<IEngine>().Add<FourFiftyFour>().AlwaysUnique(); x.For<IEngine>().Add<StraightSix>().LifecycleIs<ThreadLocalStorageLifecycle>(); x.For<IEngine>().Add(() => new Rotary()).Named("Rotary"); x.For<IEngine>().Add(c => c.GetInstance<PluginElectric>()); x.For<IEngine>().Add(new InlineFour()); x.For<IEngine>().UseIfNone<VTwelve>(); x.For<IEngine>().MissingNamedInstanceIs.ConstructedBy(c => new NamedEngine(c.RequestedName)); });

If you were to run the code below against this Container:
-
Debug.WriteLine(container.WhatDoIHave());
+
Debug.WriteLine(container.WhatDoIHave());

you would get the output shown in this gist.

If you're curious, all the raw code for this example is in here.

Filtering WhatDoIHave()

Filtering the WhatDoIHave() results can be done in these ways:
-
var container = new Container(); // Filter by the Assembly of the Plugin Type var byAssembly = container.WhatDoIHave(assembly: typeof(IWidget).GetAssembly()); // Only report on the specified Plugin Type var byPluginType = container.WhatDoIHave(typeof(IWidget)); // Filter to Plugin Type's in the named namespace // The 'IsInNamespace' test will include child namespaces var byNamespace = container.WhatDoIHave(@namespace: "StructureMap.Testing.Widget"); // Filter by a case insensitive string.Contains() match // against the Plugin Type name var byType = container.WhatDoIHave(typeName: "Widget");
+
var container = new Container(); // Filter by the Assembly of the Plugin Type var byAssembly = container.WhatDoIHave(assembly: typeof(IWidget).GetAssembly()); // Only report on the specified Plugin Type var byPluginType = container.WhatDoIHave(typeof(IWidget)); // Filter to Plugin Type's in the named namespace // The 'IsInNamespace' test will include child namespaces var byNamespace = container.WhatDoIHave(@namespace: "StructureMap.Testing.Widget"); // Filter by a case insensitive string.Contains() match // against the Plugin Type name var byType = container.WhatDoIHave(typeName: "Widget");

diff --git a/documentation/index.html b/documentation/index.html old mode 100644 new mode 100755 index dffecaf..97a8cef --- a/documentation/index.html +++ b/documentation/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Roadmap

Previous
StructureMap

diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html old mode 100644 new mode 100755 index 0f0451d..d0c2a00 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Auto-factories

Previous
Diagnostics

@@ -93,20 +93,20 @@
Aspect Oriented Programming with StructureMap.DynamicInterception Interception and Decorators page describes how to use "static" interception of created instances, mainly allowing to apply the Decorator pattern. It is "static" in a sense that you need know what interfaces you want to implement and you need to create decorators implementing all appropriate interfaces. It is almost always fine, but there are cases when you want to implement the same decorating logic for many interfaces which easily breaks the DRY principle. The most common examples are cross-cutting concerns such as logging, caching etc.

Dynamic proxy interceptor

Let's see it in action. Let's say we have
-
public interface IMathService { int GetSquareRoot(int value); Task<int> GetSquareRootAsync(int value); }
+
public interface IMathService { int GetSquareRoot(int value); Task<int> GetSquareRootAsync(int value); }
with implementation -
private class MathService : IMathService { public int GetSquareRoot(int value) { return (int)Math.Sqrt(value); } public async Task<int> GetSquareRootAsync(int value) { await Task.Yield(); return (int)Math.Sqrt(value); } }
+
private class MathService : IMathService { public int GetSquareRoot(int value) { return (int)Math.Sqrt(value); } public async Task<int> GetSquareRootAsync(int value) { await Task.Yield(); return (int)Math.Sqrt(value); } }

If you need to apply dynamic interception to IMathService, first you implement either ISyncInterceptionBehavior or IAsyncInterceptionBehavior depending if your interception code needs to use async/await or not. For demonstration purposes, let's have
-
private class NegatingInterceptor : ISyncInterceptionBehavior { public IMethodInvocationResult Intercept(ISyncMethodInvocation methodInvocation) { var argument = methodInvocation.GetArgument("value"); var argumentValue = (int)argument.Value; if (argumentValue < 0) { argument.Value = -argumentValue; } return methodInvocation.InvokeNext(); } }
+
private class NegatingInterceptor : ISyncInterceptionBehavior { public IMethodInvocationResult Intercept(ISyncMethodInvocation methodInvocation) { var argument = methodInvocation.GetArgument("value"); var argumentValue = (int)argument.Value; if (argumentValue < 0) { argument.Value = -argumentValue; } return methodInvocation.InvokeNext(); } }
and -
private class AsyncCachingInterceptor : IAsyncInterceptionBehavior { private static readonly IDictionary<int, int> PrecalculatedValues = new Dictionary<int, int> { { 16, 4444 }, { 10, 5555 }, }; public async Task<IMethodInvocationResult> InterceptAsync(IAsyncMethodInvocation methodInvocation) { var argument = methodInvocation.GetArgument("value"); var argumentValue = (int)argument.Value; int result; return PrecalculatedValues.TryGetValue(argumentValue, out result) ? methodInvocation.CreateResult(result) : await methodInvocation.InvokeNextAsync().ConfigureAwait(false); } }
+
private class AsyncCachingInterceptor : IAsyncInterceptionBehavior { private static readonly IDictionary<int, int> PrecalculatedValues = new Dictionary<int, int> { { 16, 4444 }, { 10, 5555 }, }; public async Task<IMethodInvocationResult> InterceptAsync(IAsyncMethodInvocation methodInvocation) { var argument = methodInvocation.GetArgument("value"); var argumentValue = (int)argument.Value; int result; return PrecalculatedValues.TryGetValue(argumentValue, out result) ? methodInvocation.CreateResult(result) : await methodInvocation.InvokeNextAsync().ConfigureAwait(false); } }

Finally, we register interceptors with help of DynamicProxyInterceptor as follows:
-
[Theory] [InlineData(111, 10)] [InlineData(16, 4444)] [InlineData(-16, 4444)] public void CallSyncMethodWithSyncThenAsyncInterceptors(int value, int expectedResult) { var container = new Container(x => { x.For<IMathService>().Use<MathService>() .InterceptWith(new DynamicProxyInterceptor<IMathService>(new IInterceptionBehavior[] { new NegatingInterceptor(), new AsyncCachingInterceptor() })); }); var service = container.GetInstance<IMathService>(); service.GetSquareRoot(value).ShouldBe(expectedResult); }
+
[Theory] [InlineData(111, 10)] [InlineData(16, 4444)] [InlineData(-16, 4444)] public void CallSyncMethodWithSyncThenAsyncInterceptors(int value, int expectedResult) { var container = new Container(x => { x.For<IMathService>().Use<MathService>() .InterceptWith(new DynamicProxyInterceptor<IMathService>(new IInterceptionBehavior[] { new NegatingInterceptor(), new AsyncCachingInterceptor() })); }); var service = container.GetInstance<IMathService>(); service.GetSquareRoot(value).ShouldBe(expectedResult); }

The idea is simple - for each method call of the intercepted instance, Intercept/InterceptAsync is called passing an IMethodInvocation instance allowing to get information about the intercepted method and modify arguments if needed before passing to the next interceptor. You have a choice to call the next interceptor in the chain via methodInvocation.InvokeNext/methodInvocation.InvokeNextAsync. Alternatively, you can return the result directly from the interceptor via methodInvocation.CreateResult.

Finally, you can also throw exceptions from interceptors either directly or by returning methodInvocation.CreateExceptionResult.

Dynamic proxy policy

As described on the Interception and Decorators page, you can create an interception policy if you need to apply interceptors to many types by certain filter. DynamicProxyInterceptorPolicy makes it easier when it comes to dynamic interceptors. See the example below:
-
[Fact] public void UseInterceptionPolicy() { var container = new Container(x => { x.Policies.Interceptors(new DynamicProxyInterceptorPolicy(new NegatingInterceptor(), new CachingInterceptor())); x.For<IMathService>().Use<MathService>(); }); var service = container.GetInstance<IMathService>(); service.GetSquareRoot(-10).ShouldBe(5555); }
+
[Fact] public void UseInterceptionPolicy() { var container = new Container(x => { x.Policies.Interceptors(new DynamicProxyInterceptorPolicy(new NegatingInterceptor(), new CachingInterceptor())); x.For<IMathService>().Use<MathService>(); }); var service = container.GetInstance<IMathService>(); service.GetSquareRoot(-10).ShouldBe(5555); }

Check DynamicProxyInterceptorPolicy constructors to find the most suitable overload for your purposes.

diff --git a/features/index.html b/features/index.html old mode 100644 new mode 100755 index 6206297..e202b49 --- a/features/index.html +++ b/features/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Software Design Concepts

Previous
Get StructureMap

diff --git a/generics/index.html b/generics/index.html old mode 100644 new mode 100755 index 0bd5fbb..aac4ce6 --- a/generics/index.html +++ b/generics/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Interception and Decorators

Previous
Object Lifecycles

@@ -98,25 +98,25 @@
Example 1: Visualizing an Activit this topic to find and apply the correct HTML rendering strategy for each type of log object in an activity stream.

Given a log object, we wanted to look up the right visualizer strategy to render that type of log object to html on the server side.

To start, we had an interface like this one that we were going to use to get the HTML for each log object:
-
public interface ILogVisualizer { // If we already know what the type of log we have string ToHtml<TLog>(TLog log); // If we only know that we have a log object string ToHtml(object log); }
+
public interface ILogVisualizer { // If we already know what the type of log we have string ToHtml<TLog>(TLog log); // If we only know that we have a log object string ToHtml(object log); }

So for an example, if we already knew that we had an IssueCreated object, we should be able to use StructureMap like this:
-
// Just setting up a Container and ILogVisualizer var container = Container.For<VisualizationRegistry>(); var visualizer = container.GetInstance<ILogVisualizer>(); // If I have an IssueCreated lob object... var created = new IssueCreated(); // I can get the html representation: var html = visualizer.ToHtml(created);
+
// Just setting up a Container and ILogVisualizer var container = Container.For<VisualizationRegistry>(); var visualizer = container.GetInstance<ILogVisualizer>(); // If I have an IssueCreated lob object... var created = new IssueCreated(); // I can get the html representation: var html = visualizer.ToHtml(created);

If we had an array of log objects, but we do not already know the specific types, we can still use the more generic ToHtml(object) method like this:
-
var logs = new object[] { new IssueCreated(), new TaskAssigned(), new Comment(), new IssueResolved() }; // SAMPLE: using-visualizer-knowning-the-type // Just setting up a Container and ILogVisualizer var container = Container.For<VisualizationRegistry>(); var visualizer = container.GetInstance<ILogVisualizer>(); var items = logs.Select(visualizer.ToHtml); var html = string.Join("<hr />", items);
+
var logs = new object[] { new IssueCreated(), new TaskAssigned(), new Comment(), new IssueResolved() }; // SAMPLE: using-visualizer-knowning-the-type // Just setting up a Container and ILogVisualizer var container = Container.For<VisualizationRegistry>(); var visualizer = container.GetInstance<ILogVisualizer>(); var items = logs.Select(visualizer.ToHtml); var html = string.Join("<hr />", items);

The next step is to create a way to identify the visualization strategy for a single type of log object. We certainly could have done this with a giant switch statement, but we wanted some extensibility for new types of activity log objects and even customer specific log types that would never, ever be in the main codebase. We settled on an interface like the one shown below that would be responsible for rendering a particular type of log object ("T" in the type):
-
public interface IVisualizer<TLog> { string ToHtml(TLog log); }
+
public interface IVisualizer<TLog> { string ToHtml(TLog log); }

Inside of the concrete implementation of ILogVisualizer we need to be able to pull out and use the correct IVisualizer<T> strategy for a log type. We of course used a StructureMap Container to do the resolution and lookup, so now we also need to be able to register all the log visualization strategies in some easy way. On top of that, many of the log types were simple and could just as easily be rendered with a simple html strategy like this class:
-
public class DefaultVisualizer<TLog> : IVisualizer<TLog> { public string ToHtml(TLog log) { return string.Format("<div>{0}</div>", log); } }
+
public class DefaultVisualizer<TLog> : IVisualizer<TLog> { public string ToHtml(TLog log) { return string.Format("<div>{0}</div>", log); } }

Inside of our StructureMap usage, if we don't have a specific visualizer for a given log type, we'd just like to fallback to the default visualizer and proceed.

Alright, now that we have a real world problem, let's proceed to the mechanics of the solution.

Registering Open Generic Types

Let's say to begin with all we want to do is to always use the DefaultVisualizer for each log type. We can do that with code like this below:
-
[Fact] public void register_open_generic_type() { var container = new Container(_ => { _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>)); }); Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization")); container.GetInstance<IVisualizer<IssueCreated>>() .ShouldBeOfType<DefaultVisualizer<IssueCreated>>(); Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization")); container.GetInstance<IVisualizer<IssueResolved>>() .ShouldBeOfType<DefaultVisualizer<IssueResolved>>(); }
+
[Fact] public void register_open_generic_type() { var container = new Container(_ => { _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>)); }); Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization")); container.GetInstance<IVisualizer<IssueCreated>>() .ShouldBeOfType<DefaultVisualizer<IssueCreated>>(); Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization")); container.GetInstance<IVisualizer<IssueResolved>>() .ShouldBeOfType<DefaultVisualizer<IssueResolved>>(); }

With the configuration above, there are no specific registrations for IVisualizer<IssueCreated>. At the first request for that interface, StructureMap will run through its "missing family policies", one of which is to try to find registrations for an open generic type that could be closed to make a valid registration for the requested type. In the case above, @@ -147,20 +147,20 @@
Generic Registrations and D users to register a "fallback" registration otherwise. In the case of the visualization, some types of log objects may justify some special HTML rendering while others can happily be rendered with the default visualization strategy. This behavior is demonstrated by the following code sample:
-
[Fact] public void generic_defaults() { var container = new Container(_ => { // The default visualizer just like we did above _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>)); // Register a specific visualizer for IssueCreated _.For<IVisualizer<IssueCreated>>().Use<IssueCreatedVisualizer>(); }); // We have a specific visualizer for IssueCreated container.GetInstance<IVisualizer<IssueCreated>>() .ShouldBeOfType<IssueCreatedVisualizer>(); // We do not have any special visualizer for TaskAssigned, // so fall back to the DefaultVisualizer<T> container.GetInstance<IVisualizer<TaskAssigned>>() .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>(); }
+
[Fact] public void generic_defaults() { var container = new Container(_ => { // The default visualizer just like we did above _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>)); // Register a specific visualizer for IssueCreated _.For<IVisualizer<IssueCreated>>().Use<IssueCreatedVisualizer>(); }); // We have a specific visualizer for IssueCreated container.GetInstance<IVisualizer<IssueCreated>>() .ShouldBeOfType<IssueCreatedVisualizer>(); // We do not have any special visualizer for TaskAssigned, // so fall back to the DefaultVisualizer<T> container.GetInstance<IVisualizer<TaskAssigned>>() .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>(); }

Connecting Generic Implementations with Type Scanning

It's generally harmful in software projects to have a single code file that has to be frequently edited to for unrelated changes, and StructureMap Registry classes that explicitly configure services can easily fall into that category. Using type scanning registration can help teams avoid that problem altogether by eliminating the need to make any explict registrations as new providers are added to the codebase.

For this example, I have two special visualizers for the IssueCreated and IssueResolved log types:
-
public class IssueCreatedVisualizer : IVisualizer<IssueCreated> { public string ToHtml(IssueCreated log) { return "special html for an issue being created"; } } public class IssueResolvedVisualizer : IVisualizer<IssueResolved> { public string ToHtml(IssueResolved log) { return "special html for issue resolved"; } }
+
public class IssueCreatedVisualizer : IVisualizer<IssueCreated> { public string ToHtml(IssueCreated log) { return "special html for an issue being created"; } } public class IssueResolvedVisualizer : IVisualizer<IssueResolved> { public string ToHtml(IssueResolved log) { return "special html for issue resolved"; } }

In the real project that inspired this example, we had many, many more types of log visualizer strategies and it could have easily been very tedious to manually register all the different little IVisualizer<T> strategy types in a Registry class by hand. Fortunately, part of StructureMap's type scanning support is the ConnectImplementationsToTypesClosing() auto-registration mechanism via generic templates for exactly this kind of scenario.

In the sample below, I've set up a type scanning operation that will register any concrete type in the Assembly that contains the VisualizationRegistry that closes IVisualizer<T> against the proper interface:
-
public class VisualizationRegistry : Registry { public VisualizationRegistry() { // The main ILogVisualizer service For<ILogVisualizer>().Use<LogVisualizer>(); // A default, fallback visualizer For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>)); // Auto-register all concrete types that "close" // IVisualizer<TLog> Scan(x => { x.TheCallingAssembly(); x.ConnectImplementationsToTypesClosing(typeof(IVisualizer<>)); }); } }
+
public class VisualizationRegistry : Registry { public VisualizationRegistry() { // The main ILogVisualizer service For<ILogVisualizer>().Use<LogVisualizer>(); // A default, fallback visualizer For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>)); // Auto-register all concrete types that "close" // IVisualizer<TLog> Scan(x => { x.TheCallingAssembly(); x.ConnectImplementationsToTypesClosing(typeof(IVisualizer<>)); }); } }

If we create a Container based on the configuration above, we can see that the type scanning operation picks up the specific visualizers for IssueCreated and IssueResolved as shown in the diagnostic view below:

@@ -183,16 +183,16 @@
Connecting Generi

The following sample shows the VisualizationRegistry in action to combine the type scanning registration plus the default fallback behavior for log types that do not have any special visualization logic:
-
[Fact] public void visualization_registry() { var container = Container.For<VisualizationRegistry>(); Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization")); container.GetInstance<IVisualizer<IssueCreated>>() .ShouldBeOfType<IssueCreatedVisualizer>(); container.GetInstance<IVisualizer<IssueResolved>>() .ShouldBeOfType<IssueResolvedVisualizer>(); // We have no special registration for TaskAssigned, // so fallback to the default visualizer container.GetInstance<IVisualizer<TaskAssigned>>() .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>(); }
+
[Fact] public void visualization_registry() { var container = Container.For<VisualizationRegistry>(); Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization")); container.GetInstance<IVisualizer<IssueCreated>>() .ShouldBeOfType<IssueCreatedVisualizer>(); container.GetInstance<IVisualizer<IssueResolved>>() .ShouldBeOfType<IssueResolvedVisualizer>(); // We have no special registration for TaskAssigned, // so fallback to the default visualizer container.GetInstance<IVisualizer<TaskAssigned>>() .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>(); }

Building Closed Types with ForGenericType() and ForObject()

Working with generic types and the common IHandler<T> pattern can be a little bit tricky if all you have is an object that is declared as an object. Fortunately, StructureMap has a couple helper methods and mechanisms to help you bridge the gap between DoSomething(object something) and DoSomething<T>(T something).

If you remember the full ILogVisualizer interface from above:
-
public interface ILogVisualizer { // If we already know what the type of log we have string ToHtml<TLog>(TLog log); // If we only know that we have a log object string ToHtml(object log); }
+
public interface ILogVisualizer { // If we already know what the type of log we have string ToHtml<TLog>(TLog log); // If we only know that we have a log object string ToHtml(object log); }

The method ToHtml(object log) somehow needs to be able to find the right IVisualizer<T> and execute it to get the HTML representation for a log object. The StructureMap IContainer provides two different methods called ForObject() and ForGenericType() for exactly this case, as shown below in a possible implementation of ILogVisualizer:
-
public class LogVisualizer : ILogVisualizer { private readonly IContainer _container; // Take in the IContainer directly so that // yes, you can use it as a service locator public LogVisualizer(IContainer container) { _container = container; } // It's easy if you already know what the log // type is public string ToHtml<TLog>(TLog log) { return _container.GetInstance<IVisualizer<TLog>>() .ToHtml(log); } public string ToHtml(object log) { // The ForObject() method uses the // log.GetType() as the parameter to the open // type Writer<T>, and then resolves that // closed type from the container and // casts it to IWriter for you return _container.ForObject(log) .GetClosedTypeOf(typeof (Writer<>)) .As<IWriter>() .Write(log); } public string ToHtml2(object log) { // The ForGenericType() method is again creating // a closed type of Writer<T> from the Container // and casting it to IWriter return _container.ForGenericType(typeof (Writer<>)) .WithParameters(log.GetType()) .GetInstanceAs<IWriter>() .Write(log); } // The IWriter and Writer<T> class below are // adapters to go from "object" to <T>() signatures public interface IWriter { string Write(object log); } public class Writer<T> : IWriter { private readonly IVisualizer<T> _visualizer; public Writer(IVisualizer<T> visualizer) { _visualizer = visualizer; } public string Write(object log) { return _visualizer.ToHtml((T) log); } } }
+
public class LogVisualizer : ILogVisualizer { private readonly IContainer _container; // Take in the IContainer directly so that // yes, you can use it as a service locator public LogVisualizer(IContainer container) { _container = container; } // It's easy if you already know what the log // type is public string ToHtml<TLog>(TLog log) { return _container.GetInstance<IVisualizer<TLog>>() .ToHtml(log); } public string ToHtml(object log) { // The ForObject() method uses the // log.GetType() as the parameter to the open // type Writer<T>, and then resolves that // closed type from the container and // casts it to IWriter for you return _container.ForObject(log) .GetClosedTypeOf(typeof (Writer<>)) .As<IWriter>() .Write(log); } public string ToHtml2(object log) { // The ForGenericType() method is again creating // a closed type of Writer<T> from the Container // and casting it to IWriter return _container.ForGenericType(typeof (Writer<>)) .WithParameters(log.GetType()) .GetInstanceAs<IWriter>() .Write(log); } // The IWriter and Writer<T> class below are // adapters to go from "object" to <T>() signatures public interface IWriter { string Write(object log); } public class Writer<T> : IWriter { private readonly IVisualizer<T> _visualizer; public Writer(IVisualizer<T> visualizer) { _visualizer = visualizer; } public string Write(object log) { return _visualizer.ToHtml((T) log); } } }

The two methods are almost identical in result with some slight differences:

ForObject(object subject) can only work with open types that have only one generic type parameter, and it will pass the argument subject to the underlying Container as an explicit argument so that you can inject that subject object into the object graph being created.
@@ -202,23 +202,23 @@
Example #2: Generic Instance Builder
As I recall, the following example was inspired by a question about how to use StructureMap to build out MongoDB MongoCollection objects from some sort of static builder or factory -- but I can't find the discussion on the mailing list as I write this today. This has come up often enough to justify its inclusion in the documentation.

Say that you have some sort of persistence tooling that you primarily interact with through an interface like this one below, where TDocument and TQuery are classes in your persistent domain:
-
public interface IRepository<TDocument, TQuery> { }
+
public interface IRepository<TDocument, TQuery> { }

Great, StructureMap handles generic types just fine, so you can just register the various closed types and off you go. Except you can't because the way that your persistence tooling works requires you to create the IRepository<,> objects with a static builder class like this one below:
-
public static class RepositoryBuilder { public static IRepository<TDocument, TQuery> Build<TDocument, TQuery>() { return new Repository<TDocument, TQuery>(); } }
+
public static class RepositoryBuilder { public static IRepository<TDocument, TQuery> Build<TDocument, TQuery>() { return new Repository<TDocument, TQuery>(); } }

StructureMap has an admittedly non-obvious way to handle this situation by creating a new subclass of Instance that will "know" how to create the real Instance for a closed type of IRepository<,>.

First off, let's create a new Instance type that knows how to build a specific type of IRepository<,> by subclassing the LambdaInstance type and providing a Func to build our repository type with the static RepositoryBuilder class:
-
public class RepositoryInstance<TDocument, TQuery> : LambdaInstance<IRepository<TDocument, TQuery>> { public RepositoryInstance() : base(() => RepositoryBuilder.Build<TDocument, TQuery>()) { } // This is purely to make the diagnostic views prettier public override string Description { get { return "RepositoryBuilder.Build<{0}, {1}>()" .ToFormat(typeof(TDocument).Name, typeof(TQuery).Name); } } }
+
public class RepositoryInstance<TDocument, TQuery> : LambdaInstance<IRepository<TDocument, TQuery>> { public RepositoryInstance() : base(() => RepositoryBuilder.Build<TDocument, TQuery>()) { } // This is purely to make the diagnostic views prettier public override string Description { get { return "RepositoryBuilder.Build<{0}, {1}>()" .ToFormat(typeof(TDocument).Name, typeof(TQuery).Name); } } }

As you've probably surmised, the custom RepositoryInstance above is itself an open generic type and cannot be used directly until it has been closed. You could use this class directly if you have a very few document types like this:
-
var container = new Container(_ => { _.For<IRepository<string, int>>().UseInstance(new RepositoryInstance<string, int>()); // or skip the custom Instance with: _.For<IRepository<string, int>>().Use(() => RepositoryBuilder.Build<string, int>()); });
+
var container = new Container(_ => { _.For<IRepository<string, int>>().UseInstance(new RepositoryInstance<string, int>()); // or skip the custom Instance with: _.For<IRepository<string, int>>().Use(() => RepositoryBuilder.Build<string, int>()); });

To handle the problem in a more generic way, we can create a second custom subclass of Instance for the open type IRepository<,> that will help StructureMap understand how to build the specific closed types of IRepository<,> at runtime:
-
public class RepositoryInstanceFactory : Instance { // This is the key part here. This method is called by // StructureMap to "find" an Instance for a closed // type of IRepository<,> public override Instance CloseType(Type[] types) { // StructureMap will cache the object built out of this, // so the expensive Reflection hit only happens // once var instanceType = typeof(RepositoryInstance<,>).MakeGenericType(types); return Activator.CreateInstance(instanceType).As<Instance>(); } // Don't worry about this one, never gets called public override IDependencySource ToDependencySource(Type pluginType) { throw new NotSupportedException(); } public override string Description { get { return "Build Repository<T, T1>() with RepositoryBuilder"; } } public override Type ReturnedType { get { return typeof(Repository<,>); } } }
+
public class RepositoryInstanceFactory : Instance { // This is the key part here. This method is called by // StructureMap to "find" an Instance for a closed // type of IRepository<,> public override Instance CloseType(Type[] types) { // StructureMap will cache the object built out of this, // so the expensive Reflection hit only happens // once var instanceType = typeof(RepositoryInstance<,>).MakeGenericType(types); return Activator.CreateInstance(instanceType).As<Instance>(); } // Don't worry about this one, never gets called public override IDependencySource ToDependencySource(Type pluginType) { throw new NotSupportedException(); } public override string Description { get { return "Build Repository<T, T1>() with RepositoryBuilder"; } } public override Type ReturnedType { get { return typeof(Repository<,>); } } }

The key part of the class above is the CloseType(Type[] types) method. At that point, we can determine the right type of RepositoryInstance<,> to build the requested type of IRepository<,>, then use some reflection to create and return that custom Instance.

Here's a unit test that exercises and demonstrates this functionality from end to end:
-
[Fact] public void show_the_workaround_for_generic_builders() { var container = new Container(_ => { _.For(typeof(IRepository<,>)).Use(new RepositoryInstanceFactory()); }); container.GetInstance<IRepository<string, int>>() .ShouldBeOfType<Repository<string, int>>(); Debug.WriteLine(container.WhatDoIHave(assembly: GetType().GetAssembly())); }
+
[Fact] public void show_the_workaround_for_generic_builders() { var container = new Container(_ => { _.For(typeof(IRepository<,>)).Use(new RepositoryInstanceFactory()); }); container.GetInstance<IRepository<string, int>>() .ShouldBeOfType<Repository<string, int>>(); Debug.WriteLine(container.WhatDoIHave(assembly: GetType().GetAssembly())); }

After requesting IRepository<string, int> for the first time, the container configuration from Container.WhatDoIHave() is:

=================================================================================================================================================== @@ -235,16 +235,16 @@
Example 3: Intercep that same design with the improved interception model introduced by StructureMap 3.0 (the event aggregator and StructureMap interception worked out well, but I'm very happy now that I ditched the old WPF client and replaced it with a web application using React.js instead).

First off, let's say that we're going to have this interface for our event aggregator:
-
public interface IEventAggregator { // Sending messages void SendMessage<T>(T message); void SendMessage<T>() where T : new(); // Explicit registration void AddListener(object listener); void RemoveListener(object listener); }
+
public interface IEventAggregator { // Sending messages void SendMessage<T>(T message); void SendMessage<T>() where T : new(); // Explicit registration void AddListener(object listener); void RemoveListener(object listener); }

To register a listener for a particular type of event notification, you would implement an interface called IListener<T> shown below and directly add that object to the IEventAggregator:
-
public interface IListener<T> { void Handle(T message); }
+
public interface IListener<T> { void Handle(T message); }

In the application I'm describing, all of the listener objects were presenters or screen controls that were created by StructureMap, so it was convenient to allow StructureMap to register newly created objects with the IEventAggregator in an activation interceptor.

What we want to do though is have an interception policy that only applies to any concrete type that implements some interface that closes IListener<T>:
-
public class EventListenerRegistration : IInterceptorPolicy { public string Description { get { return "Adds the constructed object to the EventAggregator"; } } public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance) { if (instance.ReturnedType.FindInterfacesThatClose(typeof(IListener<>)).Any()) { Expression<Action<IContext, object>> register = (c, o) => c.GetInstance<IEventAggregator>().AddListener(o); yield return new ActivatorInterceptor<object>(register); } } }
+
public class EventListenerRegistration : IInterceptorPolicy { public string Description { get { return "Adds the constructed object to the EventAggregator"; } } public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance) { if (instance.ReturnedType.FindInterfacesThatClose(typeof(IListener<>)).Any()) { Expression<Action<IContext, object>> register = (c, o) => c.GetInstance<IEventAggregator>().AddListener(o); yield return new ActivatorInterceptor<object>(register); } } }

To see our new interception policy in action, see this unit test from GitHub:
-
[Fact] public void use_the_event_listener_registration() { var container = new Container(x => { x.Policies.Interceptors(new EventListenerRegistration()); x.For<IEventAggregator>().Use<EventAggregator>().Singleton(); }); var events = container.GetInstance<IEventAggregator>(); var listener = container.GetInstance<BooMessageListener>(); var message = new BooMessage(); events.SendMessage(message); listener.Messages.Single().ShouldBeTheSameAs(message); }
+
[Fact] public void use_the_event_listener_registration() { var container = new Container(x => { x.Policies.Interceptors(new EventListenerRegistration()); x.For<IEventAggregator>().Use<EventAggregator>().Singleton(); }); var events = container.GetInstance<IEventAggregator>(); var listener = container.GetInstance<BooMessageListener>(); var message = new BooMessage(); events.SendMessage(message); listener.Messages.Single().ShouldBeTheSameAs(message); }

diff --git a/get-structuremap/index.html b/get-structuremap/index.html old mode 100644 new mode 100755 index 5f6eb8d..3e11211 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Features

Previous
Glossary

@@ -94,7 +94,8 @@
Current Release

The current version of StructureMap will always be available on Nuget. See the Release Notes for more information.

Supported Platforms

The original StructureMap.dll has been broken up into a couple pieces. The main assembly will be targeting PCL compliance thanks to the diligent efforts of Frank Quednau, and that means that anything to do with ASP.Net or falls outside of the PCL core has been devolved into separate assemblies and eventually into different Nuget packages. This means that StructureMap 3.* will theoretically support WP8 and other versions of .Net for the very first time.
-
At this point StructureMap 3.* has been used on .Net 4, 4.5, WP8, and WP8.1. Nobody in the core StructureMap team is currently working with Xamarin mobile runtimes, but we are interested in verifying StructureMap on new platforms if any volunteers are interested in helping us out.
+
At this point StructureMap 3.* has been used on .Net 4, 4.5, WP8, and WP8.1.
+
StructureMap 4.5+ will not work on Xamarin iOS because it depends on System.Reflection.Emit, which is not available in MonoTouch. StructureMap 4.4 works for at least basic scenarios on that platform. Nobody in the core StructureMap team is currently working with Xamarin mobile runtimes, but we are interested in verifying StructureMap on new platforms if any volunteers are interested in helping us out.

Binaries

Binaries of StructureMap are available via NuGet:

PM> Install-Package StructureMap diff --git a/glossary/index.html b/glossary/index.html old mode 100644 new mode 100755 index f741276..5d31855 --- a/glossary/index.html +++ b/glossary/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Get StructureMap Previous A Gentle Quickstart @@ -95,26 +95,26 @@ Container A container is a tool that can help you composing object graphs and managing their scope (lifecycle). Altough you can do Inversion of Control and Dependency Injection manually, using tools like StructureMap makes you far more productive and succesfull in doing so. Obviously there is more to a container than resolving services and managing their scope, but in the core that's just what it is. Before you can do so you need to tell StructureMap, the container, how it must compose those objects graphs and what their lifecycle is. This is called registration and can be done in various mixed ways. The strongly recommend way would be using the Registry DSL. In your registration you're basically mapping abstractions to concrete types and defining their lifecycle. A simple example of a container using the Registry DSL: - public class FooBarRegistry : Registry { public FooBarRegistry() { For<IFoo>().Use<Foo>(); For<IBar>().Use<Bar>(); } } - var container = new Container(c => { c.AddRegistry<FooBarRegistry>(); }); + public class FooBarRegistry : Registry { public FooBarRegistry() { For<IFoo>().Use<Foo>(); For<IBar>().Use<Bar>(); } } + var container = new Container(c => { c.AddRegistry<FooBarRegistry>(); }); Because we didn't specify the lifecycle for both registrations, the default Transient lifecycle will be used. This will instruct the container to create a new instance for every request for a plugin type IFoo or IBar. More advanced features that the container can do are things like: Interception, Auto-Wiring, Forwarding Types. Nested Container A nested container is used to mark the scope of short lived transactions or web requests and track and clean up objects implementing the IDisposable interface for that operation. You can ask an existing container to create a nested container for you like in the following example: - using (var nested = someExistingContainer.GetNestedContainer()) { // pull other objects from the nested container and do work with those services var service = nested.GetInstance<IService>(); service.DoSomething(); } + using (var nested = someExistingContainer.GetNestedContainer()) { // pull other objects from the nested container and do work with those services var service = nested.GetInstance<IService>(); service.DoSomething(); } For more detailed information about nested containers and their special properties you can read the Nested Containers (Per Request/Transaction) topic. PluginType and PluggedType The term plugin type is used throughout the code and documentation to mean the type that you want to register or resolve. More generally this type is known as the service type. This type can be a concrete class or in most cases, it will be a form of abstraction like an abstract class or interface. The term plugged type means the actual concrete type that you get when you request the plugin type. This type must obviously implement the plugin type contract. In your registration you could have something like this: - public class FooRegistry : Registry { public FooRegistry() { For<IFoo>().Use<Foo>(); } } - //For<PLUGINTYPE>().Use<PLUGGEDTYPE>() var container = new Container(c => { c.AddRegistry<FooRegistry>(); }); container.GetInstance<IFoo>(); //container.GetInstance<PLUGINTYPE>() + public class FooRegistry : Registry { public FooRegistry() { For<IFoo>().Use<Foo>(); } } + //For<PLUGINTYPE>().Use<PLUGGEDTYPE>() var container = new Container(c => { c.AddRegistry<FooRegistry>(); }); container.GetInstance<IFoo>(); //container.GetInstance<PLUGINTYPE>() If you request an object of IFoo, you'll get an instance of the Foo class. In this case, IFoo is the plugin type (what you're asking for) and Foo is the plugged type (the concrete class you'll get that fulfills, implements the plugin type contract). PluginFamily This term you will not see so often because it's mostly used by StructureMap itself. A PluginFamily represents a CLR type (the plugin type) that StructureMap can build, and all of the possible plugged types that implement the CLR type. In the following code StructureMap internally creates one PluginFamily of the plugin type IFoo with two instances Foo and SomeOtherFoo, where Foo is the default instance because it's registered through For<PLUGIN_TYPE>().Use<PLUGGED_TYPE>(). - var container = new Container(c => { c.For<IFoo>().Use<Foo>(); c.For<IFoo>().Add<SomeOtherFoo>(); }); + var container = new Container(c => { c.For<IFoo>().Use<Foo>(); c.For<IFoo>().Add<SomeOtherFoo>(); }); Before StructureMap 3.0 you have probably seen the term used in an exception message when you request a plugin type that doesn't have a default instance defined. StructureMap Exception Code: 202 No Default Instance defined for PluginFamily [plugin type] @@ -125,11 +125,11 @@ Plugin Graph any kind of special convention that doesn't fit into the existing conventional support. Instance In StructureMap terms, an "Instance" is a configured and named strategy to build or locate a named object instance for a requested Plugin Type. An "Instance" does not automatically equate to a concrete type. For example, let's say that we're building a system to automate a warehouse. Our system might consume an interface called IShippingService that acts as a Gateway to various ways of shipping boxes out of our warehouse. - public interface IShippingService { void ShipIt(); } + public interface IShippingService { void ShipIt(); } Our warehouse system might have to interact with three types of shipping: domestic, international, and intra-company or internal shipments. The internal shipping service runs in process with the warehouse application, but domestic and international shipping is done by invoking external web services. The registration of the IShippingService Instances might look like this: - public class ShippingRegistry : Registry { public ShippingRegistry() { For<IShippingService>().AddInstances(x => { x.Type<ShippingWebService>() .Ctor<string>("url").Is("a url") .Named("Domestic"); x.Type<ShippingWebService>() .Ctor<string>("url").Is("a different url") .Named("International"); x.Type<InternalShippingService>().Named("Internal"); }); } } + public class ShippingRegistry : Registry { public ShippingRegistry() { For<IShippingService>().AddInstances(x => { x.Type<ShippingWebService>() .Ctor<string>("url").Is("a url") .Named("Domestic"); x.Type<ShippingWebService>() .Ctor<string>("url").Is("a different url") .Named("International"); x.Type<InternalShippingService>().Named("Internal"); }); } } In the registration code above, there are three "Instances." You can access the various IShippingService Instance's by name: - var container = new Container(new ShippingRegistry()); // Accessing the IShippingService Instance's by name var internationalService = container.GetInstance<IShippingService>("International"); var domesticService = container.GetInstance<IShippingService>("Domestic"); var internalService = container.GetInstance<IShippingService>("Internal"); + var container = new Container(new ShippingRegistry()); // Accessing the IShippingService Instance's by name var internationalService = container.GetInstance<IShippingService>("International"); var domesticService = container.GetInstance<IShippingService>("Domestic"); var internalService = container.GetInstance<IShippingService>("Internal"); Asking for the "International" or the "Domestic" instance of IShippingService will both return an object of type ShippingWebService, but the two objects will be differently configured with unique Url's. There is an actual class in StructureMap that represents an "Instance." When you call Container.GetInstance<T>("the instance that I want") or Container.GetInstance<T>(), the internal Container object is locating the correct Instance object and then using the Instance's internal build plan to resolve or construct the actual object. @@ -153,7 +153,7 @@ Auto wiring most IoC container tools, supports the concept of auto-wiring -- meaning that StructureMap can happily infer dependency requirements from constructor functions and setter rules and fill those dependencies with the default configuration for the declared dependency type. Let's just see it in action: - public interface Xman { } public class Cyclops : Xman { } public interface Avenger { } public class IronMan : Avenger { } public class CrossoverEvent { public Xman Xman { get; set; } public Avenger Avenger { get; set; } public CrossoverEvent(Xman xman, Avenger avenger) { Xman = xman; Avenger = avenger; } } public class UsingCrossover { [Fact] public void showing_auto_wiring() { var container = new Container(x => { x.For<Xman>().Use<Cyclops>(); x.For<Avenger>().Use<IronMan>(); }); // Notice that at no point did we define how to // build CrossoverEvent. var @event = container.GetInstance<CrossoverEvent>(); @event.Avenger.ShouldBeOfType<IronMan>(); @event.Xman.ShouldBeOfType<Cyclops>(); } } + public interface Xman { } public class Cyclops : Xman { } public interface Avenger { } public class IronMan : Avenger { } public class CrossoverEvent { public Xman Xman { get; set; } public Avenger Avenger { get; set; } public CrossoverEvent(Xman xman, Avenger avenger) { Xman = xman; Avenger = avenger; } } public class UsingCrossover { [Fact] public void showing_auto_wiring() { var container = new Container(x => { x.For<Xman>().Use<Cyclops>(); x.For<Avenger>().Use<IronMan>(); }); // Notice that at no point did we define how to // build CrossoverEvent. var @event = container.GetInstance<CrossoverEvent>(); @event.Avenger.ShouldBeOfType<IronMan>(); @event.Xman.ShouldBeOfType<Cyclops>(); } } diff --git a/history/index.html b/history/index.html old mode 100644 new mode 100755 index a55ae0a..9e5640e --- a/history/index.html +++ b/history/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Release Notes Previous Best Practices diff --git a/instances/index.html b/instances/index.html old mode 100644 new mode 100755 index 1d909a1..7481557 --- a/instances/index.html +++ b/instances/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Integrating StructureMap into Common .Net Frameworks Previous Release Notes @@ -91,14 +91,14 @@ Custom Instance Types public class FuncInstance<T> : LambdaInstance<Func<T>> { // Pass a Func<IContext, T> into the base constructor // Use a static method for cleaner syntax to avoid the // nasty Lambda syntax formatting as needed public FuncInstance() : base(s => s.GetInstance<IContainer>().GetInstance<T>) { } public override string Description { get { return "Constructor for Func<{0}>".ToFormat(typeof (T).Name); } } }
+ public class FuncInstance<T> : LambdaInstance<Func<T>> { // Pass a Func<IContext, T> into the base constructor // Use a static method for cleaner syntax to avoid the // nasty Lambda syntax formatting as needed public FuncInstance() : base(s => s.GetInstance<IContainer>().GetInstance<T>) { } public override string Description { get { return "Constructor for Func<{0}>".ToFormat(typeof (T).Name); } } } The other common customization is as a generic builder template If neither of these approaches will easily work for your custom Instance, you may want to contact the StructureMap team via the gitter link above and we can help walk you through a custom subclass of Instance -- or more likely, talk you out of it somehow. Missing Name Instance Template New to StructureMap 4.0 is the Instance.ToNamedClone(name) method that is used behind the scenes by the Handling Missing Named Instances feature. - public virtual Instance ToNamedClone(string name) + public virtual Instance ToNamedClone(string name) Custom Instance types can override this method to provide a brand new Instance for a name. This functionality may be useful for multi-tenancy situations.
diff --git a/integrations/index.html b/integrations/index.html old mode 100644 new mode 100755 index 0836d36..3938edd --- a/integrations/index.html +++ b/integrations/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Previous Custom Instance Types diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html old mode 100644 new mode 100755 index 31e6b73..aac2ac7 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Interpreting Exceptions Previous Generic Types @@ -111,10 +111,10 @@ Activation Interceptors For right now, all activation interceptors are either using or subclassing the ActivatorInterceptor<T> class. This class has two constructor functions that interest us: To create an activator interceptor that acts on an object that can be cast to type T: - public ActivatorInterceptor(Expression<Action<T>> action, string description = null) + public ActivatorInterceptor(Expression<Action<T>> action, string description = null) To create an activator interceptor that acts on an object that can be cast to type T and also uses the IContext service supplied by StructureMap itself. - public ActivatorInterceptor(Expression<Action<IContext, T>> action, string description = null) { _action = action; _description = description; } + public ActivatorInterceptor(Expression<Action<IContext, T>> action, string description = null) { _action = action; _description = description; } In both cases, the description is optional and is only used for diagnostic purposes in the build plan visualization. If omitted, StructureMap tries to do a ToString() on the Expression for the description and that frequently suffices to understand what's going on in the build plan. Please note that the Lambda supplied to ActivatorInterceptor<T> must be a .Net Expression so cannot be a multi-line Lambda. @@ -124,37 +124,37 @@ Decorators To demonstrate a decorator in action, say that we have an interface called IWidget, and when we build any instance of IWidget we want those objects decorated by another type of IWidget that I clumsily named WidgetHolder in the acceptance tests: - public class WidgetHolder : IWidget { private readonly IWidget _inner; public WidgetHolder(IWidget inner) { _inner = inner; } public IWidget Inner { get { return _inner; } } } + public class WidgetHolder : IWidget { private readonly IWidget _inner; public WidgetHolder(IWidget inner) { _inner = inner; } public IWidget Inner { get { return _inner; } } } Now, to see the decorator mechanism in action: - [Fact] public void decorator_example() { var container = new Container(_ => { // This usage adds the WidgetHolder as a decorator // on all IWidget registrations and makes AWidget // the default _.For<IWidget>().DecorateAllWith<WidgetHolder>(); _.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<WidgetHolder>() .Inner.ShouldBeOfType<AWidget>(); } + [Fact] public void decorator_example() { var container = new Container(_ => { // This usage adds the WidgetHolder as a decorator // on all IWidget registrations and makes AWidget // the default _.For<IWidget>().DecorateAllWith<WidgetHolder>(); _.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<WidgetHolder>() .Inner.ShouldBeOfType<AWidget>(); } In effect, doing a decorator this way has the same effect (and build plan) as: - var container = new Container(_ => { _.For<IWidget>().Use<WidgetHolder>() .Ctor<IWidget>().Is<AWidget>(); }); + var container = new Container(_ => { _.For<IWidget>().Use<WidgetHolder>() .Ctor<IWidget>().Is<AWidget>(); }); Custom Decorator Interceptors The simplest usage is to just declare a type that will be the decorating type like we did above, but if you need some other mechanism for decorators like runtime AOP interception or you want to build the decorating object yourself, StructureMap provides the FuncInterceptor<T> type where T is the type you want to decorate. These objects can be created in two ways, by a user-supplied Expression<Func<T, T>> and optional description: - public FuncInterceptor(Expression<Func<T, T>> expression, string description = null) + public FuncInterceptor(Expression<Func<T, T>> expression, string description = null) and by a user-supplied Expression<Func<IContext, T, T>> and optional description. - public FuncInterceptor(Expression<Func<IContext, T, T>> expression, string description = null) + public FuncInterceptor(Expression<Func<IContext, T, T>> expression, string description = null) In both cases, the description field is only used for diagnostic purposes. Interception Policies The Registry DSL includes shorthand methods for the most common ways of configuring decorators and activators by an individual Instance or by matching on implementing types. For more customized interception policies that don't fit these mechanisms, StructureMap allows you to directly define an interception policy with a class implementing this interface below: - /// <summary> /// User defined policy to conventionally attach interceptors /// to any pluginType/instance combination in a StructureMap /// container /// </summary> public interface IInterceptorPolicy : IDescribed { /// <summary> /// Determine what (if any) interceptors should be attached to the /// given instance and pluginType /// </summary> /// <param name="pluginType">The Type that is being requested</param> /// <param name="instance">The Instance being built</param> /// <returns></returns> IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance); } + /// <summary> /// User defined policy to conventionally attach interceptors /// to any pluginType/instance combination in a StructureMap /// container /// </summary> public interface IInterceptorPolicy : IDescribed { /// <summary> /// Determine what (if any) interceptors should be attached to the /// given instance and pluginType /// </summary> /// <param name="pluginType">The Type that is being requested</param> /// <param name="instance">The Instance being built</param> /// <returns></returns> IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance); } For a simple example, let's say that we want to decorate any IWidget object with the WidgetHolder class from earlier. We could build a small custom interceptor policy like this one: - public class CustomInterception : IInterceptorPolicy { public string Description { get { return "good interception policy"; } } public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance) { if (pluginType == typeof(IWidget)) { // DecoratorInterceptor is the simple case of wrapping one type with another // concrete type that takes the first as a dependency yield return new DecoratorInterceptor(typeof(IWidget), typeof(WidgetHolder)); } } } + public class CustomInterception : IInterceptorPolicy { public string Description { get { return "good interception policy"; } } public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance) { if (pluginType == typeof(IWidget)) { // DecoratorInterceptor is the simple case of wrapping one type with another // concrete type that takes the first as a dependency yield return new DecoratorInterceptor(typeof(IWidget), typeof(WidgetHolder)); } } } To use this custom interception policy, use the Policies.Interceptor() methods like this example: - [Fact] public void use_a_custom_interception_policy() { var container = new Container(x => { x.Policies.Interceptors(new CustomInterception()); x.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<WidgetHolder>() .Inner.ShouldBeOfType<AWidget>(); } + [Fact] public void use_a_custom_interception_policy() { var container = new Container(x => { x.Policies.Interceptors(new CustomInterception()); x.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<WidgetHolder>() .Inner.ShouldBeOfType<AWidget>(); } As a helper for creating your own interception policies, you can also use the InterceptorPolicy<T> base class to conventionally apply some sort of IInterceptor to any number of Instance's: - public InterceptorPolicy(IInterceptor interceptor, Func<Instance, bool> filter = null) + public InterceptorPolicy(IInterceptor interceptor, Func<Instance, bool> filter = null) Here's an example of InterceptorPolicy<T> in usage from the acceptance tests: - [Fact] public void apply_policy_selectively_with_a_func() { var activator1 = new ActivatorInterceptor<ITarget>(x => x.Activate()); var policy = new InterceptorPolicy<ITarget>(activator1, i => i.Name.StartsWith("A")); var container = new Container(x => { x.Policies.Interceptors(policy); x.For<ITarget>().AddInstances(targets => { targets.Type<ATarget>().Named("A"); targets.Type<ATarget>().Named("A1"); targets.Type<ATarget>().Named("A2"); targets.Type<ATarget>().Named("B"); targets.Type<ATarget>().Named("C"); targets.Type<ATarget>().Named("D"); }); }); container.GetInstance<ITarget>("A").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue(); container.GetInstance<ITarget>("A1").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue(); container.GetInstance<ITarget>("A2").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue(); container.GetInstance<ITarget>("B").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse(); container.GetInstance<ITarget>("C").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse(); container.GetInstance<ITarget>("D").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse(); } public class ATarget : ITarget { public void Activate() { WasActivated = true; } public bool WasActivated { get; set; } public void Debug() { throw new NotImplementedException(); } } + [Fact] public void apply_policy_selectively_with_a_func() { var activator1 = new ActivatorInterceptor<ITarget>(x => x.Activate()); var policy = new InterceptorPolicy<ITarget>(activator1, i => i.Name.StartsWith("A")); var container = new Container(x => { x.Policies.Interceptors(policy); x.For<ITarget>().AddInstances(targets => { targets.Type<ATarget>().Named("A"); targets.Type<ATarget>().Named("A1"); targets.Type<ATarget>().Named("A2"); targets.Type<ATarget>().Named("B"); targets.Type<ATarget>().Named("C"); targets.Type<ATarget>().Named("D"); }); }); container.GetInstance<ITarget>("A").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue(); container.GetInstance<ITarget>("A1").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue(); container.GetInstance<ITarget>("A2").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue(); container.GetInstance<ITarget>("B").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse(); container.GetInstance<ITarget>("C").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse(); container.GetInstance<ITarget>("D").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse(); } public class ATarget : ITarget { public void Activate() { WasActivated = true; } public bool WasActivated { get; set; } public void Debug() { throw new NotImplementedException(); } } Some quick things to note: For decorator interceptors, InterceptorPolicy<T> will only apply if the pluginType matches T @@ -164,25 +164,25 @@ Interception Policies Apply Activation Interception by Type Let's say that in your system you have a marker interface or in this case an abstract class that exposes a single Activate() method to start up stateful, long-running services created within your container: - public abstract class Activateable { public bool Activated { get; set; } public void Activate() { Activated = true; } } + public abstract class Activateable { public bool Activated { get; set; } public void Activate() { Activated = true; } } An implementation of Activateable from StructureMap's unit tests is shown below: - public class AWidget : Activateable, IWidget { } + public class AWidget : Activateable, IWidget { } If you decide that you'd like StructureMap to call the Activate() method on any object it creates as part of its object creation and resolution process, we can register an interception policy in a Registry like this: - [Fact] public void activate_by_action() { var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); x.For<Activateable>() .OnCreationForAll("Mark the object as activated", o => o.Activated = true); }); container.GetInstance<IWidget>() .ShouldBeOfType<AWidget>() .Activated.ShouldBeTrue(); } + [Fact] public void activate_by_action() { var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); x.For<Activateable>() .OnCreationForAll("Mark the object as activated", o => o.Activated = true); }); container.GetInstance<IWidget>() .ShouldBeOfType<AWidget>() .Activated.ShouldBeTrue(); } There are several overloads of OnCreationForAll() covering cases with and without IContext Apply Decoration across a Plugin Type As shown above, you can use the Registry.For<T>().DecorateAllWith<TDecorator>() to apply decorators to all Instance's registered to a Plugin Type: - [Fact] public void decorate_with_type() { var container = new Container(x => { x.For<IWidget>().DecorateAllWith<WidgetHolder>(); x.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<WidgetHolder>() .Inner .ShouldBeOfType<AWidget>(); } + [Fact] public void decorate_with_type() { var container = new Container(x => { x.For<IWidget>().DecorateAllWith<WidgetHolder>(); x.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<WidgetHolder>() .Inner .ShouldBeOfType<AWidget>(); } There are also several other overloads of DecorateAllWith() for user supplied expressions, filters, and descriptions. See the acceptance tests for interception in the StructureMap codebase for many more sample usages. Add Interception to a Single Instance You can also define interceptors directly to individual Instance's inside of a StructureMap Registry using the OnCreation() and DecorateWith methods or the more generic Instance.AddInterceptor() method. Here is some sample usage from StructureMap's unit tests on interception: - _container = new Container(r => { r.For<ContextRecorder>().Use(recorder); r.For<IService>().AddInstances(x => { x.Type<ColorService>() // Registers an activation action on this Instance .OnCreation("last service", s => _lastService = s) .Named("Intercepted") .Ctor<string>("color").Is("Red"); x.Type<ColorService>() // Activation using IContext .OnCreation("last touched", (c, s) => c.GetInstance<ContextRecorder>().WasTouched = true) .Named("InterceptedWithContext") .Ctor<string>("color").Is("Red"); x.Type<ColorService>() .Named("NotIntercepted") .Ctor<string>("color").Is("Blue"); x.Object(new ColorService("Yellow")) .Named("Yellow") .OnCreation("set the last service", s => _lastService = s); x.ConstructedBy(() => new ColorService("Purple")).Named("Purple") // Applies a decorator to this instance. Not sure *why* // you'd want to do it this way .DecorateWith(s => new DecoratorService(s)); x.ConstructedBy(() => new ColorService("Purple")).Named("DecoratedWithContext") // Fancier decorator .DecorateWith("decorated with context", (c, s) => { c.GetInstance<ContextRecorder>().WasTouched = true; return new DecoratorService(s); }); x.Type<ColorService>().Named("Decorated").DecorateWith( s => new DecoratorService(s)) .Ctor<string>("color").Is("Orange"); x.Object(new ColorService("Yellow")).Named("Bad") .OnCreation("throw exception", obj => { throw new Exception("Bad!"); }); }); + _container = new Container(r => { r.For<ContextRecorder>().Use(recorder); r.For<IService>().AddInstances(x => { x.Type<ColorService>() // Registers an activation action on this Instance .OnCreation("last service", s => _lastService = s) .Named("Intercepted") .Ctor<string>("color").Is("Red"); x.Type<ColorService>() // Activation using IContext .OnCreation("last touched", (c, s) => c.GetInstance<ContextRecorder>().WasTouched = true) .Named("InterceptedWithContext") .Ctor<string>("color").Is("Red"); x.Type<ColorService>() .Named("NotIntercepted") .Ctor<string>("color").Is("Blue"); x.Object(new ColorService("Yellow")) .Named("Yellow") .OnCreation("set the last service", s => _lastService = s); x.ConstructedBy(() => new ColorService("Purple")).Named("Purple") // Applies a decorator to this instance. Not sure *why* // you'd want to do it this way .DecorateWith(s => new DecoratorService(s)); x.ConstructedBy(() => new ColorService("Purple")).Named("DecoratedWithContext") // Fancier decorator .DecorateWith("decorated with context", (c, s) => { c.GetInstance<ContextRecorder>().WasTouched = true; return new DecoratorService(s); }); x.Type<ColorService>().Named("Decorated").DecorateWith( s => new DecoratorService(s)) .Ctor<string>("color").Is("Orange"); x.Object(new ColorService("Yellow")).Named("Bad") .OnCreation("throw exception", obj => { throw new Exception("Bad!"); }); }); diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html old mode 100644 new mode 100755 index 387c4b3..f874445 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Diagnostics Previous Interception and Decorators diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html old mode 100644 new mode 100755 index 90e2a5d..a290aa3 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Custom Lifecycles Previous Supported Lifecycles @@ -99,12 +99,12 @@ Configuring Lifecycles [Fact] public void lifecycle_precedence() { var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); // Configure the default lifecycle for // a PluginType (Rule) x.For<Rule>().Singleton(); x.For<Rule>().Add<ARule>().Named("C"); // Configure the lifecycle for a single Instance x.For<Rule>().Add<ARule>().Named("A").Transient(); x.For<Rule>().Add<ARule>().Named("B").AlwaysUnique(); }); // The default lifecycle is Transient container.Model.For<IWidget>().Default .Lifecycle.ShouldBeOfType<TransientLifecycle>(); // Override at the Family container.Model.For<Rule>().Lifecycle.ShouldBeOfType<SingletonLifecycle>(); container.Model.For<Rule>().Find("C").Lifecycle.ShouldBeOfType<SingletonLifecycle>(); // 'C' is the default lifecycle for Rule (SingletonThing) container.GetInstance<Rule>("C") .ShouldBeTheSameAs(container.GetInstance<Rule>("C")); // 'A' is a transient container.GetInstance<Rule>("A") .ShouldNotBeTheSameAs(container.GetInstance<Rule>("A")); using (var nested = container.GetNestedContainer()) { // 'B' is always unique nested.GetInstance<Rule>("B") .ShouldNotBeTheSameAs(nested.GetInstance<Rule>("B")); } } + [Fact] public void lifecycle_precedence() { var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); // Configure the default lifecycle for // a PluginType (Rule) x.For<Rule>().Singleton(); x.For<Rule>().Add<ARule>().Named("C"); // Configure the lifecycle for a single Instance x.For<Rule>().Add<ARule>().Named("A").Transient(); x.For<Rule>().Add<ARule>().Named("B").AlwaysUnique(); }); // The default lifecycle is Transient container.Model.For<IWidget>().Default .Lifecycle.ShouldBeOfType<TransientLifecycle>(); // Override at the Family container.Model.For<Rule>().Lifecycle.ShouldBeOfType<SingletonLifecycle>(); container.Model.For<Rule>().Find("C").Lifecycle.ShouldBeOfType<SingletonLifecycle>(); // 'C' is the default lifecycle for Rule (SingletonThing) container.GetInstance<Rule>("C") .ShouldBeTheSameAs(container.GetInstance<Rule>("C")); // 'A' is a transient container.GetInstance<Rule>("A") .ShouldNotBeTheSameAs(container.GetInstance<Rule>("A")); using (var nested = container.GetNestedContainer()) { // 'B' is always unique nested.GetInstance<Rule>("B") .ShouldNotBeTheSameAs(nested.GetInstance<Rule>("B")); } } Using Attributes New in StructureMap 4.0 are some simple attributes to mark either a complete Plugin Type or a single Instance as either a singleton or using the always unique lifecycle: The usage is shown below: - [AlwaysUnique] public interface IShouldBeUnique { } [Singleton] // because the most wonderful thing about Tiggers is that I'm the only one.... public class Tigger { } + [AlwaysUnique] public interface IShouldBeUnique { } [Singleton] // because the most wonderful thing about Tiggers is that I'm the only one.... public class Tigger { } See Using Attributes for Configuration for information about adding your own custom attibutes for other lifecycles. diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html old mode 100644 new mode 100755 index 6cf99c2..30d7f51 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Generic Types Previous Configuring Lifecycles @@ -91,9 +91,9 @@ Custom Lifecycles public class CustomLifecycle : ILifecycle { public static LifecycleObjectCache Cache = new LifecycleObjectCache(); public string Description { get { return "Custom"; } } public void EjectAll(ILifecycleContext context) { // Here you'd remove all the existing objects // from the cache and call IDisposable.Dispose() // as appropriate } public IObjectCache FindCache(ILifecycleContext context) { // using the context, "find" the appropriate // IObjectCache object return Cache; } } + public class CustomLifecycle : ILifecycle { public static LifecycleObjectCache Cache = new LifecycleObjectCache(); public string Description { get { return "Custom"; } } public void EjectAll(ILifecycleContext context) { // Here you'd remove all the existing objects // from the cache and call IDisposable.Dispose() // as appropriate } public IObjectCache FindCache(ILifecycleContext context) { // using the context, "find" the appropriate // IObjectCache object return Cache; } } Registering your custom lifecycle can be done like this: - public class UsingCustomLifecycle : Registry { public UsingCustomLifecycle() { // at the Plugin Type level For<IService>().LifecycleIs<CustomLifecycle>(); // at the Instance level For<IService>().Use<AService>() .LifecycleIs<CustomLifecycle>(); } } + public class UsingCustomLifecycle : Registry { public UsingCustomLifecycle() { // at the Plugin Type level For<IService>().LifecycleIs<CustomLifecycle>(); // at the Instance level For<IService>().Use<AService>() .LifecycleIs<CustomLifecycle>(); } } Most of the built in ILifecycle implementations use LifecycleObjectCache internally, but you may also need to create your own IObjectCache implementation. diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html old mode 100644 new mode 100755 index 12e404e..3879404 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Supported Lifecycles Previous The Container @@ -102,10 +102,10 @@ Object Lifecycles Motivation for Container Managed Scope In the bad old days, we used the infamous Singleton pattern as shown below for objects that really needed to be scoped as one single instance for the entire system: - public class EvilSingleton { public static readonly EvilSingleton Instance = new EvilSingleton(); private EvilSingleton() { } public void DoSomething() { // do something with the static data here } } public class EvilSingletonUser { public void DoWork() { EvilSingleton.Instance.DoSomething(); } } + public class EvilSingleton { public static readonly EvilSingleton Instance = new EvilSingleton(); private EvilSingleton() { } public void DoSomething() { // do something with the static data here } } public class EvilSingletonUser { public void DoWork() { EvilSingleton.Instance.DoSomething(); } } The code above isn't terribly difficult to write or understand, but using a Singleton has some negative effects on your code as explained in Singletons are Evil and my own writing at Chill out on the Singleton Fetish. Instead, let's just use StructureMap to handle the singleton scoping instead and rewrite the code sample above as: - public class SingletonService { } public class SingletonUser { public SingletonUser(SingletonService singleton) { } } public class SingletonScopeRegistry : Registry { public SingletonScopeRegistry() { For<SingletonService>().Singleton(); } } + public class SingletonService { } public class SingletonUser { public SingletonUser(SingletonService singleton) { } } public class SingletonScopeRegistry : Registry { public SingletonScopeRegistry() { For<SingletonService>().Singleton(); } } The big advantage to the second, StructureMap-managed singleton scoping is that my DependencyUser class does not have to have any knowledge of how the ISingletonDependency object is built and certainly no coupling to the hard Singleton mechanics from the first sample that was so harmful in the past. diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html old mode 100644 new mode 100755 index 16f47d1..afb5a14 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Configuring Lifecycles Previous Object Lifecycles @@ -105,32 +105,32 @@ Transient of the nested container itself. See Nested Containers (Per Request/Transaction) for more information. StructureMap's behavior for transient objects that implement IDisposable changed in 4.0 to introduce an "opt-in" tracking mode. Please see StructureMap and IDisposable for the details. The following unit test demonstrates how Transient lifecycles work in both root and nested containers. - [Fact] public void Transient() { var c = new Container(x => { x.For<IService>().Use<Service>().Transient(); }); // In a normal container, you get a new object // instance of the Service class in subsequent // requests c.GetInstance<IService>() .ShouldNotBeTheSameAs(c.GetInstance<IService>()) .ShouldNotBeTheSameAs(c.GetInstance<IService>()); // Within a nested container, 'Transient' now // means within the Nested Container. // A nested container is effectively one request using (var nested = c.GetNestedContainer()) { nested.GetInstance<IService>() .ShouldBeTheSameAs(nested.GetInstance<IService>()) .ShouldBeTheSameAs(nested.GetInstance<IService>()); } } + [Fact] public void Transient() { var c = new Container(x => { x.For<IService>().Use<Service>().Transient(); }); // In a normal container, you get a new object // instance of the Service class in subsequent // requests c.GetInstance<IService>() .ShouldNotBeTheSameAs(c.GetInstance<IService>()) .ShouldNotBeTheSameAs(c.GetInstance<IService>()); // Within a nested container, 'Transient' now // means within the Nested Container. // A nested container is effectively one request using (var nested = c.GetNestedContainer()) { nested.GetInstance<IService>() .ShouldBeTheSameAs(nested.GetInstance<IService>()) .ShouldBeTheSameAs(nested.GetInstance<IService>()); } } Also note that a transient dependency will be created exactly once in an object graph resolved from IContainer.GetInstance(Type). Imagine that you are building an object graph with various objects that all need to apply some work to a shared unit of work object (think NHibernate's ISession, Entity Framework's DbContext, RavenDb's IDocumentSession): - public interface IUnitOfWork { } public class DefaultUnitOfWork : IUnitOfWork { } public class Worker1 { public IUnitOfWork Uow { get; set; } public Worker1(IUnitOfWork uow) { Uow = uow; } } public class Worker2 { public IUnitOfWork Uow { get; set; } public Worker2(IUnitOfWork uow) { Uow = uow; } } public class WorkerCoordinator { public IUnitOfWork Uow { get; set; } public Worker1 Worker1 { get; set; } public Worker2 Worker2 { get; set; } public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2) { Uow = uow; Worker1 = worker1; Worker2 = worker2; } } [Fact] public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container() { var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); }); var coordinator = container.GetInstance<WorkerCoordinator>(); // The IUnitOfWork object instance is the same for // all the objects in the object graph that had // a constructor dependency on IUnitOfWork coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker1.Uow); coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); coordinator.Worker1.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); } + public interface IUnitOfWork { } public class DefaultUnitOfWork : IUnitOfWork { } public class Worker1 { public IUnitOfWork Uow { get; set; } public Worker1(IUnitOfWork uow) { Uow = uow; } } public class Worker2 { public IUnitOfWork Uow { get; set; } public Worker2(IUnitOfWork uow) { Uow = uow; } } public class WorkerCoordinator { public IUnitOfWork Uow { get; set; } public Worker1 Worker1 { get; set; } public Worker2 Worker2 { get; set; } public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2) { Uow = uow; Worker1 = worker1; Worker2 = worker2; } } [Fact] public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container() { var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); }); var coordinator = container.GetInstance<WorkerCoordinator>(); // The IUnitOfWork object instance is the same for // all the objects in the object graph that had // a constructor dependency on IUnitOfWork coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker1.Uow); coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); coordinator.Worker1.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); } AlwaysUnique Very simply, using the AlwaysUnique means that a new object instance will be created every single time a configured Instance is either requested from a Container or as a dependency to another object. The AlwaysUnique lifecycle is a "fire and forget" operation as the object instances are neither tracked nor disposed by StructureMap. The StructureMap team strongly feels that the default lifecycle is appropriate in most cases and that the unique lifecycle is mostly useful for logging services as demonstrated in the StructureMap 3.1 announcement. - [Fact] public void Always_Unique() { var c = new Container(x => { x.For<IService>().Use<Service>().AlwaysUnique(); }); // In a normal container, you get a new object // instance of the Service class in subsequent // requests c.GetInstance<IService>() .ShouldNotBeTheSameAs(c.GetInstance<IService>()) .ShouldNotBeTheSameAs(c.GetInstance<IService>()); // Within a nested container, 'Transient' now // means within the Nested Container. // A nested container is effectively one request using (var nested = c.GetNestedContainer()) { nested.GetInstance<IService>() .ShouldNotBeTheSameAs(nested.GetInstance<IService>()) .ShouldNotBeTheSameAs(nested.GetInstance<IService>()); } // Even in a single request, var holder = c.GetInstance<ServiceUserHolder>(); holder.Service.ShouldNotBeTheSameAs(holder.User.Service); } + [Fact] public void Always_Unique() { var c = new Container(x => { x.For<IService>().Use<Service>().AlwaysUnique(); }); // In a normal container, you get a new object // instance of the Service class in subsequent // requests c.GetInstance<IService>() .ShouldNotBeTheSameAs(c.GetInstance<IService>()) .ShouldNotBeTheSameAs(c.GetInstance<IService>()); // Within a nested container, 'Transient' now // means within the Nested Container. // A nested container is effectively one request using (var nested = c.GetNestedContainer()) { nested.GetInstance<IService>() .ShouldNotBeTheSameAs(nested.GetInstance<IService>()) .ShouldNotBeTheSameAs(nested.GetInstance<IService>()); } // Even in a single request, var holder = c.GetInstance<ServiceUserHolder>(); holder.Service.ShouldNotBeTheSameAs(holder.User.Service); } Singleton StructureMap 3.0 fixed the dreaded singletons with nested container's bug that was so problematic in 2.6. - [Fact] public void singletons_are_disposed_when_the_container_is_disposed() { var container = new Container(_ => { _.ForSingletonOf<DisposableSingleton>(); }); // As a singleton-scoped object, every request for DisposableSingleton // will return the same object var singleton = container.GetInstance<DisposableSingleton>(); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.WasDisposed.ShouldBeFalse(); // now, dispose the Container container.Dispose(); // the SingletonThing scoped object should be disposed singleton.WasDisposed.ShouldBeTrue(); } + [Fact] public void singletons_are_disposed_when_the_container_is_disposed() { var container = new Container(_ => { _.ForSingletonOf<DisposableSingleton>(); }); // As a singleton-scoped object, every request for DisposableSingleton // will return the same object var singleton = container.GetInstance<DisposableSingleton>(); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.WasDisposed.ShouldBeFalse(); // now, dispose the Container container.Dispose(); // the SingletonThing scoped object should be disposed singleton.WasDisposed.ShouldBeTrue(); } Do note that objects created as the singleton scope will be disposed when the Container is disposed if they implement the IDisposable interface: - public interface IUnitOfWork { } public class DefaultUnitOfWork : IUnitOfWork { } public class Worker1 { public IUnitOfWork Uow { get; set; } public Worker1(IUnitOfWork uow) { Uow = uow; } } public class Worker2 { public IUnitOfWork Uow { get; set; } public Worker2(IUnitOfWork uow) { Uow = uow; } } public class WorkerCoordinator { public IUnitOfWork Uow { get; set; } public Worker1 Worker1 { get; set; } public Worker2 Worker2 { get; set; } public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2) { Uow = uow; Worker1 = worker1; Worker2 = worker2; } } [Fact] public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container() { var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); }); var coordinator = container.GetInstance<WorkerCoordinator>(); // The IUnitOfWork object instance is the same for // all the objects in the object graph that had // a constructor dependency on IUnitOfWork coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker1.Uow); coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); coordinator.Worker1.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); } + public interface IUnitOfWork { } public class DefaultUnitOfWork : IUnitOfWork { } public class Worker1 { public IUnitOfWork Uow { get; set; } public Worker1(IUnitOfWork uow) { Uow = uow; } } public class Worker2 { public IUnitOfWork Uow { get; set; } public Worker2(IUnitOfWork uow) { Uow = uow; } } public class WorkerCoordinator { public IUnitOfWork Uow { get; set; } public Worker1 Worker1 { get; set; } public Worker2 Worker2 { get; set; } public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2) { Uow = uow; Worker1 = worker1; Worker2 = worker2; } } [Fact] public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container() { var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); }); var coordinator = container.GetInstance<WorkerCoordinator>(); // The IUnitOfWork object instance is the same for // all the objects in the object graph that had // a constructor dependency on IUnitOfWork coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker1.Uow); coordinator.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); coordinator.Worker1.Uow .ShouldBeTheSameAs(coordinator.Worker2.Uow); } ContainerScoped New in StructureMap 4.0 is the ContainerScoped lifecycle that was designed specifically for compliance with the new ASP.Net DNX adapter model. ContainerScoped in this case means that a registration will be built once per Container, such that the root container, any child or profile container, and every single nested container will build its own object instance. The acceptance test for ContainerScoped is shown below: - [Fact] public void container_scoping_with_root_child_and_nested_container() { var container = new Container(_ => { _.ForConcreteType<Disposable>().Configure.ContainerScoped(); }); var child = container.CreateChildContainer(); var nested = container.GetNestedContainer(); // Always the same object when requested from the root container var mainDisposable = container.GetInstance<Disposable>(); mainDisposable .ShouldBeTheSameAs(container.GetInstance<Disposable>()); // Always the same object when requested from a child container var childDisposable = child.GetInstance<Disposable>(); childDisposable .ShouldBeTheSameAs(child.GetInstance<Disposable>()); // Always the same object when requested from a nested container var nestedDisposable = nested.GetInstance<Disposable>(); nestedDisposable .ShouldBeTheSameAs(nested.GetInstance<Disposable>()); // It should be a different object instance for // all three containers mainDisposable .ShouldNotBeTheSameAs(childDisposable); mainDisposable .ShouldNotBeTheSameAs(nestedDisposable); childDisposable .ShouldNotBeTheSameAs(nestedDisposable); // When the nested container is disposed, // it should dispose all the container scoped objects, // but not impact the other containers nested.Dispose(); nestedDisposable.WasDisposed.ShouldBeTrue(); childDisposable.WasDisposed.ShouldBeFalse(); mainDisposable.WasDisposed.ShouldBeFalse(); // Same for the child container child.Dispose(); childDisposable.WasDisposed.ShouldBeTrue(); mainDisposable.WasDisposed.ShouldBeFalse(); // Same for the main container container.Dispose(); mainDisposable.WasDisposed.ShouldBeTrue(); } + [Fact] public void container_scoping_with_root_child_and_nested_container() { var container = new Container(_ => { _.ForConcreteType<Disposable>().Configure.ContainerScoped(); }); var child = container.CreateChildContainer(); var nested = container.GetNestedContainer(); // Always the same object when requested from the root container var mainDisposable = container.GetInstance<Disposable>(); mainDisposable .ShouldBeTheSameAs(container.GetInstance<Disposable>()); // Always the same object when requested from a child container var childDisposable = child.GetInstance<Disposable>(); childDisposable .ShouldBeTheSameAs(child.GetInstance<Disposable>()); // Always the same object when requested from a nested container var nestedDisposable = nested.GetInstance<Disposable>(); nestedDisposable .ShouldBeTheSameAs(nested.GetInstance<Disposable>()); // It should be a different object instance for // all three containers mainDisposable .ShouldNotBeTheSameAs(childDisposable); mainDisposable .ShouldNotBeTheSameAs(nestedDisposable); childDisposable .ShouldNotBeTheSameAs(nestedDisposable); // When the nested container is disposed, // it should dispose all the container scoped objects, // but not impact the other containers nested.Dispose(); nestedDisposable.WasDisposed.ShouldBeTrue(); childDisposable.WasDisposed.ShouldBeFalse(); mainDisposable.WasDisposed.ShouldBeFalse(); // Same for the child container child.Dispose(); childDisposable.WasDisposed.ShouldBeTrue(); mainDisposable.WasDisposed.ShouldBeFalse(); // Same for the main container container.Dispose(); mainDisposable.WasDisposed.ShouldBeTrue(); } ThreadLocal The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test: - public class ThreadLocalStorageLifecycleTester { public ThreadLocalStorageLifecycleTester() { _lifecycle = new ThreadLocalStorageLifecycle(); container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red"))); } private ThreadLocalStorageLifecycle _lifecycle; private ColorRule _rule1; private ColorRule _rule2; private ColorRule _rule3; private Container container; private void findRule1() { _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule1.ShouldBeTheSameAs(rule); } private void findRule2() { _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule2.ShouldBeTheSameAs(rule); } private void findRule3() { _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); } [Fact] public void object_has_been_created() { container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse(); var r1 = container.GetInstance<Rule>(); container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue(); } [Fact] public void FindUniqueInstancePerThread() { var t1 = new Thread(findRule1); var t2 = new Thread(findRule2); var t3 = new Thread(findRule3); t1.Start(); t2.Start(); t3.Start(); t1.Join(); t2.Join(); t3.Join(); _rule1.ShouldNotBeTheSameAs(_rule2); _rule1.ShouldNotBeTheSameAs(_rule3); _rule2.ShouldNotBeTheSameAs(_rule3); (_rule1.ID != _rule2.ID).ShouldBeTrue(); (_rule1.ID != _rule3.ID).ShouldBeTrue(); (_rule2.ID != _rule3.ID).ShouldBeTrue(); } } + public class ThreadLocalStorageLifecycleTester { public ThreadLocalStorageLifecycleTester() { _lifecycle = new ThreadLocalStorageLifecycle(); container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red"))); } private ThreadLocalStorageLifecycle _lifecycle; private ColorRule _rule1; private ColorRule _rule2; private ColorRule _rule3; private Container container; private void findRule1() { _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule1.ShouldBeTheSameAs(rule); } private void findRule2() { _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule2.ShouldBeTheSameAs(rule); } private void findRule3() { _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); } [Fact] public void object_has_been_created() { container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse(); var r1 = container.GetInstance<Rule>(); container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue(); } [Fact] public void FindUniqueInstancePerThread() { var t1 = new Thread(findRule1); var t2 = new Thread(findRule2); var t3 = new Thread(findRule3); t1.Start(); t2.Start(); t3.Start(); t1.Join(); t2.Join(); t3.Join(); _rule1.ShouldNotBeTheSameAs(_rule2); _rule1.ShouldNotBeTheSameAs(_rule3); _rule2.ShouldNotBeTheSameAs(_rule3); (_rule1.ID != _rule2.ID).ShouldBeTrue(); (_rule1.ID != _rule3.ID).ShouldBeTrue(); (_rule2.ID != _rule3.ID).ShouldBeTrue(); } } Legacy ASP.Net Lifecycles The StructureMap team strongly recommends against using the old ASP.Net lifecycles. Most modern web frameworks in .Net will use a Nested Container per request to accomplish the same scoping in a better way. diff --git a/quickstart/index.html b/quickstart/index.html old mode 100644 new mode 100755 index f0be9d8..4e392b2 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Glossary Previous Roadmap @@ -108,11 +108,11 @@ Main Usage
So let's say that you have a simple object model like so: - public interface IBar { } public class Bar : IBar { } public interface IFoo { } public class Foo : IFoo { public IBar Bar { get; private set; } public Foo(IBar bar) { Bar = bar; } } + public interface IBar { } public class Bar : IBar { } public interface IFoo { } public class Foo : IFoo { public IBar Bar { get; private set; } public Foo(IBar bar) { Bar = bar; } } You could explicitly build a StructureMap Container object to build these types like this: - // Configure and build a brand new // StructureMap Container object var container = new Container(_ => { _.For<IFoo>().Use<Foo>(); _.For<IBar>().Use<Bar>(); }); // Now, resolve a new object instance of IFoo container.GetInstance<IFoo>() // should be type Foo .ShouldBeOfType<Foo>() // and the IBar dependency too .Bar.ShouldBeOfType<Bar>(); + // Configure and build a brand new // StructureMap Container object var container = new Container(_ => { _.For<IFoo>().Use<Foo>(); _.For<IBar>().Use<Bar>(); }); // Now, resolve a new object instance of IFoo container.GetInstance<IFoo>() // should be type Foo .ShouldBeOfType<Foo>() // and the IBar dependency too .Bar.ShouldBeOfType<Bar>(); or utilize StructureMap's type scanning conventions to configure the relationships and do the same thing like this: - var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.WithDefaultConventions(); }); }); container.GetInstance<IFoo>() .ShouldBeOfType<Foo>() .Bar.ShouldBeOfType<Bar>(); + var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.WithDefaultConventions(); }); }); container.GetInstance<IFoo>() .ShouldBeOfType<Foo>() .Bar.ShouldBeOfType<Bar>(); Integrating StructureMap within your application At some point you will want to integrate StructureMap into your application. Whether you are using Windows Presentation Foundation (WPF), FubuMVC, ASP.NET WebForms, ASP.NET MVC or any other framework or technology, you will have to do some sort of plumbing and bootstrapping. Depending on the used technology or framework there can be important integration points that you will have to use to fully enable the power of StructureMap. While StructureMap doesn't provide integration support out of the box for all of the frameworks and technologies out there, we do find it important to help you get started with integrating StructureMap into your application. That said, StructureMap does provide integration support for FubuMVC (a web framework, which is part of the same family as StructureMap). diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100644 new mode 100755 index af0ad3c..1713609 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@
- + Next Resolving Services Previous Replace or Clear Out Previous Registrations @@ -97,7 +97,7 @@
Using Attributes for Configuration /// <summary> /// Base class for custom configuration attributes /// </summary> public abstract class StructureMapAttribute : Attribute { /// <summary> /// Override this method to apply a configuration change to an entire /// PluginFamily (every Instance of a certain PluginType) /// </summary> /// <param name="family"></param> public virtual void Alter(PluginFamily family) { } /// <summary> /// Make configuration alterations to a single IConfiguredInstance object /// </summary> /// <param name="instance"></param> public virtual void Alter(IConfiguredInstance instance) { } /// <summary> /// Apply configuration customization to a single setter property /// </summary> /// <param name="instance"></param> /// <param name="property"></param> public virtual void Alter(IConfiguredInstance instance, PropertyInfo property) { } /// <summary> /// Apply configuration customization for a single constructor parameter /// </summary> /// <param name="instance"></param> /// <param name="parameter"></param> public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter) { } } + /// <summary> /// Base class for custom configuration attributes /// </summary> public abstract class StructureMapAttribute : Attribute { /// <summary> /// Override this method to apply a configuration change to an entire /// PluginFamily (every Instance of a certain PluginType) /// </summary> /// <param name="family"></param> public virtual void Alter(PluginFamily family) { } /// <summary> /// Make configuration alterations to a single IConfiguredInstance object /// </summary> /// <param name="instance"></param> public virtual void Alter(IConfiguredInstance instance) { } /// <summary> /// Apply configuration customization to a single setter property /// </summary> /// <param name="instance"></param> /// <param name="property"></param> public virtual void Alter(IConfiguredInstance instance, PropertyInfo property) { } /// <summary> /// Apply configuration customization for a single constructor parameter /// </summary> /// <param name="instance"></param> /// <param name="parameter"></param> public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter) { } } There's a couple thing to note, here about this new attibute:
StructureMap internals are looking for any attribute of the base class. Attributes that affect types are read and applied early, @@ -107,20 +107,20 @@ Using Attributes for Configuration Attribute Targeting Plugin Type or Concrete Type Take the new [Singleton] attribute shown below: - [AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface)] public class SingletonAttribute : StructureMapAttribute { // This method will affect the configuration for the // entire plugin type public override void Alter(PluginFamily family) { family.SetLifecycleTo<SingletonLifecycle>(); } // This method will affect single registrations public override void Alter(IConfiguredInstance instance) { instance.SetLifecycleTo<SingletonLifecycle>(); } } + [AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface)] public class SingletonAttribute : StructureMapAttribute { // This method will affect the configuration for the // entire plugin type public override void Alter(PluginFamily family) { family.SetLifecycleTo<SingletonLifecycle>(); } // This method will affect single registrations public override void Alter(IConfiguredInstance instance) { instance.SetLifecycleTo<SingletonLifecycle>(); } } This new attribute can be used on either the plugin type (typically an interface) or on a concrete type to make an individual type registration be a singleton. You can see the usage on some types below: - [Singleton] // ALL Instance's of ITeamCache will be singletons by default public interface ITeamCache { } public class TeamCache : ITeamCache { } public class OtherTeamCache : ITeamCache { } public interface ITeam { } public class Chargers : ITeam { } [Singleton] // This specific type will be a singleton public class Chiefs : ITeam { } + [Singleton] // ALL Instance's of ITeamCache will be singletons by default public interface ITeamCache { } public class TeamCache : ITeamCache { } public class OtherTeamCache : ITeamCache { } public interface ITeam { } public class Chargers : ITeam { } [Singleton] // This specific type will be a singleton public class Chiefs : ITeam { } Attribute Targeting Constructor Parameters or Setter Properties As an example, let's say that you want a new attribute type that can decorate either properties or constructor parameters to say "use the value from the old .Net AppSettings collection as the value for this property/parameter." To build that new custom attribute, you would create a new attribute that subclasses StructureMapAttribute and override the two methods shown below: - public class AppSettingAttribute : StructureMapAttribute { private readonly string _key; public AppSettingAttribute(string key) { _key = key; } public override void Alter(IConfiguredInstance instance, PropertyInfo property) { var value = System.Configuration.ConfigurationManager.AppSettings[_key]; instance.Dependencies.AddForProperty(property, value); } public override void Alter(IConfiguredInstance instance, ParameterInfo parameter) { var value = System.Configuration.ConfigurationManager.AppSettings[_key]; instance.Dependencies.AddForConstructorParameter(parameter, value); } } + public class AppSettingAttribute : StructureMapAttribute { private readonly string _key; public AppSettingAttribute(string key) { _key = key; } public override void Alter(IConfiguredInstance instance, PropertyInfo property) { var value = System.Configuration.ConfigurationManager.AppSettings[_key]; instance.Dependencies.AddForProperty(property, value); } public override void Alter(IConfiguredInstance instance, ParameterInfo parameter) { var value = System.Configuration.ConfigurationManager.AppSettings[_key]; instance.Dependencies.AddForConstructorParameter(parameter, value); } } To test out the new attribute above, say we have a concrete type like this one that we decorate with the new [AppSetting] attribute: - public class AppSettingTarget { public string Name { get; set; } [AppSetting("homestate")] public string HomeState { get; set; } public AppSettingTarget([AppSetting("name")]string name) { Name = name; } } + public class AppSettingTarget { public string Name { get; set; } [AppSetting("homestate")] public string HomeState { get; set; } public AppSettingTarget([AppSetting("name")]string name) { Name = name; } } The following unit test demonstrates our new custom [AppSetting] attribute in action: - [Fact] public void using_parameter_and_property_attibutes() { System.Configuration.ConfigurationManager.AppSettings["name"] = "Jeremy"; System.Configuration.ConfigurationManager.AppSettings["homestate"] = "Missouri"; System.Configuration.ConfigurationManager.AppSettings["name"].ShouldBe("Jeremy"); var container = new Container(); var target = container.GetInstance<AppSettingTarget>(); target.Name.ShouldBe("Jeremy"); target.HomeState.ShouldBe("Missouri"); Debug.WriteLine(container.Model.For<AppSettingTarget>().Default.DescribeBuildPlan()); } + [Fact] public void using_parameter_and_property_attibutes() { System.Configuration.ConfigurationManager.AppSettings["name"] = "Jeremy"; System.Configuration.ConfigurationManager.AppSettings["homestate"] = "Missouri"; System.Configuration.ConfigurationManager.AppSettings["name"].ShouldBe("Jeremy"); var container = new Container(); var target = container.GetInstance<AppSettingTarget>(); target.Name.ShouldBe("Jeremy"); target.HomeState.ShouldBe("Missouri"); Debug.WriteLine(container.Model.For<AppSettingTarget>().Default.DescribeBuildPlan()); } The build plan for AppSettingTarget is determined by the active StructureMap container to be this:
diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html old mode 100644 new mode 100755 index c62e566..6838a65 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@ - + Next Working with IConfiguredInstance Previous Inline Dependencies @@ -97,7 +97,7 @@ Auto-Registration and Conventions Type Scanning Diagnostics for help in understanding the assembly scanning behavior in your system. Registry.Scan() Assembly scanning operations are defined by the Registry.Scan() method demonstrated below: - public class BasicScanning : Registry { public BasicScanning() { Scan(_ => { // Declare which assemblies to scan _.Assembly("StructureMap.Testing"); _.AssemblyContainingType<IWidget>(); // Filter types _.Exclude(type => type.Name.Contains("Bad")); // A custom registration convention _.Convention<MySpecialRegistrationConvention>(); // Built in registration conventions _.AddAllTypesOf<IWidget>().NameBy(x => x.Name.Replace("Widget", "")); _.WithDefaultConventions(); }); } } + public class BasicScanning : Registry { public BasicScanning() { Scan(_ => { // Declare which assemblies to scan _.Assembly("StructureMap.Testing"); _.AssemblyContainingType<IWidget>(); // Filter types _.Exclude(type => type.Name.Contains("Bad")); // A custom registration convention _.Convention<MySpecialRegistrationConvention>(); // Built in registration conventions _.AddAllTypesOf<IWidget>().NameBy(x => x.Name.Replace("Widget", "")); _.WithDefaultConventions(); }); } } Please note (because I've been asked this several times over the years) that each call to Registry.Scan() is an entirely atomic operation that has no impact on previous or subsequent calls. Any given call to Registry.Scan() consists of three different things: @@ -110,21 +110,21 @@ Scan the Calling Assembly registry is placed in. Note if you have other registries, StructureMap will not automatically find them. - [Fact] public void scan_but_ignore_registries_by_default() { Scan(x => { x.TheCallingAssembly(); }); TestingRegistry.WasUsed.ShouldBeFalse(); } + [Fact] public void scan_but_ignore_registries_by_default() { Scan(x => { x.TheCallingAssembly(); }); TestingRegistry.WasUsed.ShouldBeFalse(); } Note that this method is an extension method in the StructureMap.Net4 assembly and cannot be used if you target PCL compliance. Scan for Registries StructureMap can automatically include other registries with theLookForRegistries method. - [Fact] public void Search_for_registries_when_explicitly_told() { Scan(x => { x.TheCallingAssembly(); x.LookForRegistries(); }); TestingRegistry.WasUsed.ShouldBeTrue(); } + [Fact] public void Search_for_registries_when_explicitly_told() { Scan(x => { x.TheCallingAssembly(); x.LookForRegistries(); }); TestingRegistry.WasUsed.ShouldBeTrue(); } As of 4.0, this operation is now recursive and StructureMap has always been idempotent about adding Registry types Search for Assemblies on the File System StructureMap provides facilities for registering types by finding assemblies in the application bin path: - [Fact] public void scan_all_assemblies_in_a_folder() { Scan(x => x.AssembliesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory() { Scan(x => x.AssembliesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } + [Fact] public void scan_all_assemblies_in_a_folder() { Scan(x => x.AssembliesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory() { Scan(x => x.AssembliesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } Do note that StructureMap 4.0 does not search for .exe files in the assembly search. The StructureMap team felt this was problematic and "nobody would ever actually want to do that." We were wrong, and due to many user requests, you can now opt in to scanning .exe files with a new public method on AssemblyScanner shown below: - [Fact] public void scan_all_assemblies_in_a_folder_including_exe() { Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory_including_exe() { Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } + [Fact] public void scan_all_assemblies_in_a_folder_including_exe() { Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory_including_exe() { Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } Do be aware that while this technique is very powerful for extensibility, it's been extremely problematic for some folks in the past. The StructureMap team's recommendation for using this feature is to: @@ -141,26 +141,26 @@ Excluding Types a type within that assembly. Excluding additional types or namespaces is as easy as calling the corresponding method again. - [Fact] public void use_a_single_exclude_of_type() { Scan(x => { x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); x.ExcludeType<ITypeThatHasAttributeButIsNotInRegistry>(); }); shouldHaveFamily<IInterfaceInWidget5>(); shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>(); } [Fact] public void use_a_single_exclude2() { Scan(x => { x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); x.ExcludeNamespace("StructureMap.Testing.Widget5"); }); shouldNotHaveFamily<IInterfaceInWidget5>(); shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>(); } [Fact] public void use_a_single_exclude3() { Scan(x => { x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); x.ExcludeNamespaceContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); }); shouldNotHaveFamily<IInterfaceInWidget5>(); shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>(); } + [Fact] public void use_a_single_exclude_of_type() { Scan(x => { x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); x.ExcludeType<ITypeThatHasAttributeButIsNotInRegistry>(); }); shouldHaveFamily<IInterfaceInWidget5>(); shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>(); } [Fact] public void use_a_single_exclude2() { Scan(x => { x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); x.ExcludeNamespace("StructureMap.Testing.Widget5"); }); shouldNotHaveFamily<IInterfaceInWidget5>(); shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>(); } [Fact] public void use_a_single_exclude3() { Scan(x => { x.AssemblyContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); x.ExcludeNamespaceContainingType<ITypeThatHasAttributeButIsNotInRegistry>(); }); shouldNotHaveFamily<IInterfaceInWidget5>(); shouldNotHaveFamily<ITypeThatHasAttributeButIsNotInRegistry>(); } Custom Registration Conventions It's just not possible (or desirable) for StructureMap to include every possible type of auto registration convention users might want, but that's okay because StructureMap allows you to create and use your own conventions through the IRegistrationConvention interface: - public interface IRegistrationConvention { void ScanTypes(TypeSet types, Registry registry); } + public interface IRegistrationConvention { void ScanTypes(TypeSet types, Registry registry); } Let's say that you'd like a custom convention that just registers a concrete type against all the interfaces that it implements. You could then build a custom IRegistrationConvention class like the following example: - public interface IFoo { } public interface IBar { } public interface IBaz { } public class BusyGuy : IFoo, IBar, IBaz { } // Custom IRegistrationConvention public class AllInterfacesConvention : IRegistrationConvention { public void ScanTypes(TypeSet types, Registry registry) { // Only work on concrete types types.FindTypes(TypeClassification.Concretes | TypeClassification.Closed).Each(type => { // Register against all the interfaces implemented // by this concrete class type.GetInterfaces().Each(@interface => registry.For(@interface).Use(type)); }); } } [Fact] public void use_custom_registration_convention() { var container = new Container(_ => { _.Scan(x => { // You're probably going to want to tightly filter // the Type's that are applicable to avoid unwanted // registrations x.TheCallingAssembly(); x.IncludeNamespaceContainingType<BusyGuy>(); // Register the custom policy x.Convention<AllInterfacesConvention>(); }); }); container.GetInstance<IFoo>().ShouldBeOfType<BusyGuy>(); container.GetInstance<IBar>().ShouldBeOfType<BusyGuy>(); container.GetInstance<IBaz>().ShouldBeOfType<BusyGuy>(); } + public interface IFoo { } public interface IBar { } public interface IBaz { } public class BusyGuy : IFoo, IBar, IBaz { } // Custom IRegistrationConvention public class AllInterfacesConvention : IRegistrationConvention { public void ScanTypes(TypeSet types, Registry registry) { // Only work on concrete types types.FindTypes(TypeClassification.Concretes | TypeClassification.Closed).Each(type => { // Register against all the interfaces implemented // by this concrete class type.GetInterfaces().Each(@interface => registry.For(@interface).Use(type)); }); } } [Fact] public void use_custom_registration_convention() { var container = new Container(_ => { _.Scan(x => { // You're probably going to want to tightly filter // the Type's that are applicable to avoid unwanted // registrations x.TheCallingAssembly(); x.IncludeNamespaceContainingType<BusyGuy>(); // Register the custom policy x.Convention<AllInterfacesConvention>(); }); }); container.GetInstance<IFoo>().ShouldBeOfType<BusyGuy>(); container.GetInstance<IBar>().ShouldBeOfType<BusyGuy>(); container.GetInstance<IBaz>().ShouldBeOfType<BusyGuy>(); } The Default ISomething/Something Convention The "default" convention simply tries to connect concrete classes to interfaces using the I[Something]/[Something] naming convention as shown in this sample: - public interface ISpaceship { } public class Spaceship : ISpaceship { } public interface IRocket { } public class Rocket : IRocket { } [Fact] public void default_scanning_in_action() { var container = new Container(_ => { _.Scan(x => { x.Assembly("StructureMap.Testing"); x.WithDefaultConventions(); }); }); container.GetInstance<ISpaceship>().ShouldBeOfType<Spaceship>(); container.GetInstance<IRocket>().ShouldBeOfType<Rocket>(); } + public interface ISpaceship { } public class Spaceship : ISpaceship { } public interface IRocket { } public class Rocket : IRocket { } [Fact] public void default_scanning_in_action() { var container = new Container(_ => { _.Scan(x => { x.Assembly("StructureMap.Testing"); x.WithDefaultConventions(); }); }); container.GetInstance<ISpaceship>().ShouldBeOfType<Spaceship>(); container.GetInstance<IRocket>().ShouldBeOfType<Rocket>(); } The StructureMap team contains some VB6 veterans who hate Hungarian Notation, but can't shake the "I" nomenclature. Registering the Single Implementation of an Interface To tell StructureMap to automatically register any interface that only has one concrete implementation, use this method: - public interface ISong { } public class TheOnlySong : ISong { } [Fact] public void only_implementation() { var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.SingleImplementationsOfInterface(); }); }); container.GetInstance<ISong>() .ShouldBeOfType<TheOnlySong>(); } + public interface ISong { } public class TheOnlySong : ISong { } [Fact] public void only_implementation() { var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.SingleImplementationsOfInterface(); }); }); container.GetInstance<ISong>() .ShouldBeOfType<TheOnlySong>(); } Register all Concrete Types of an Interface To add all concrete types that can be cast to a named plugin type, use this syntax: - public interface IFantasySeries { } public class WheelOfTime : IFantasySeries { } public class GameOfThrones : IFantasySeries { } public class BlackCompany : IFantasySeries { } [Fact] public void register_all_types_of_an_interface() { var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.AddAllTypesOf<IFantasySeries>(); // or x.AddAllTypesOf(typeof(IFantasySeries)) .NameBy(type => type.Name.ToLower()); }); }); container.Model.For<IFantasySeries>() .Instances.Select(x => x.ReturnedType) .OrderBy(x => x.Name) .ShouldHaveTheSameElementsAs(typeof(BlackCompany), typeof(GameOfThrones), typeof(WheelOfTime)); } + public interface IFantasySeries { } public class WheelOfTime : IFantasySeries { } public class GameOfThrones : IFantasySeries { } public class BlackCompany : IFantasySeries { } [Fact] public void register_all_types_of_an_interface() { var container = new Container(_ => { _.Scan(x => { x.TheCallingAssembly(); x.AddAllTypesOf<IFantasySeries>(); // or x.AddAllTypesOf(typeof(IFantasySeries)) .NameBy(type => type.Name.ToLower()); }); }); container.Model.For<IFantasySeries>() .Instances.Select(x => x.ReturnedType) .OrderBy(x => x.Name) .ShouldHaveTheSameElementsAs(typeof(BlackCompany), typeof(GameOfThrones), typeof(WheelOfTime)); } Note, "T" does not have to be an interface, it's all based on the ability to cast a concrete type to the "T" Generic Types See Generic Types for an example of using the ConnectImplementationsToTypesClosing @@ -168,7 +168,7 @@ Generic Types Register Concrete Types against the First Interface The last built in registration convention is a mechanism to register all concrete types that implement at least one interface against the first interface that they implement. - container = new Container(x => { x.Scan(o => { o.TheCallingAssembly(); o.RegisterConcreteTypesAgainstTheFirstInterface(); o.Exclude(t => t.CanBeCastTo(typeof(IGateway))); }); }); + container = new Container(x => { x.Scan(o => { o.TheCallingAssembly(); o.RegisterConcreteTypesAgainstTheFirstInterface(); o.Exclude(t => t.CanBeCastTo(typeof(IGateway))); }); }); diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html old mode 100644 new mode 100755 index 5576737..a9ea947 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@ - + Next On Missing Family Policies Previous Construction Policies @@ -93,7 +93,7 @@ Changing Configuration at Runtime Use the technique shown here with caution. If you need to add or change configuration to an existing StructureMap Container object, you can use the IContainer.Configure() method to add or change your container at runtime as shown below: - [Fact] public void change_default_in_an_existing_container() { var container = new Container(x => { x.For<IFoo>().Use<AFoo>(); }); container.GetInstance<IFoo>().ShouldBeOfType<AFoo>(); // Now, change the container configuration container.Configure(x => x.For<IFoo>().Use<BFoo>()); // The default of IFoo is now different container.GetInstance<IFoo>().ShouldBeOfType<BFoo>(); // or use the Inject method that's just syntactical // sugar for replacing the default of one type at a time container.Inject<IFoo>(new CFoo()); container.GetInstance<IFoo>().ShouldBeOfType<CFoo>(); } + [Fact] public void change_default_in_an_existing_container() { var container = new Container(x => { x.For<IFoo>().Use<AFoo>(); }); container.GetInstance<IFoo>().ShouldBeOfType<AFoo>(); // Now, change the container configuration container.Configure(x => x.For<IFoo>().Use<BFoo>()); // The default of IFoo is now different container.GetInstance<IFoo>().ShouldBeOfType<BFoo>(); // or use the Inject method that's just syntactical // sugar for replacing the default of one type at a time container.Inject<IFoo>(new CFoo()); container.GetInstance<IFoo>().ShouldBeOfType<CFoo>(); } Best Practices First off, the best advice on this functionality is don't use it outside of testing scenarios on the root container. The Configure() method has to use a threading lock around the internal object model of a StructureMap container and can cause serious contention at runtime if you try to override services in the main application controller. Some frameworks (looking at you NancyFx) have abused this functionality quite badly in the past and the result was not pretty.
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100644 new mode 100755 index 29eacdf..0f7b119 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@
- + Next Using Attributes for Configuration Previous Registering Existing Objects @@ -106,9 +106,9 @@
Replace or Clear Out Previous Registrations IWidget service to run. For an important client, they want to deploy our system with a special version, so we will create a new StructureMap Registry to apply their specific registrations using the ClearAll() mechanism to insure that the important client gets their way: - public class ImportantClientWidget : IWidget { } public class ImportantClientServices : Registry { public ImportantClientServices() { For<IWidget>().ClearAll().Use<ImportantClientWidget>(); } } + public class ImportantClientWidget : IWidget { } public class ImportantClientServices : Registry { public ImportantClientServices() { For<IWidget>().ClearAll().Use<ImportantClientWidget>(); } } In usage, the ClearAll() stomps all over the default registration before adding their own: - [Fact] public void clear_all_in_action() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.IncludeRegistry<ImportantClientServices>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<ImportantClientWidget>(); Debug.WriteLine(container.WhatDoIHave(pluginType: typeof(IWidget))); } + [Fact] public void clear_all_in_action() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.IncludeRegistry<ImportantClientServices>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<ImportantClientWidget>(); Debug.WriteLine(container.WhatDoIHave(pluginType: typeof(IWidget))); } If you were to check the WhatDoIHave() view for IWidget, you would see only the ImportantClientWidget: ============================================================================================================================================== diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100644 new mode 100755 index 45fe8c8..469ac69 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Construction Policies Previous Auto-Registration and Conventions @@ -95,21 +95,21 @@ Working with IConfiguredInstance Registry DSL fluent interface provides the main way of explicitly configuring concrete type creation, the IConfiguredInstance interface is meant to support conventional registration, configuration attributes, and construction policies. - /// <summary> /// Represents a configured Instance object that /// is built by StructureMap directly by calling /// constructor functions and property setters /// </summary> public interface IConfiguredInstance { /// <summary> /// The Instance name /// </summary> string Name { get; set; } /// <summary> /// The actual concrete type built by this Instance /// </summary> Type PluggedType { get; } /// <summary> /// The explicitly configured inline dependencies that override /// auto-wiring /// </summary> DependencyCollection Dependencies { get; } /// <summary> /// Add an interceptor to only this Instance /// </summary> /// <param name="interceptor"></param> void AddInterceptor(IInterceptor interceptor); /// <summary> /// Set the lifecycle of only this Instance to the ILifecycle type. /// </summary> /// <typeparam name="T"></typeparam> /// <example> /// SetLifecycleTo<SingletonLifecycle>() /// </example> void SetLifecycleTo<T>() where T : ILifecycle, new(); /// <summary> /// Set the lifecycle of only this Instance to a certain lifecycle /// </summary> /// <param name="lifecycle"></param> void SetLifecycleTo(ILifecycle lifecycle); /// <summary> /// The current Lifecycle that will be used for this Instance /// </summary> ILifecycle Lifecycle { get; } /// <summary> /// Explicitly choose a constructor /// </summary> ConstructorInfo Constructor { get; set; } /// <summary> /// Has a build plan already been created for this instance? /// </summary> /// <returns></returns> bool HasBuildPlan(); /// <summary> /// Clears out any cached IBuildPlan for this Instance. /// </summary> void ClearBuildPlan(); } + /// <summary> /// Represents a configured Instance object that /// is built by StructureMap directly by calling /// constructor functions and property setters /// </summary> public interface IConfiguredInstance { /// <summary> /// The Instance name /// </summary> string Name { get; set; } /// <summary> /// The actual concrete type built by this Instance /// </summary> Type PluggedType { get; } /// <summary> /// The explicitly configured inline dependencies that override /// auto-wiring /// </summary> DependencyCollection Dependencies { get; } /// <summary> /// Add an interceptor to only this Instance /// </summary> /// <param name="interceptor"></param> void AddInterceptor(IInterceptor interceptor); /// <summary> /// Set the lifecycle of only this Instance to the ILifecycle type. /// </summary> /// <typeparam name="T"></typeparam> /// <example> /// SetLifecycleTo<SingletonLifecycle>() /// </example> void SetLifecycleTo<T>() where T : ILifecycle, new(); /// <summary> /// Set the lifecycle of only this Instance to a certain lifecycle /// </summary> /// <param name="lifecycle"></param> void SetLifecycleTo(ILifecycle lifecycle); /// <summary> /// The current Lifecycle that will be used for this Instance /// </summary> ILifecycle Lifecycle { get; } /// <summary> /// Explicitly choose a constructor /// </summary> ConstructorInfo Constructor { get; set; } /// <summary> /// Has a build plan already been created for this instance? /// </summary> /// <returns></returns> bool HasBuildPlan(); /// <summary> /// Clears out any cached IBuildPlan for this Instance. /// </summary> void ClearBuildPlan(); } Changing the Instance Lifecycle You can override the lifecycle of a single IConfiguredInstance by calling the LifecycleIs() methods and either supplying a type of ILifecycle or an ILifecycle object. As a quick helper, there are also extension methods for common lifecycles: - IConfiguredInstance instance = new ConfiguredInstance(typeof(WidgetHolder)); // Use the SingletonThing lifecycle instance.Singleton(); // or supply an ILifecycle type instance.SetLifecycleTo<ThreadLocalStorageLifecycle>(); // or supply an ILifecycle object instance.SetLifecycleTo(new Lifecycles_Samples.MyCustomLifecycle()); // or override to the default "transient" lifecycle instance.DefaultLifecycle(); + IConfiguredInstance instance = new ConfiguredInstance(typeof(WidgetHolder)); // Use the SingletonThing lifecycle instance.Singleton(); // or supply an ILifecycle type instance.SetLifecycleTo<ThreadLocalStorageLifecycle>(); // or supply an ILifecycle object instance.SetLifecycleTo(new Lifecycles_Samples.MyCustomLifecycle()); // or override to the default "transient" lifecycle instance.DefaultLifecycle(); Reflecting over Constructor Parameters To find the constructor function parameters of an IConfiguredInstance, just use this syntax (it's just .Net Reflection): - public class GuyWithArguments { public GuyWithArguments(IWidget widget, Rule rule) { } } [Fact] public void reflecting_over_constructor_args() { IConfiguredInstance instance = new SmartInstance<GuyWithArguments>() // I'm just forcing it to assign the constructor function .SelectConstructor(() => new GuyWithArguments(null, null)); instance.Constructor.GetParameters().Select(x => x.Name) .ShouldHaveTheSameElementsAs("widget", "rule"); } + public class GuyWithArguments { public GuyWithArguments(IWidget widget, Rule rule) { } } [Fact] public void reflecting_over_constructor_args() { IConfiguredInstance instance = new SmartInstance<GuyWithArguments>() // I'm just forcing it to assign the constructor function .SelectConstructor(() => new GuyWithArguments(null, null)); instance.Constructor.GetParameters().Select(x => x.Name) .ShouldHaveTheSameElementsAs("widget", "rule"); } The constructor function selection process takes place as the very first step in creating a build plan and will be available in any kind of construction policy or configuration attribute on parameters or properties. Reflecting over Setter Properties There's a helper extension method off of `IConfiguredInstance' for finding all of the settable properties that StructureMap can work with as shown below: - public class GuyWithProperties { public IWidget Widget { get; set; } public Rule Rule { get; private set; } } [Fact] public void get_settable_properties() { IConfiguredInstance instance = new ConfiguredInstance(typeof(GuyWithProperties)); instance.SettableProperties() .Single().Name.ShouldBe("Widget"); } + public class GuyWithProperties { public IWidget Widget { get; set; } public Rule Rule { get; private set; } } [Fact] public void get_settable_properties() { IConfiguredInstance instance = new ConfiguredInstance(typeof(GuyWithProperties)); instance.SettableProperties() .Single().Name.ShouldBe("Widget"); } Working with Dependencies The IConfiguredInstance.Dependencies property is a collection of Argument objects that model inline dependencies. A single Argument can refer to a public property or the parameter in a constructor function and consists of: @@ -136,15 +136,15 @@ Add a Dependency for a Setter Pr Dependencies.AddForProperty() method as a convenience. For the actual value of the dependency, it needs to either be an object that can be cast to the property type or an Instance object that returns a type that can be cast to the property type. With a value: - [Fact] public void dependency_with_setter_with_value() { var instance = new ConfiguredInstance(typeof(GuyWithProperties)); var prop = instance.PluggedType.GetProperty("Widget"); var myWidget = new ColorWidget("red"); instance.Dependencies.AddForProperty(prop, myWidget); var container = new Container(); container.GetInstance<GuyWithProperties>(instance) .Widget.ShouldBeTheSameAs(myWidget); } + [Fact] public void dependency_with_setter_with_value() { var instance = new ConfiguredInstance(typeof(GuyWithProperties)); var prop = instance.PluggedType.GetProperty("Widget"); var myWidget = new ColorWidget("red"); instance.Dependencies.AddForProperty(prop, myWidget); var container = new Container(); container.GetInstance<GuyWithProperties>(instance) .Widget.ShouldBeTheSameAs(myWidget); } With an Instance for the dependency value: - [Fact] public void dependency_with_setter_with_instance() { var instance = new ConfiguredInstance(typeof(GuyWithProperties)); var prop = instance.PluggedType.GetProperty("Widget"); var dependency = new SmartInstance<AWidget>(); instance.Dependencies.AddForProperty(prop, dependency); var container = new Container(); container.GetInstance<GuyWithProperties>(instance) .Widget.ShouldBeOfType<AWidget>(); } + [Fact] public void dependency_with_setter_with_instance() { var instance = new ConfiguredInstance(typeof(GuyWithProperties)); var prop = instance.PluggedType.GetProperty("Widget"); var dependency = new SmartInstance<AWidget>(); instance.Dependencies.AddForProperty(prop, dependency); var container = new Container(); container.GetInstance<GuyWithProperties>(instance) .Widget.ShouldBeOfType<AWidget>(); } Add a Dependency for a Constructor Parameter Likewise, you can add a dependency for a specific constructor parameter as either the actual value or an Instance object with the AddForConstructorParameter helper method: - public class GuyWithDatabaseConnection { public string ConnectionString { get; set; } public GuyWithDatabaseConnection(string connectionString) { ConnectionString = connectionString; } } [Fact] public void specify_dependency_by_constructor_parameter() { var instance = ConstructorInstance .For<GuyWithDatabaseConnection>(); var parameter = instance.Constructor.GetParameters().Single(); parameter.Name.ShouldBe("connectionString"); var connString = "I haven't used sql server in years and I don't remember what connection strings look like"; instance.Dependencies.AddForConstructorParameter(parameter, connString); var guy = new Container().GetInstance<GuyWithDatabaseConnection>(instance); guy.ConnectionString.ShouldBe(connString); } + public class GuyWithDatabaseConnection { public string ConnectionString { get; set; } public GuyWithDatabaseConnection(string connectionString) { ConnectionString = connectionString; } } [Fact] public void specify_dependency_by_constructor_parameter() { var instance = ConstructorInstance .For<GuyWithDatabaseConnection>(); var parameter = instance.Constructor.GetParameters().Single(); parameter.Name.ShouldBe("connectionString"); var connString = "I haven't used sql server in years and I don't remember what connection strings look like"; instance.Dependencies.AddForConstructorParameter(parameter, connString); var guy = new Container().GetInstance<GuyWithDatabaseConnection>(instance); guy.ConnectionString.ShouldBe(connString); } Adding Interceptors You can add interceptors directly to a single IConfiguredInstance with code like this: - public class SimpleWidget { public bool WasIntercepted = false; public void Intercept() { WasIntercepted = true; } } [Fact] public void add_interceptor() { var interceptor = new ActivatorInterceptor<SimpleWidget>(w => w.Intercept()); var instance = new SmartInstance<SimpleWidget>(); instance.AddInterceptor(interceptor); new Container().GetInstance<SimpleWidget>(instance) .WasIntercepted.ShouldBeTrue(); } + public class SimpleWidget { public bool WasIntercepted = false; public void Intercept() { WasIntercepted = true; } } [Fact] public void add_interceptor() { var interceptor = new ActivatorInterceptor<SimpleWidget>(w => w.Intercept()); var instance = new SmartInstance<SimpleWidget>(); instance.AddInterceptor(interceptor); new Container().GetInstance<SimpleWidget>(instance) .WasIntercepted.ShouldBeTrue(); } See Interception and Decorators for more information. diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html old mode 100644 new mode 100755 index bc85bff..14aaf2a --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Fallback Services Previous On Missing Family Policies @@ -100,20 +100,20 @@ Greediest Constructor constructor functions with the same number of parameters StructureMap will simply take the first constructor encountered in that subset of constructors. The default constructor selection is demonstrated below: - public class GreaterThanRule : Rule { public string Attribute { get; set; } public int Value { get; set; } public GreaterThanRule() { } public GreaterThanRule(string attribute, int value) { Attribute = attribute; Value = value; } public GreaterThanRule(IWidget widget, Rule rule) { } } [Fact] public void using_the_greediest_ctor() { var container = new Container(_ => { _.ForConcreteType<GreaterThanRule>().Configure .Ctor<string>("attribute").Is("foo") .Ctor<int>("value").Is(42); }); var rule = container.GetInstance<GreaterThanRule>(); rule.Attribute.ShouldBe("foo"); rule.Value.ShouldBe(42); } + public class GreaterThanRule : Rule { public string Attribute { get; set; } public int Value { get; set; } public GreaterThanRule() { } public GreaterThanRule(string attribute, int value) { Attribute = attribute; Value = value; } public GreaterThanRule(IWidget widget, Rule rule) { } } [Fact] public void using_the_greediest_ctor() { var container = new Container(_ => { _.ForConcreteType<GreaterThanRule>().Configure .Ctor<string>("attribute").Is("foo") .Ctor<int>("value").Is(42); }); var rule = container.GetInstance<GreaterThanRule>(); rule.Attribute.ShouldBe("foo"); rule.Value.ShouldBe(42); } New in StructureMap 4.0, the "greediest constructor selection" will bypass any constructor function that requires "simple" arguments like strings, numbers, or enumeration values that are not explicitly configured for the instance. You can see this behavior shown below: - public class DbContext { public string ConnectionString { get; set; } public DbContext(string connectionString) { ConnectionString = connectionString; } public DbContext() : this("default value") { } } [Fact] public void should_bypass_ctor_with_unresolvable_simple_args() { var container = new Container(); container.GetInstance<DbContext>() .ConnectionString.ShouldBe("default value"); } [Fact] public void should_use_greediest_ctor_that_has_all_of_simple_dependencies() { var container = new Container(_ => { _.ForConcreteType<DbContext>().Configure .Ctor<string>("connectionString").Is("not the default"); }); container.GetInstance<DbContext>() .ConnectionString.ShouldBe("not the default"); } + public class DbContext { public string ConnectionString { get; set; } public DbContext(string connectionString) { ConnectionString = connectionString; } public DbContext() : this("default value") { } } [Fact] public void should_bypass_ctor_with_unresolvable_simple_args() { var container = new Container(); container.GetInstance<DbContext>() .ConnectionString.ShouldBe("default value"); } [Fact] public void should_use_greediest_ctor_that_has_all_of_simple_dependencies() { var container = new Container(_ => { _.ForConcreteType<DbContext>().Configure .Ctor<string>("connectionString").Is("not the default"); }); container.GetInstance<DbContext>() .ConnectionString.ShouldBe("not the default"); } Explicitly Selecting a Constructor To override the constructor selection explicitly on a case by case basis, you can use the SelectConstructor(Expression) method in the Registry DSL as shown below: - public class Thingie { public Thingie(IWidget widget) { CorrectCtorWasUsed = true; } public bool CorrectCtorWasUsed { get; set; } public Thingie(IWidget widget, IService service) { Assert.True(false, "I should not have been called"); } } [Fact] public void override_the_constructor_selection() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.ForConcreteType<Thingie>().Configure // StructureMap parses the expression passed // into the method below to determine the // constructor .SelectConstructor(() => new Thingie(null)); }); container.GetInstance<Thingie>() .CorrectCtorWasUsed .ShouldBeTrue(); } + public class Thingie { public Thingie(IWidget widget) { CorrectCtorWasUsed = true; } public bool CorrectCtorWasUsed { get; set; } public Thingie(IWidget widget, IService service) { Assert.True(false, "I should not have been called"); } } [Fact] public void override_the_constructor_selection() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.ForConcreteType<Thingie>().Configure // StructureMap parses the expression passed // into the method below to determine the // constructor .SelectConstructor(() => new Thingie(null)); }); container.GetInstance<Thingie>() .CorrectCtorWasUsed .ShouldBeTrue(); } [DefaultConstructor] Attribute Alternatively, you can override the choice of constructor function by using the older [DefaultConstructor] attribute like this: - public class AttributedThing { // Normally the greediest ctor would be // selected, but using this attribute // will overrid that behavior [DefaultConstructor] public AttributedThing(IWidget widget) { CorrectCtorWasUsed = true; } public bool CorrectCtorWasUsed { get; set; } public AttributedThing(IWidget widget, IService service) { Assert.True(false, "I should not have been called"); } } [Fact] public void select_constructor_by_attribute() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); }); container.GetInstance<AttributedThing>() .CorrectCtorWasUsed .ShouldBeTrue(); } + public class AttributedThing { // Normally the greediest ctor would be // selected, but using this attribute // will overrid that behavior [DefaultConstructor] public AttributedThing(IWidget widget) { CorrectCtorWasUsed = true; } public bool CorrectCtorWasUsed { get; set; } public AttributedThing(IWidget widget, IService service) { Assert.True(false, "I should not have been called"); } } [Fact] public void select_constructor_by_attribute() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); }); container.GetInstance<AttributedThing>() .CorrectCtorWasUsed .ShouldBeTrue(); } Custom Constructor Selection Rule If the constructor selection logic isn't what you want, you can systematically override the selection rules by registering one or more custom IConstructorSelector @@ -121,12 +121,12 @@ Custom Constructor Selection Rule Let's say that you want to control the constructor selection for all concrete subclasses of an abstract class like this hiearchy: - public abstract class BaseThing { public BaseThing(IWidget widget) { CorrectCtorWasUsed = true; } public bool CorrectCtorWasUsed { get; set; } public BaseThing(IWidget widget, IService service) { Assert.True(false, "I should not have been called"); } } public class Thing1 : BaseThing { public Thing1(IWidget widget) : base(widget) { } public Thing1(IWidget widget, IService service) : base(widget, service) { } } public class Thing2 : BaseThing { public Thing2(IWidget widget) : base(widget) { } public Thing2(IWidget widget, IService service) : base(widget, service) { } } + public abstract class BaseThing { public BaseThing(IWidget widget) { CorrectCtorWasUsed = true; } public bool CorrectCtorWasUsed { get; set; } public BaseThing(IWidget widget, IService service) { Assert.True(false, "I should not have been called"); } } public class Thing1 : BaseThing { public Thing1(IWidget widget) : base(widget) { } public Thing1(IWidget widget, IService service) : base(widget, service) { } } public class Thing2 : BaseThing { public Thing2(IWidget widget) : base(widget) { } public Thing2(IWidget widget, IService service) : base(widget, service) { } } You could create a custom IConstructorSelector like this one below to override the constructor behavior for only subclasses of BaseThing: - public class ThingCtorRule : IConstructorSelector { public ConstructorInfo Find(Type pluggedType, DependencyCollection dependencies, PluginGraph graph) { // if this rule does not apply to the pluggedType, // just return null to denote "not applicable" if (!pluggedType.CanBeCastTo<BaseThing>()) return null; return pluggedType.GetConstructor(new[] { typeof(IWidget) }); } } + public class ThingCtorRule : IConstructorSelector { public ConstructorInfo Find(Type pluggedType, DependencyCollection dependencies, PluginGraph graph) { // if this rule does not apply to the pluggedType, // just return null to denote "not applicable" if (!pluggedType.CanBeCastTo<BaseThing>()) return null; return pluggedType.GetConstructor(new[] { typeof(IWidget) }); } } Finally, you can register your custom rule as shown below: - [Fact] public void use_a_custom_constructor_selector() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.Policies.ConstructorSelector<ThingCtorRule>(); }); container.GetInstance<Thing1>() .CorrectCtorWasUsed.ShouldBeTrue(); container.GetInstance<Thing2>() .CorrectCtorWasUsed.ShouldBeTrue(); } + [Fact] public void use_a_custom_constructor_selector() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.Policies.ConstructorSelector<ThingCtorRule>(); }); container.GetInstance<Thing1>() .CorrectCtorWasUsed.ShouldBeTrue(); container.GetInstance<Thing2>() .CorrectCtorWasUsed.ShouldBeTrue(); } diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html old mode 100644 new mode 100755 index bf22380..fa22cd4 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Replace or Clear Out Previous Registrations Previous Fallback Services @@ -91,7 +91,7 @@ Registering Existing Objects Container and there are overloads of the Registry.For().Use(object) and Registry.For().Add(object) methods to do just that: - [Fact] public void should_be_able_to_resolve_from_the_generic_family_expression() { var widget = new AWidget(); var container = new Container(x => x.For(typeof(IWidget)).Use(widget).Named("mine")); container.GetInstance<IWidget>("mine").ShouldBeTheSameAs(widget); } + [Fact] public void should_be_able_to_resolve_from_the_generic_family_expression() { var widget = new AWidget(); var container = new Container(x => x.For(typeof(IWidget)).Use(widget).Named("mine")); container.GetInstance<IWidget>("mine").ShouldBeTheSameAs(widget); } Injecting an existing object into the Container makes it a de facto singleton, but the Container treats it with a special scope called ObjectLifecycle if you happen to look into the WhatDoIHave() diagnostics. StructureMap will attempt to call the IDisposable.Dispose() on any objects that are directly injected into a Container diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html old mode 100644 new mode 100755 index e8e787a..dca372f --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Registering Existing Objects Previous Constructor Selection @@ -97,10 +97,10 @@ Fallback Services public class DefaultServices : Registry { public DefaultServices() { // If nobody else provides a default // for IWidget, use AWidget For<IWidget>().UseIfNone<AWidget>(); } } public class SpecificServices : Registry { public SpecificServices() { // Use BWidget for IWidget, period For<IWidget>().Use<BWidget>(); } } + public class DefaultServices : Registry { public DefaultServices() { // If nobody else provides a default // for IWidget, use AWidget For<IWidget>().UseIfNone<AWidget>(); } } public class SpecificServices : Registry { public SpecificServices() { // Use BWidget for IWidget, period For<IWidget>().Use<BWidget>(); } } In application usage, you would add the default UseIfNone() registrations, and optionally pick up additional extension Registry objects from extension assemblies as shown in this example: - [AttributeUsage(AttributeTargets.Assembly)] public class ProductModuleAttribute : Attribute { } public class ApplicationRegistry : Registry { public ApplicationRegistry() { // Use the default services as fallbacks IncludeRegistry<DefaultServices>(); // Dependending on what assemblies are present, // this might find specific registrations that // will take precedence over the UseIfNone() // registrations in DefaultServices Scan(_ => { _.AssembliesFromApplicationBaseDirectory( assem => assem.HasAttribute<ProductModuleAttribute>()); _.LookForRegistries(); }); } } [Fact] public void see_use_if_none_in_action() { var container1 = Container.For<DefaultServices>(); // No other registrations, so fallback // to AWidget container1.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); var container2 = new Container(_ => { // add both registries above // NOTE: the order does not matter for IWidget _.IncludeRegistry<SpecificServices>(); _.IncludeRegistry<DefaultServices>(); }); // The registration in SpecificServices // should win out container2.GetInstance<IWidget>() .ShouldBeOfType<BWidget>(); } + [AttributeUsage(AttributeTargets.Assembly)] public class ProductModuleAttribute : Attribute { } public class ApplicationRegistry : Registry { public ApplicationRegistry() { // Use the default services as fallbacks IncludeRegistry<DefaultServices>(); // Dependending on what assemblies are present, // this might find specific registrations that // will take precedence over the UseIfNone() // registrations in DefaultServices Scan(_ => { _.AssembliesFromApplicationBaseDirectory( assem => assem.HasAttribute<ProductModuleAttribute>()); _.LookForRegistries(); }); } } [Fact] public void see_use_if_none_in_action() { var container1 = Container.For<DefaultServices>(); // No other registrations, so fallback // to AWidget container1.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); var container2 = new Container(_ => { // add both registries above // NOTE: the order does not matter for IWidget _.IncludeRegistry<SpecificServices>(); _.IncludeRegistry<DefaultServices>(); }); // The registration in SpecificServices // should win out container2.GetInstance<IWidget>() .ShouldBeOfType<BWidget>(); }
diff --git a/registration/index.html b/registration/index.html old mode 100644 new mode 100755 index 7689824..2db6a99 --- a/registration/index.html +++ b/registration/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@ - + Next Registry DSL Previous Setter Injection @@ -94,9 +94,9 @@ Registration Registry DSL. Let's say that you have a simple set of services like this: - public interface IBar { } public class Bar : IBar { } public interface IFoo { } public class Foo : IFoo { public IBar Bar { get; private set; } public Foo(IBar bar) { Bar = bar; } } + public interface IBar { } public class Bar : IBar { } public interface IFoo { } public class Foo : IFoo { public IBar Bar { get; private set; } public Foo(IBar bar) { Bar = bar; } } A simple configuration of a StructureMap Container might then be: - // Example #1 - Create an container instance and directly pass in the configuration. var container1 = new Container(c => { c.For<IFoo>().Use<Foo>(); c.For<IBar>().Use<Bar>(); }); // Example #2 - Create an container instance but add configuration later. var container2 = new Container(); container2.Configure(c => { c.For<IFoo>().Use<Foo>(); c.For<IBar>().Use<Bar>(); }); + // Example #1 - Create an container instance and directly pass in the configuration. var container1 = new Container(c => { c.For<IFoo>().Use<Foo>(); c.For<IBar>().Use<Bar>(); }); // Example #2 - Create an container instance but add configuration later. var container2 = new Container(); container2.Configure(c => { c.For<IFoo>().Use<Foo>(); c.For<IBar>().Use<Bar>(); }); Initializing or configuring the container is usually done at application startup and is located as close as possible to the application's entry point. This place is sometimes referred to as the composition root of the application. In our example we are composing our application's object graph by connecting abstractions to concrete types. @@ -104,16 +104,16 @@ Registration Registry DSL is by defining one or more Registry classes. Typically, you would subclass the Registry class, then use the Fluent API methods exposed by the Registry class to describe a Container configuration. Here's a sample Registry class used to configure the same types as in our previous example: - public class FooBarRegistry : Registry { public FooBarRegistry() { For<IFoo>().Use<Foo>(); For<IBar>().Use<Bar>(); } } + public class FooBarRegistry : Registry { public FooBarRegistry() { For<IFoo>().Use<Foo>(); For<IBar>().Use<Bar>(); } } When you set up a Container , you need to simply direct the Container to use the configuration in that Registry class. - // Example #1 var container1 = new Container(new FooBarRegistry()); // Example #2 var container2 = new Container(c => { c.AddRegistry<FooBarRegistry>(); }); // Example #3 -- create a container for a single Registry var container3 = Container.For<FooBarRegistry>(); + // Example #1 var container1 = new Container(new FooBarRegistry()); // Example #2 var container2 = new Container(c => { c.AddRegistry<FooBarRegistry>(); }); // Example #3 -- create a container for a single Registry var container3 = Container.For<FooBarRegistry>(); The StructureMap team highly recommends using `Registry` classes for your real application configuration. The syntax is shorter inside the Registry class constructor than from within the `Container` constructor method. In addition, Registry classes can be used to modularize the configuration of a bigger application into more manageable chunks. Lastly, using `Registry` classes makes it easier to stand up additional `Container` objects in testing scenarios that reflect the real application composition. In real world applications you also have to deal with repetitive similar registrations. Such registrations are tedious, easy to forget and can be a weak spot in your application. StructureMap provides Auto-Registration and Conventions which mitigates this pain and eases the maintenance burden. StructureMap exposes this feature through the Registry DSL by the Scan method. In our example there is an reoccuring pattern, we are connecting the plugin type ISomething to a concrete type Something, meaning IFoo to Foo and IBar to Bar. Wouldn't it be cool if we could write a convention for exactly doing that? Fortunatly StructureMap has already one build in. Let's see how we can create an container with the same configuration as in the above examples. - // Example #1 var container1 = new Container(c => c.Scan(scanner => { scanner.TheCallingAssembly(); scanner.WithDefaultConventions(); })); // Example #2 var container2 = new Container(); container2.Configure(c => c.Scan(scanner => { scanner.TheCallingAssembly(); scanner.WithDefaultConventions(); })); + // Example #1 var container1 = new Container(c => c.Scan(scanner => { scanner.TheCallingAssembly(); scanner.WithDefaultConventions(); })); // Example #2 var container2 = new Container(); container2.Configure(c => c.Scan(scanner => { scanner.TheCallingAssembly(); scanner.WithDefaultConventions(); })); We instruct the scanner to scan through the calling assembly with default conventions on. This will find and register the default instance for IFoo and IBar which are obviously the concrete types Foo and Bar. Now whenever you add an additional interface IMoreFoo and a class MoreFoo to your application's code base, it's automatically picked up by the scanner. Sometimes classes need to be supplied with some primitive value in its constructor. For example the System.Data.SqlClient.SqlConnection needs to be supplied with the connection string in its constructor. No problem, just set up the value of the constructor argument in the bootstrapping: - var container = new Container(c => { //just for demo purposes, normally you don't want to embed the connection string directly into code. c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING"); //a better way would be providing a delegate that retrieves the value from your app config. }); + var container = new Container(c => { //just for demo purposes, normally you don't want to embed the connection string directly into code. c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING"); //a better way would be providing a delegate that retrieves the value from your app config. }); So far you have seen an couple of ways to work with the Registry DSL and configure a Container object. We have seen examples of configuration that allow us to build objects that don't depend on anything like the Bar class, or do depend on other types like the Foo class needs an instance of IBar. In our last example we have seen configuration for objects that need some primitive types like strings in its constructor function. diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html old mode 100644 new mode 100755 index b176071..a068d5f --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@ - + Next Auto-Registration and Conventions Previous Registry DSL @@ -94,9 +94,9 @@ Inline Dependencies Let's say we have a simple class called ColorWidget like the following: - public class ColorWidget : IWidget { public string Color { get; set; } public ColorWidget(string color) { Color = color; } } + public class ColorWidget : IWidget { public string Color { get; set; } public ColorWidget(string color) { Color = color; } } To register the ColorWidget, you would supply the value of the color parameter to the constructor function like so: - [Fact] public void inline_usage_of_primitive_constructor_argument() { var container = new Container(_ => { _.For<IWidget>().Use<ColorWidget>() .Ctor<string>().Is("Red"); }); container.GetInstance<IWidget>() .ShouldBeOfType<ColorWidget>() .Color.ShouldBe("Red"); } + [Fact] public void inline_usage_of_primitive_constructor_argument() { var container = new Container(_ => { _.For<IWidget>().Use<ColorWidget>() .Ctor<string>().Is("Red"); }); container.GetInstance<IWidget>() .ShouldBeOfType<ColorWidget>() .Color.ShouldBe("Red"); } The most common reason to define string arguments to classes seems to be passing in database connection strings or occasional file paths. I used this strategy very commonly in the early days of StructureMap, but for the past 5-6 years I strongly prefer to use Settings classes @@ -105,35 +105,35 @@ Inline Dependencies Event Condition Action Rules The ability to explicitly define dependencies inline isn't commonly used these days, but was actually one of the very core use cases in the initial versions of StructureMap. One of the first usages of StructureMap in a production application was in a configurable rules engine using an Event-Condition-Action architecture where the conditions and actions were configured in StructureMap as inline dependencies of Rule objects. Using StructureMap's old Xml configuration, we could define rules for new customers by registering rule objects with the container that reused existing condition and action classes in new configurations. To make that concrete and establish a sample problem domain, consider these types: - public class SomeEvent { } public interface ICondition { bool Matches(SomeEvent @event); } public interface IAction { void PerformWork(SomeEvent @event); } public interface IEventRule { void ProcessEvent(SomeEvent @event); } + public class SomeEvent { } public interface ICondition { bool Matches(SomeEvent @event); } public interface IAction { void PerformWork(SomeEvent @event); } public interface IEventRule { void ProcessEvent(SomeEvent @event); } Now, let's move on to seeing how we could use inline dependency configuration to register new rules. Constructor Parameters by Type First off, let's say that we have a SimpleRule that takes a single condition and action: - public class SimpleRule : IEventRule { private readonly ICondition _condition; private readonly IAction _action; public SimpleRule(ICondition condition, IAction action) { _condition = condition; _action = action; } public void ProcessEvent(SomeEvent @event) { if (_condition.Matches(@event)) { _action.PerformWork(@event); } } } + public class SimpleRule : IEventRule { private readonly ICondition _condition; private readonly IAction _action; public SimpleRule(ICondition condition, IAction action) { _condition = condition; _action = action; } public void ProcessEvent(SomeEvent @event) { if (_condition.Matches(@event)) { _action.PerformWork(@event); } } } Now, since SimpleRule has only a single dependency on both IAction and ICondition, we can create new rules by registering new Instance's of SimpleRule with different combinations of its dependencies: - public class InlineCtorArgs : Registry { public InlineCtorArgs() { // Defining args by type For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is<Condition1>() .Ctor<IAction>().Is<Action1>() .Named("One"); // Pass the explicit values for dependencies For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is(new Condition2()) .Ctor<IAction>().Is(new Action2()) .Named("Two"); // Use Lambda construction For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is(() => new Condition3()) .Ctor<IAction>().Is("some crazy builder", c => c.GetInstance<Action3>()) .Named("Three"); // Rarely used, but gives you a "do any crazy thing" option // Pass in your own Instance object For<IEventRule>().Use<SimpleRule>() .Ctor<IAction>().Is(new MySpecialActionInstance()); // Inline configuration of your dependency's dependencies For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().IsSpecial(_ => _.Type<BigCondition>().Ctor<int>().Is(100)) // or .Ctor<ICondition>().Is(new SmartInstance<BigCondition>().Ctor<int>().Is(100)); } public class BigCondition : ICondition { public BigCondition(int number) { } public bool Matches(SomeEvent @event) { throw new NotImplementedException(); } } public class MySpecialActionInstance : LambdaInstance<Action3> { public MySpecialActionInstance() : base(() => new Action3()) { } } } + public class InlineCtorArgs : Registry { public InlineCtorArgs() { // Defining args by type For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is<Condition1>() .Ctor<IAction>().Is<Action1>() .Named("One"); // Pass the explicit values for dependencies For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is(new Condition2()) .Ctor<IAction>().Is(new Action2()) .Named("Two"); // Use Lambda construction For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is(() => new Condition3()) .Ctor<IAction>().Is("some crazy builder", c => c.GetInstance<Action3>()) .Named("Three"); // Rarely used, but gives you a "do any crazy thing" option // Pass in your own Instance object For<IEventRule>().Use<SimpleRule>() .Ctor<IAction>().Is(new MySpecialActionInstance()); // Inline configuration of your dependency's dependencies For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().IsSpecial(_ => _.Type<BigCondition>().Ctor<int>().Is(100)) // or .Ctor<ICondition>().Is(new SmartInstance<BigCondition>().Ctor<int>().Is(100)); } public class BigCondition : ICondition { public BigCondition(int number) { } public bool Matches(SomeEvent @event) { throw new NotImplementedException(); } } public class MySpecialActionInstance : LambdaInstance<Action3> { public MySpecialActionInstance() : base(() => new Action3()) { } } } The inline dependency configuration using the Ctor<T>().Is() syntax supports all the common StructureMap configuration options: define by type, by lambdas, by value, or if you really want to risk severe eye strain, you can use your own Instance objects and define the configuration of your dependency's dependencies. Specifying the Argument Name If for some reason you need to specify an inline constructor argument dependency, and the concrete type has more than one dependency for that type, you just need to specify the parameter name as shown in this sample: - public class DualConditionRule : IEventRule { private readonly ICondition _first; private readonly ICondition _second; private readonly IAction _action; public DualConditionRule(ICondition first, ICondition second, IAction action) { _first = first; _second = second; _action = action; } public void ProcessEvent(SomeEvent @event) { if (_first.Matches(@event) || _second.Matches(@event)) { _action.PerformWork(@event); } } } public class DualConditionRuleRegistry : Registry { public DualConditionRuleRegistry() { // In this case, because DualConditionRule // has two different For<IEventRule>().Use<DualConditionRule>() .Ctor<ICondition>("first").Is<Condition1>() .Ctor<ICondition>("second").Is<Condition2>(); } } + public class DualConditionRule : IEventRule { private readonly ICondition _first; private readonly ICondition _second; private readonly IAction _action; public DualConditionRule(ICondition first, ICondition second, IAction action) { _first = first; _second = second; _action = action; } public void ProcessEvent(SomeEvent @event) { if (_first.Matches(@event) || _second.Matches(@event)) { _action.PerformWork(@event); } } } public class DualConditionRuleRegistry : Registry { public DualConditionRuleRegistry() { // In this case, because DualConditionRule // has two different For<IEventRule>().Use<DualConditionRule>() .Ctor<ICondition>("first").Is<Condition1>() .Ctor<ICondition>("second").Is<Condition2>(); } } Setter Dependencies You can also configure setter dependencies with a similar syntax, but with additional options to specify the property name by using an Expression as shown below: - public class RuleWithSetters : IEventRule { public ICondition Condition { get; set; } public IAction Action { get; set; } public void ProcessEvent(SomeEvent @event) { if (Condition.Matches(@event)) { Action.PerformWork(@event); } } } public class RuleWithSettersRegistry : Registry { public RuleWithSettersRegistry() { For<IEventRule>().Use<RuleWithSetters>() .Setter<ICondition>().Is<Condition1>() // or .Setter(x => x.Action).Is(new Action1()) // or if you need to specify the name .Setter<IAction>("Action").Is<Action2>() // or you can configure values *after* the object // is constructed with the SetProperty method .SetProperty(x => x.Action = new Action2()); } } + public class RuleWithSetters : IEventRule { public ICondition Condition { get; set; } public IAction Action { get; set; } public void ProcessEvent(SomeEvent @event) { if (Condition.Matches(@event)) { Action.PerformWork(@event); } } } public class RuleWithSettersRegistry : Registry { public RuleWithSettersRegistry() { For<IEventRule>().Use<RuleWithSetters>() .Setter<ICondition>().Is<Condition1>() // or .Setter(x => x.Action).Is(new Action1()) // or if you need to specify the name .Setter<IAction>("Action").Is<Action2>() // or you can configure values *after* the object // is constructed with the SetProperty method .SetProperty(x => x.Action = new Action2()); } } The `Ctor` and `Setter` methods are just syntactic sugar. Both methods store data to the same underlying structure. Enumerable Dependencies TODO(show a sample of using enumerable dependencies) Programmatic Configuration outside of the Registry DSL In some cases, you may want to skip the Registry DSL and go straight for the raw dependencies structures. Let's say that we're using an open generic type for our rules engine so that we can respond to multiple event types: - public interface IEventRule<TEvent> { void ProcessEvent(TEvent @event); } public interface ICondition<TEvent> { bool Matches(TEvent @event); } public class Condition1<TEvent> : ICondition<TEvent> { public bool Matches(TEvent @event) { throw new NotImplementedException(); } } public interface IAction<TEvent> { void PerformWork(TEvent @event); } public class Action1<TEvent> : IAction<TEvent> { public void PerformWork(TEvent @event) { throw new NotImplementedException(); } } public class EventRule<TEvent> : IEventRule<TEvent> { private readonly string _name; private readonly ICondition<TEvent> _condition; private readonly IAction<TEvent> _action; public EventRule(string name, ICondition<TEvent> condition, IAction<TEvent> action) { _name = name; _condition = condition; _action = action; } public string Name { get { return _name; } } public void ProcessEvent(TEvent @event) { if (_condition.Matches(@event)) { _action.PerformWork(@event); } } } + public interface IEventRule<TEvent> { void ProcessEvent(TEvent @event); } public interface ICondition<TEvent> { bool Matches(TEvent @event); } public class Condition1<TEvent> : ICondition<TEvent> { public bool Matches(TEvent @event) { throw new NotImplementedException(); } } public interface IAction<TEvent> { void PerformWork(TEvent @event); } public class Action1<TEvent> : IAction<TEvent> { public void PerformWork(TEvent @event) { throw new NotImplementedException(); } } public class EventRule<TEvent> : IEventRule<TEvent> { private readonly string _name; private readonly ICondition<TEvent> _condition; private readonly IAction<TEvent> _action; public EventRule(string name, ICondition<TEvent> condition, IAction<TEvent> action) { _name = name; _condition = condition; _action = action; } public string Name { get { return _name; } } public void ProcessEvent(TEvent @event) { if (_condition.Matches(@event)) { _action.PerformWork(@event); } } } As an alternative approach, we could build up ConstructorInstance objects to represent our rules like so: - public class OpenTypesRegistry : Registry { public OpenTypesRegistry() { var instance = new ConstructorInstance(typeof(EventRule<>)); // By name instance.Dependencies.Add("action", typeof(Action1<>)); // Everything else is syntactical sugur over this: instance.Dependencies.Add(new Argument { Type = typeof(IAction<>), // The dependency type Name = "action", // The name of the dependency, either // a constructor argument name or // the name of a setter property // Specify the actual dependency // This can be either a concrete type, the prebuilt value, // or an Instance Dependency = typeof(Action1<>) }); } } + public class OpenTypesRegistry : Registry { public OpenTypesRegistry() { var instance = new ConstructorInstance(typeof(EventRule<>)); // By name instance.Dependencies.Add("action", typeof(Action1<>)); // Everything else is syntactical sugur over this: instance.Dependencies.Add(new Argument { Type = typeof(IAction<>), // The dependency type Name = "action", // The name of the dependency, either // a constructor argument name or // the name of a setter property // Specify the actual dependency // This can be either a concrete type, the prebuilt value, // or an Instance Dependency = typeof(Action1<>) }); } } It's frequently useful to explicitly configure all the elements for an enumerable argument (arrays, IEnumerable, or IList). StructureMap provides this syntax to do just that: - public class BigRule : IEventRule { private readonly IEnumerable<ICondition> _conditions; private readonly IEnumerable<IAction> _actions; public BigRule(IEnumerable<ICondition> conditions, IEnumerable<IAction> actions) { _conditions = conditions; _actions = actions; } public void ProcessEvent(SomeEvent @event) { if (_conditions.Any(x => x.Matches(@event))) { _actions.Each(x => x.PerformWork(@event)); } } } public class BigRuleRegistry : Registry { public BigRuleRegistry() { For<IEventRule>().Use<BigRule>() // Each line in the nested closure adds another // ICondition to the enumerable dependency in // the order in which they are configured .EnumerableOf<ICondition>().Contains(_ => { _.Type<Condition1>(); _.Type<Condition2>(); }) .EnumerableOf<IAction>().Contains(_ => { _.Type<Action1>(); _.Object(new Action2()); }); } } + public class BigRule : IEventRule { private readonly IEnumerable<ICondition> _conditions; private readonly IEnumerable<IAction> _actions; public BigRule(IEnumerable<ICondition> conditions, IEnumerable<IAction> actions) { _conditions = conditions; _actions = actions; } public void ProcessEvent(SomeEvent @event) { if (_conditions.Any(x => x.Matches(@event))) { _actions.Each(x => x.PerformWork(@event)); } } } public class BigRuleRegistry : Registry { public BigRuleRegistry() { For<IEventRule>().Use<BigRule>() // Each line in the nested closure adds another // ICondition to the enumerable dependency in // the order in which they are configured .EnumerableOf<ICondition>().Contains(_ => { _.Type<Condition1>(); _.Type<Condition2>(); }) .EnumerableOf<IAction>().Contains(_ => { _.Type<Action1>(); _.Object(new Action2()); }); } } diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html old mode 100644 new mode 100755 index ec20884..0a8b5c4 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -31,7 +31,7 @@ - StructureMap 4.5.3 + StructureMap 4.6.0 @@ -74,7 +74,7 @@ - + Next Constructor Selection Previous Changing Configuration at Runtime @@ -92,13 +92,13 @@ On Missing Family Policies /// <summary> /// Allows StructureMap to fill in missing registrations by unknown plugin types /// at runtime /// </summary> public interface IFamilyPolicy { /// <summary> /// Allows you to create missing registrations for an unknown plugin type /// at runtime. /// Return null if this policy does not apply to the given type /// </summary> PluginFamily Build(Type type); /// <summary> /// Should this policy be used to determine whether or not the Container has /// registrations for a plugin type in the PluginGraph.HasFamily(type) method /// </summary> bool AppliesToHasFamilyChecks { get; } }
+ /// <summary> /// Allows StructureMap to fill in missing registrations by unknown plugin types /// at runtime /// </summary> public interface IFamilyPolicy { /// <summary> /// Allows you to create missing registrations for an unknown plugin type /// at runtime. /// Return null if this policy does not apply to the given type /// </summary> PluginFamily Build(Type type); /// <summary> /// Should this policy be used to determine whether or not the Container has /// registrations for a plugin type in the PluginGraph.HasFamily(type) method /// </summary> bool AppliesToHasFamilyChecks { get; } } Internally, if you make a request to IContainer.GetInstance(type) for a type that the active Container does not recognize, StructureMap will next try to apply all the registered IFamilyPolicy policies to create a PluginFamily object for that plugin type that models the registrations for that plugin type, including the default, additional named instances, interceptors or decorators, and lifecycle rules. The simplest built in example is the EnumerableFamilyPolicy shown below that can fill in requests for IList<T>, ICollection<T>, and T[] with a collection of all the known registrations of the type T: - public class EnumerableFamilyPolicy : IFamilyPolicy { public PluginFamily Build(Type type) { if (EnumerableInstance.IsEnumerable(type)) { var family = new PluginFamily(type); family.SetDefault(new AllPossibleInstance(type)); return family; } return null; } public bool AppliesToHasFamilyChecks { get { return false; } } } + public class EnumerableFamilyPolicy : IFamilyPolicy { public PluginFamily Build(Type type) { if (EnumerableInstance.IsEnumerable(type)) { var family = new PluginFamily(type); family.SetDefault(new AllPossibleInstance(type)); return family; } return null; } public bool AppliesToHasFamilyChecks { get { return false; } } } The result of EnumerableFamilyPolicy in action is shown by the acceptance test below: - [Fact] public void collection_types_are_all_possible_by_default() { // NOTE that we do NOT make any explicit registration of // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[] var container = new Container(_ => { _.For<IWidget>().Add<AWidget>(); _.For<IWidget>().Add<BWidget>(); _.For<IWidget>().Add<CWidget>(); }); // IList<T> container.GetInstance<IList<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // ICollection<T> container.GetInstance<ICollection<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // Array of T container.GetInstance<IWidget[]>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); } + [Fact] public void collection_types_are_all_possible_by_default() { // NOTE that we do NOT make any explicit registration of // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[] var container = new Container(_ => { _.For<IWidget>().Add<AWidget>(); _.For<IWidget>().Add<BWidget>(); _.For<IWidget>().Add<CWidget>(); }); // IList<T> container.GetInstance<IList<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // ICollection<T> container.GetInstance<ICollection<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // Array of T container.GetInstance<IWidget[]>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); } See also the Handling Missing Named Instances for runtime determination of named instances within a known plugin type. Built In Policies StructureMap and StructureMap.AutoMocking use several IFamilyPolicy rules internally to create default behavior. In all cases, any custom @@ -117,18 +117,18 @@ Built In Policies Using a Custom IFamilyPolicy" id="custom"> FubuMVC 2.0 (still unreleased to the public as of yet, but in production usage) uses a custom family policy in its StructureMap integration to auto-resolve concrete configuration types like the following type: - public class SomeSettings { public string ThisDirectory { get; set; } public string ThatDirectory { get; set; } } + public class SomeSettings { public string ThisDirectory { get; set; } public string ThatDirectory { get; set; } } Unless the system using this object has explicitly registered SomeSettings, we want StructureMap to resolve this object by using data from the basic .Net appSettings collection to create a SomeSettings object. For the sake of the example, assume that you have a functioning service that implements this interface below: - public interface ISettingsProvider { T SettingsFor<T>() where T : class, new(); object SettingsFor(Type settingsType); } public class AppSettingsProvider : ISettingsProvider { public T SettingsFor<T>() where T : class, new() { return SettingsFor(typeof (T)).As<T>(); } public object SettingsFor(Type settingsType) { // The real one reads key/value data from // the appSettings and uses FubuCore's // model binding to assign data to a new // object of settingsType return null; } } + public interface ISettingsProvider { T SettingsFor<T>() where T : class, new(); object SettingsFor(Type settingsType); } public class AppSettingsProvider : ISettingsProvider { public T SettingsFor<T>() where T : class, new() { return SettingsFor(typeof (T)).As<T>(); } public object SettingsFor(Type settingsType) { // The real one reads key/value data from // the appSettings and uses FubuCore's // model binding to assign data to a new // object of settingsType return null; } } Assuming that ISettingsProvider is registered in your StructureMap Container, you could then craft a custom IFamilyPolicy class like this: - public class SettingPolicy : IFamilyPolicy { public PluginFamily Build(Type type) { if (type.Name.EndsWith("Settings") && type.IsConcreteWithDefaultCtor()) { var family = new PluginFamily(type); var instance = buildInstanceForType(type); family.SetDefault(instance); return family; } return null; } public bool AppliesToHasFamilyChecks { get { return true; } } private static Instance buildInstanceForType(Type type) { var instanceType = typeof (SettingsInstance<>).MakeGenericType(type); var instance = Activator.CreateInstance(instanceType).As<Instance>(); return instance; } } // SettingsInstance just uses the registered service for ISettingsProvider to // build the real object public class SettingsInstance<T> : LambdaInstance<T> where T : class, new() { public SettingsInstance() : base("Building {0} from application settings".ToFormat(typeof (T).FullName), c => c.GetInstance<ISettingsProvider>().SettingsFor<T>()) { } } + public class SettingPolicy : IFamilyPolicy { public PluginFamily Build(Type type) { if (type.Name.EndsWith("Settings") && type.IsConcreteWithDefaultCtor()) { var family = new PluginFamily(type); var instance = buildInstanceForType(type); family.SetDefault(instance); return family; } return null; } public bool AppliesToHasFamilyChecks { get { return true; } } private static Instance buildInstanceForType(Type type) { var instanceType = typeof (SettingsInstance<>).MakeGenericType(type); var instance = Activator.CreateInstance(instanceType).As<Instance>(); return instance; } } // SettingsInstance just uses the registered service for ISettingsProvider to // build the real object public class SettingsInstance<T> : LambdaInstance<T> where T : class, new() { public SettingsInstance() : base("Building {0} from application settings".ToFormat(typeof (T).FullName), c => c.GetInstance<ISettingsProvider>().SettingsFor<T>()) { } } SettingPolicy is able to create a registration on the fly for any concrete type whose name ends in "Settings" and has a default, no arg constructor. To use register the custom SettingPolicy, use one of the Registry.Policies.OnMissingFamily() methods: - public class SettingsRegistry : Registry { public SettingsRegistry() { For<ISettingsProvider>().Use<AppSettingsProvider>(); Policies.OnMissingFamily<SettingPolicy>(); } } + public class SettingsRegistry : Registry { public SettingsRegistry() { For<ISettingsProvider>().Use<AppSettingsProvider>(); Policies.OnMissingFamily<SettingPolicy>(); } } You can see the real implementation of the SettingPolicy in action in its integration tests on GitHub.
diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100644 new mode 100755 index f0abfb8..95c62b6 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -31,7 +31,7 @@
- StructureMap 4.5.3 + StructureMap 4.6.0
@@ -74,7 +74,7 @@
- + Next Changing Configuration at Runtime Previous Working with IConfiguredInstance @@ -94,10 +94,10 @@ Construction Policies interception policies. The 4.0 release extends StructureMap's support for conventional build policies with a new mechanism for altering how object instances are built based on user created meta-conventions using the IInstancePolicy shown below: - /// <summary> /// Custom policy on Instance construction that is evaluated /// as part of creating a "build plan" /// </summary> public interface IInstancePolicy { /// <summary> /// Apply any conventional changes to the configuration /// of a single Instance /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> void Apply(Type pluginType, Instance instance); } + /// <summary> /// Custom policy on Instance construction that is evaluated /// as part of creating a "build plan" /// </summary> public interface IInstancePolicy { /// <summary> /// Apply any conventional changes to the configuration /// of a single Instance /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> void Apply(Type pluginType, Instance instance); } These policies are registered as part of the registry dsl with the Policies.Add() method: - var container = new Container(_ => { _.Policies.Add<MyCustomPolicy>(); // or _.Policies.Add(new MyCustomPolicy()); }); + var container = new Container(_ => { _.Policies.Add<MyCustomPolicy>(); // or _.Policies.Add(new MyCustomPolicy()); }); The IInstancePolicy mechanism probably works differently than other IoC containers in that the policy is applied to the container's underlying configuration model instead of at runtime. Internally, StructureMap lazily creates a "build plan" for each configured Instance at the first time @@ -109,7 +109,7 @@
Construction Policies public abstract class ConfiguredInstancePolicy : IInstancePolicy { /// <summary> /// Applies explicit configuration to an IConfiguredInstance /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> public void Apply(Type pluginType, Instance instance) { var configured = instance as IConfiguredInstance; if (configured != null) { apply(pluginType, configured); } } /// <summary> /// This method is called against any Instance that implements the /// IConfiguredInstance interface /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> protected abstract void apply(Type pluginType, IConfiguredInstance instance); } +
public abstract class ConfiguredInstancePolicy : IInstancePolicy { /// <summary> /// Applies explicit configuration to an IConfiguredInstance /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> public void Apply(Type pluginType, Instance instance) { var configured = instance as IConfiguredInstance; if (configured != null) { apply(pluginType, configured); } } /// <summary> /// This method is called against any Instance that implements the /// IConfiguredInstance interface /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> protected abstract void apply(Type pluginType, IConfiguredInstance instance); }

For more information, see:

Build Plans
@@ -120,13 +120,13 @@
Example 1: Constructor arguments

So let me say upfront that I don't like this approach, but other folks have asked for this ability over the years. Say that you have some legacy code where many concrete classes have a constructor argument called "connectionString" that needs to be the connection string to the application database like these classes:
-
public class DatabaseUser { public string ConnectionString { get; set; } public DatabaseUser(string connectionString) { ConnectionString = connectionString; } } public class ConnectedThing { public string ConnectionString { get; set; } public ConnectedThing(string connectionString) { ConnectionString = connectionString; } }
+
public class DatabaseUser { public string ConnectionString { get; set; } public DatabaseUser(string connectionString) { ConnectionString = connectionString; } } public class ConnectedThing { public string ConnectionString { get; set; } public ConnectedThing(string connectionString) { ConnectionString = connectionString; } }

Instead of explicitly configuring every single concrete class in StructureMap with that inline constructor argument, we can make a policy to do that in one place:
-
public class ConnectionStringPolicy : ConfiguredInstancePolicy { protected override void apply(Type pluginType, IConfiguredInstance instance) { var parameter = instance.Constructor.GetParameters().FirstOrDefault(x => x.Name == "connectionString"); if (parameter != null) { var connectionString = findConnectionStringFromConfiguration(); instance.Dependencies.AddForConstructorParameter(parameter, connectionString); } } // find the connection string from whatever configuration // strategy your application uses private string findConnectionStringFromConfiguration() { return "the connection string"; } }
+
public class ConnectionStringPolicy : ConfiguredInstancePolicy { protected override void apply(Type pluginType, IConfiguredInstance instance) { var parameter = instance.Constructor.GetParameters().FirstOrDefault(x => x.Name == "connectionString"); if (parameter != null) { var connectionString = findConnectionStringFromConfiguration(); instance.Dependencies.AddForConstructorParameter(parameter, connectionString); } } // find the connection string from whatever configuration // strategy your application uses private string findConnectionStringFromConfiguration() { return "the connection string"; } }

Now, let's use that policy against the types that need "connectionString" and see what happens:
-
[Fact] public void use_the_connection_string_policy() { var container = new Container(_ => { _.Policies.Add<ConnectionStringPolicy>(); }); container.GetInstance<DatabaseUser>() .ConnectionString.ShouldBe("the connection string"); container.GetInstance<ConnectedThing>() .ConnectionString.ShouldBe("the connection string"); }
+
[Fact] public void use_the_connection_string_policy() { var container = new Container(_ => { _.Policies.Add<ConnectionStringPolicy>(); }); container.GetInstance<DatabaseUser>() .ConnectionString.ShouldBe("the connection string"); container.GetInstance<ConnectedThing>() .ConnectionString.ShouldBe("the connection string"); }

Years ago StructureMap was knocked by an "IoC expert" for not having this functionality. I said at the time -- and still would -- that I would strongly recommend that you simply don't directly open database connections in more than one or a very few spots in your code anyway. If I did @@ -137,19 +137,19 @@
Example 2: Co that's all the consumers of any database should ever need to know.

To make this concrete, let's say that our data access is all behind an interface and concrete class pair named Database/IDatabase like so:
-
public interface IDatabase { } public class Database : IDatabase { public string ConnectionString { get; set; } public Database(string connectionString) { ConnectionString = connectionString; } public override string ToString() { return string.Format("ConnectionString: {0}", ConnectionString); } }
+
public interface IDatabase { } public class Database : IDatabase { public string ConnectionString { get; set; } public Database(string connectionString) { ConnectionString = connectionString; } public override string ToString() { return string.Format("ConnectionString: {0}", ConnectionString); } }

For a registration policy, let's say that the parameter name of an IDatabase dependency in a constructor function should match an identifier of one of the registered IDatabase services. That policy would be:
-
public class InjectDatabaseByName : ConfiguredInstancePolicy { protected override void apply(Type pluginType, IConfiguredInstance instance) { instance.Constructor.GetParameters() .Where(x => x.ParameterType == typeof(IDatabase)) .Each(param => { // Using ReferencedInstance here tells StructureMap // to "use the IDatabase by this name" var db = new ReferencedInstance(param.Name); instance.Dependencies.AddForConstructorParameter(param, db); }); } }
+
public class InjectDatabaseByName : ConfiguredInstancePolicy { protected override void apply(Type pluginType, IConfiguredInstance instance) { instance.Constructor.GetParameters() .Where(x => x.ParameterType == typeof(IDatabase)) .Each(param => { // Using ReferencedInstance here tells StructureMap // to "use the IDatabase by this name" var db = new ReferencedInstance(param.Name); instance.Dependencies.AddForConstructorParameter(param, db); }); } }

And because I'm generally pretty boring about picking test data names, let's say that two of our databases are named "red" and "green" with this container registration below:
-
var container = new Container(_ => { _.For<IDatabase>().Add<Database>().Named("red") .Ctor<string>("connectionString").Is("*red*"); _.For<IDatabase>().Add<Database>().Named("green") .Ctor<string>("connectionString").Is("*green*"); _.Policies.Add<InjectDatabaseByName>(); });
+
var container = new Container(_ => { _.For<IDatabase>().Add<Database>().Named("red") .Ctor<string>("connectionString").Is("*red*"); _.For<IDatabase>().Add<Database>().Named("green") .Ctor<string>("connectionString").Is("*green*"); _.Policies.Add<InjectDatabaseByName>(); });

For more context, the classes that use IDatabase would need to have constructor functions like these below:
-
public class BigService { public BigService(IDatabase green) { DB = green; } public IDatabase DB { get; set; } } public class ImportantService { public ImportantService(IDatabase red) { DB = red; } public IDatabase DB { get; set; } } public class DoubleDatabaseUser { public DoubleDatabaseUser(IDatabase red, IDatabase green) { Red = red; Green = green; } // Watch out for potential conflicts between setters // and ctor params. The easiest thing is to just make // setters private public IDatabase Green { get; private set; } public IDatabase Red { get; private set; } }
+
public class BigService { public BigService(IDatabase green) { DB = green; } public IDatabase DB { get; set; } } public class ImportantService { public ImportantService(IDatabase red) { DB = red; } public IDatabase DB { get; set; } } public class DoubleDatabaseUser { public DoubleDatabaseUser(IDatabase red, IDatabase green) { Red = red; Green = green; } // Watch out for potential conflicts between setters // and ctor params. The easiest thing is to just make // setters private public IDatabase Green { get; private set; } public IDatabase Red { get; private set; } }

Finally, we can exercise our new policy and see it in action:
-
// ImportantService should get the "red" database container.GetInstance<ImportantService>() .DB.As<Database>().ConnectionString.ShouldBe("*red*"); // BigService should get the "green" database container.GetInstance<BigService>() .DB.As<Database>().ConnectionString.ShouldBe("*green*"); // DoubleDatabaseUser gets both var user = container.GetInstance<DoubleDatabaseUser>(); user.Green.As<Database>().ConnectionString.ShouldBe("*green*"); user.Red.As<Database>().ConnectionString.ShouldBe("*red*");
+
// ImportantService should get the "red" database container.GetInstance<ImportantService>() .DB.As<Database>().ConnectionString.ShouldBe("*red*"); // BigService should get the "green" database container.GetInstance<BigService>() .DB.As<Database>().ConnectionString.ShouldBe("*green*"); // DoubleDatabaseUser gets both var user = container.GetInstance<DoubleDatabaseUser>(); user.Green.As<Database>().ConnectionString.ShouldBe("*green*"); user.Red.As<Database>().ConnectionString.ShouldBe("*red*");

How I prefer to do this - my strong preference would be to use separate interfaces for the different databases even if that type is just an empty type marker that implements the same base. I feel like using separate interfaces makes the code easier to trace and understand than trying @@ -161,13 +161,13 @@
Example 3: Make ob for its service registration. In that case, we wanted any concrete type whose name ended with "Cache" to be a singleton in the container registration. With the new IInstancePolicy feature in StructureMap 4, we could create a new policy class like so:
-
public class CacheIsSingleton : IInstancePolicy { public void Apply(Type pluginType, Instance instance) { if (instance.ReturnedType.Name.EndsWith("Cache")) { instance.SetLifecycleTo<SingletonLifecycle>(); } } }
+
public class CacheIsSingleton : IInstancePolicy { public void Apply(Type pluginType, Instance instance) { if (instance.ReturnedType.Name.EndsWith("Cache")) { instance.SetLifecycleTo<SingletonLifecycle>(); } } }
Now, let's say that we have an interface named `IWidgets` and a single implementation called `WidgetCache` that should track our widgets in the application. Using our new policy, we should see `WidgetCache` being made a singleton: -
[Fact] public void set_cache_to_singleton() { var container = new Container(_ => { _.Policies.Add<CacheIsSingleton>(); _.For<IWidgets>().Use<WidgetCache>(); }); // The policy is applied *only* at the time // that StructureMap creates a "build plan" container.GetInstance<IWidgets>() .ShouldBeTheSameAs(container.GetInstance<IWidgets>()); // Now that the policy has executed, we // can verify that WidgetCache is a SingletonThing container.Model.For<IWidgets>().Default .Lifecycle.ShouldBeOfType<SingletonLifecycle>(); }
+
[Fact] public void set_cache_to_singleton() { var container = new Container(_ => { _.Policies.Add<CacheIsSingleton>(); _.For<IWidgets>().Use<WidgetCache>(); }); // The policy is applied *only* at the time // that StructureMap creates a "build plan" container.GetInstance<IWidgets>() .ShouldBeTheSameAs(container.GetInstance<IWidgets>()); // Now that the policy has executed, we // can verify that WidgetCache is a SingletonThing container.Model.For<IWidgets>().Default .Lifecycle.ShouldBeOfType<SingletonLifecycle>(); }

diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html old mode 100644 new mode 100755 index 7317691..f313dae --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Inline Dependencies

Previous
Registration

@@ -101,12 +101,12 @@
The Registry Class
use the fluent interface methods exposed by the Registry class to create Container configuration. Here's a sample Registry class below used to configure an instance of an IWidget interface:
-
public class PurpleRegistry : Registry { public PurpleRegistry() { For<IWidget>().Use<AWidget>(); } }
+
public class PurpleRegistry : Registry { public PurpleRegistry() { For<IWidget>().Use<AWidget>(); } }

Including Registries

The next question is "how does my new Registry class get used?"

When you set up a Container, you need to simply direct the Container to use the configuration in that Registry class:
-
[Fact] public void include_a_registry() { var registry = new Registry(); registry.IncludeRegistry<YellowBlueRegistry>(); registry.IncludeRegistry<RedGreenRegistry>(); registry.IncludeRegistry<PurpleRegistry>(); // build a container var container = new Container(registry); // verify the default implementation and total registered implementations container.GetInstance<IWidget>().ShouldBeOfType<AWidget>(); container.GetAllInstances<IWidget>().Count().ShouldBe(5); }
+
[Fact] public void include_a_registry() { var registry = new Registry(); registry.IncludeRegistry<YellowBlueRegistry>(); registry.IncludeRegistry<RedGreenRegistry>(); registry.IncludeRegistry<PurpleRegistry>(); // build a container var container = new Container(registry); // verify the default implementation and total registered implementations container.GetInstance<IWidget>().ShouldBeOfType<AWidget>(); container.GetAllInstances<IWidget>().Count().ShouldBe(5); }

Use versus Add

Registrations in the Registry DSL can be done with either Add() or Use() methods, but they have a different semantic meaning to StructureMap. Add() means add another Instance to this plugin type @@ -123,20 +123,20 @@
Use versus Add
modularity scenarios, see Fallback Services and Replace or Clear Out Previous Registrations.

For().Use()

To register the default Instance of a type, the syntax is one of the Registry.For().Use() overloads shown below:
-
public class SettingDefaults : Registry { public SettingDefaults() { // If you know the plugin type and its a closed type // you can use this syntax For<IWidget>().Use<DefaultWidget>(); // By Lambda For<IWidget>().Use(() => new DefaultWidget()); // Pre-existing object For<IWidget>().Use(new AWidget()); // This is rare now, but still valid For<IWidget>().Add<AWidget>().Named("A"); For<IWidget>().Add<BWidget>().Named("B"); For<IWidget>().Use("A"); // makes AWidget the default // Also rare, but you can supply an Instance object // yourself for special needs For<IWidget>().UseInstance(new MySpecialInstance()); // If you're registering an open generic type // or you just have Type objects, use this syntax For(typeof (IService<>)).Use(typeof (Service<>)); // This is occasionally useful for generic types For(typeof (IService<>)).Use(new MySpecialInstance()); } }
+
public class SettingDefaults : Registry { public SettingDefaults() { // If you know the plugin type and its a closed type // you can use this syntax For<IWidget>().Use<DefaultWidget>(); // By Lambda For<IWidget>().Use(() => new DefaultWidget()); // Pre-existing object For<IWidget>().Use(new AWidget()); // This is rare now, but still valid For<IWidget>().Add<AWidget>().Named("A"); For<IWidget>().Add<BWidget>().Named("B"); For<IWidget>().Use("A"); // makes AWidget the default // Also rare, but you can supply an Instance object // yourself for special needs For<IWidget>().UseInstance(new MySpecialInstance()); // If you're registering an open generic type // or you just have Type objects, use this syntax For(typeof (IService<>)).Use(typeof (Service<>)); // This is occasionally useful for generic types For(typeof (IService<>)).Use(new MySpecialInstance()); } }

For().Add()

To register additional Instances for a plugin type, use one of the overloads of For().Add():
-
public class AdditionalRegistrations : Registry { public AdditionalRegistrations() { // If you know the plugin type and its a closed type // you can use this syntax For<IWidget>().Add<DefaultWidget>(); // By Lambda For<IWidget>().Add(() => new DefaultWidget()); // Pre-existing object For<IWidget>().Add(new AWidget()); // Also rare, but you can supply an Instance object // yourself for special needs For<IWidget>().AddInstance(new MySpecialInstance()); // If you're registering an open generic type // or you just have Type objects, use this syntax For(typeof(IService<>)).Add(typeof(Service<>)); // This is occasionally useful for generic types For(typeof(IService<>)).Add(new MySpecialInstance()); } }
+
public class AdditionalRegistrations : Registry { public AdditionalRegistrations() { // If you know the plugin type and its a closed type // you can use this syntax For<IWidget>().Add<DefaultWidget>(); // By Lambda For<IWidget>().Add(() => new DefaultWidget()); // Pre-existing object For<IWidget>().Add(new AWidget()); // Also rare, but you can supply an Instance object // yourself for special needs For<IWidget>().AddInstance(new MySpecialInstance()); // If you're registering an open generic type // or you just have Type objects, use this syntax For(typeof(IService<>)).Add(typeof(Service<>)); // This is occasionally useful for generic types For(typeof(IService<>)).Add(new MySpecialInstance()); } }

Add Many Registrations with For().AddInstances()

If you need to add several Instances to a single plugin type, the AddInstances() syntax shown below may be quicker and easier to use:
-
// registry is a StructureMap Registry object registry.For<IService>().AddInstances(x => { // Equivalent to For<IService>().Add<ColorService>()..... x.Type<ColorService>().Named("Red").Ctor<string>("color").Is("Red"); // Equivalent to For<IService>().Add(new ColorService("Yellow"))...... x.Object(new ColorService("Yellow")).Named("Yellow"); // Equivalent to For<IService>().Use(() => new ColorService("Purple")).... x.ConstructedBy(() => new ColorService("Purple")).Named("Purple"); x.Type<ColorService>().Named("Decorated").Ctor<string>("color").Is("Orange"); });
+
// registry is a StructureMap Registry object registry.For<IService>().AddInstances(x => { // Equivalent to For<IService>().Add<ColorService>()..... x.Type<ColorService>().Named("Red").Ctor<string>("color").Is("Red"); // Equivalent to For<IService>().Add(new ColorService("Yellow"))...... x.Object(new ColorService("Yellow")).Named("Yellow"); // Equivalent to For<IService>().Use(() => new ColorService("Purple")).... x.ConstructedBy(() => new ColorService("Purple")).Named("Purple"); x.Type<ColorService>().Named("Decorated").Ctor<string>("color").Is("Orange"); });

Named Instances

When you have multiple implementations of an interface, it can often be useful to name instances. To retrieve a specific implementation:
-
[Fact] public void SimpleCaseWithNamedInstance() { container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("MyInstance"); }); // retrieve an instance by name var widget = (AWidget)container.GetInstance<IWidget>("MyInstance"); widget.ShouldNotBeNull(); }
+
[Fact] public void SimpleCaseWithNamedInstance() { container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("MyInstance"); }); // retrieve an instance by name var widget = (AWidget)container.GetInstance<IWidget>("MyInstance"); widget.ShouldNotBeNull(); }

You can also register named instances with the following shorthand:
-
[Fact] public void A_concrete_type_is_available_by_name_when_it_is_added_by_the_shorthand_mechanism() { IContainer container = new Container(r => r.For<IAddTypes>().AddInstances(x => { x.Type<RedAddTypes>().Named("Red"); x.Type<GreenAddTypes>().Named("Green"); x.Type<BlueAddTypes>().Named("Blue"); x.Type<PurpleAddTypes>(); })); // retrieve the instances by name container.GetInstance<IAddTypes>("Red").IsType<RedAddTypes>(); container.GetInstance<IAddTypes>("Green").IsType<GreenAddTypes>(); container.GetInstance<IAddTypes>("Blue").IsType<BlueAddTypes>(); }
+
[Fact] public void A_concrete_type_is_available_by_name_when_it_is_added_by_the_shorthand_mechanism() { IContainer container = new Container(r => r.For<IAddTypes>().AddInstances(x => { x.Type<RedAddTypes>().Named("Red"); x.Type<GreenAddTypes>().Named("Green"); x.Type<BlueAddTypes>().Named("Blue"); x.Type<PurpleAddTypes>(); })); // retrieve the instances by name container.GetInstance<IAddTypes>("Red").IsType<RedAddTypes>(); container.GetInstance<IAddTypes>("Green").IsType<GreenAddTypes>(); container.GetInstance<IAddTypes>("Blue").IsType<BlueAddTypes>(); }

diff --git a/release-notes/index.html b/release-notes/index.html old mode 100644 new mode 100755 index ceb9fc6..871ae29 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Custom Instance Types

Previous
History

diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html old mode 100644 new mode 100755 index d1d6780..e335a48 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Get all Services by Plugin Type

Previous
Get a Service by PluginType

@@ -91,7 +91,7 @@
Get a Service by Plugin Type and Name [Fact] public void get_a_named_instance() { var container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("A"); x.For<IWidget>().Add<BWidget>().Named("B"); x.For<IWidget>().Add<CWidget>().Named("C"); }); container.GetInstance<IWidget>("A").ShouldBeOfType<AWidget>(); container.GetInstance<IWidget>("B").ShouldBeOfType<BWidget>(); container.GetInstance<IWidget>("C").ShouldBeOfType<CWidget>(); // or container.GetInstance(typeof(IWidget), "A").ShouldBeOfType<AWidget>(); container.GetInstance(typeof(IWidget), "B").ShouldBeOfType<BWidget>(); container.GetInstance(typeof(IWidget), "C").ShouldBeOfType<CWidget>(); } +
[Fact] public void get_a_named_instance() { var container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("A"); x.For<IWidget>().Add<BWidget>().Named("B"); x.For<IWidget>().Add<CWidget>().Named("C"); }); container.GetInstance<IWidget>("A").ShouldBeOfType<AWidget>(); container.GetInstance<IWidget>("B").ShouldBeOfType<BWidget>(); container.GetInstance<IWidget>("C").ShouldBeOfType<CWidget>(); // or container.GetInstance(typeof(IWidget), "A").ShouldBeOfType<AWidget>(); container.GetInstance(typeof(IWidget), "B").ShouldBeOfType<BWidget>(); container.GetInstance(typeof(IWidget), "C").ShouldBeOfType<CWidget>(); }

diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html old mode 100644 new mode 100755 index 4273ae0..803e694 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Get a Service by Plugin Type and Name

Previous
Resolving Services

@@ -91,7 +91,7 @@
Get a Service by PluginType [Fact] public void get_the_default_instance() { var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); // or container.GetInstance(typeof(IWidget)) .ShouldBeOfType<AWidget>(); } +
[Fact] public void get_the_default_instance() { var container = new Container(x => { x.For<IWidget>().Use<AWidget>(); }); container.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); // or container.GetInstance(typeof(IWidget)) .ShouldBeOfType<AWidget>(); }

diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html old mode 100644 new mode 100755 index a7fb8ff..5806cfa --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Try Getting an Optional Service by Plugin Type

Previous
Get a Service by Plugin Type and Name

@@ -93,7 +93,7 @@
Get all Services by Plugin Type Working with Enumerable Types for a lot more information about what's going on behind the scenes.

Once in a while you might want to get an enumerable of all the configured objects for a PluginType. That's done with the GetAllInstances() method shown below:
-
[Fact] public void get_all_instances() { var container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("A"); x.For<IWidget>().Add<BWidget>().Named("B"); x.For<IWidget>().Add<CWidget>().Named("C"); }); container.GetAllInstances<IWidget>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // or container.GetAllInstances(typeof(IWidget)) .OfType<IWidget>() // returns an IEnumerable, so I'm casting here .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); }
+
[Fact] public void get_all_instances() { var container = new Container(x => { x.For<IWidget>().Add<AWidget>().Named("A"); x.For<IWidget>().Add<BWidget>().Named("B"); x.For<IWidget>().Add<CWidget>().Named("C"); }); container.GetAllInstances<IWidget>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // or container.GetAllInstances(typeof(IWidget)) .OfType<IWidget>() // returns an IEnumerable, so I'm casting here .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); }

GetAllInstances() respects the order in which the actual instances are configured in the Container. Be warned that some other IoC tools make different assumptions if you are coming from a different tool.

diff --git a/resolving/index.html b/resolving/index.html old mode 100644 new mode 100755 index 209cf07..1571e5b --- a/resolving/index.html +++ b/resolving/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Get a Service by PluginType

Previous
Registration

diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html old mode 100644 new mode 100755 index c575bd5..20c94ad --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Auto Resolving Concrete Types

Previous
Try Geting an Optional Service by Plugin Type and Name

@@ -100,25 +100,25 @@
Passing Arguments at Runtime -
public class ColorWidget : IWidget { public string Color { get; set; } public ColorWidget(string color) { Color = color; } } public class GuyWithWidgetAndService { public IWidget Widget { get; set; } public IService Service { get; set; } public GuyWithWidgetAndService(IWidget widget, IService service) { Widget = widget; Service = service; } }
+
public class ColorWidget : IWidget { public string Color { get; set; } public ColorWidget(string color) { Color = color; } } public class GuyWithWidgetAndService { public IWidget Widget { get; set; } public IService Service { get; set; } public GuyWithWidgetAndService(IWidget widget, IService service) { Widget = widget; Service = service; } }

and unless stated otherwise in a sample, a Container configured like so:
-
var container = new Container(x => { x.For<IWidget>().Use<BWidget>(); x.For<IService>().Use<AService>(); });
+
var container = new Container(x => { x.For<IWidget>().Use<BWidget>(); x.For<IService>().Use<AService>(); });

Passing Named Arguments

The original usage of explicit arguments was to replace primitive arguments to constructor functions like this sample:
-
[Fact] public void supply_named_arguments() { var container = new Container(x => { x.For<IWidget>().Use<ColorWidget>().Ctor<string>().Is("Red"); }); container.GetInstance<IWidget>() .ShouldBeOfType<ColorWidget>() .Color.ShouldBe("Red"); container.With("color").EqualTo("Blue") .GetInstance<IWidget>() .ShouldBeOfType<ColorWidget>() .Color.ShouldBe("Blue"); }
+
[Fact] public void supply_named_arguments() { var container = new Container(x => { x.For<IWidget>().Use<ColorWidget>().Ctor<string>().Is("Red"); }); container.GetInstance<IWidget>() .ShouldBeOfType<ColorWidget>() .Color.ShouldBe("Red"); container.With("color").EqualTo("Blue") .GetInstance<IWidget>() .ShouldBeOfType<ColorWidget>() .Color.ShouldBe("Blue"); }

The canonical usage is overriding file paths, database connection string, or urls.

Passing Arguments with a Fluent Interface

You can invoke the explicit argument passing as a fluent interface starting with IContainer.With() like the following sample:
-
var widget = new BWidget(); var service = new BService(); var guyWithWidgetAndService = container .With<IWidget>(widget) .With<IService>(service) .GetInstance<GuyWithWidgetAndService>(); guyWithWidgetAndService .Widget.ShouldBeTheSameAs(widget); guyWithWidgetAndService .Service.ShouldBeTheSameAs(service);
+
var widget = new BWidget(); var service = new BService(); var guyWithWidgetAndService = container .With<IWidget>(widget) .With<IService>(service) .GetInstance<GuyWithWidgetAndService>(); guyWithWidgetAndService .Widget.ShouldBeTheSameAs(widget); guyWithWidgetAndService .Service.ShouldBeTheSameAs(service);

Using a Nested Closure

If you dislike fluent interfaces or want to pass in a lot of dependencies, the nested closure syntax might be more usable:
-
var widget = new BWidget(); var service = new BService(); var guyWithWidgetAndService = container .With(x => { x.With<IWidget>(widget); x.With<IService>(service); }) .GetInstance<GuyWithWidgetAndService>(); guyWithWidgetAndService .Widget.ShouldBeTheSameAs(widget); guyWithWidgetAndService .Service.ShouldBeTheSameAs(service);
+
var widget = new BWidget(); var service = new BService(); var guyWithWidgetAndService = container .With(x => { x.With<IWidget>(widget); x.With<IService>(service); }) .GetInstance<GuyWithWidgetAndService>(); guyWithWidgetAndService .Widget.ShouldBeTheSameAs(widget); guyWithWidgetAndService .Service.ShouldBeTheSameAs(service);

Using the ExplicitArguments object

Finally, you can also pass an object of type ExplicitArguments directly to an overload of the IContainer.GetInstance() method:
-
var widget = new BWidget(); var service = new BService(); var args = new ExplicitArguments(); args.Set<IWidget>(widget); args.Set<IService>(service); var guyWithWidgetAndService = container .GetInstance<GuyWithWidgetAndService>(args); guyWithWidgetAndService .Widget.ShouldBeTheSameAs(widget); guyWithWidgetAndService .Service.ShouldBeTheSameAs(service);
+
var widget = new BWidget(); var service = new BService(); var args = new ExplicitArguments(); args.Set<IWidget>(widget); args.Set<IService>(service); var guyWithWidgetAndService = container .GetInstance<GuyWithWidgetAndService>(args); guyWithWidgetAndService .Widget.ShouldBeTheSameAs(widget); guyWithWidgetAndService .Service.ShouldBeTheSameAs(service);

diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html old mode 100644 new mode 100755 index 24ab808..129a66e --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
The Container

Previous
Passing Arguments at Runtime

@@ -97,10 +97,10 @@
Auto Resolving Concrete Types -
public class Weather { public Location Location { get; set; } public Atmosphere Atmosphere { get; set; } public Wind Wind { get; set; } public Condition Condition { get; set; } public Weather(Location location, Atmosphere atmosphere, Wind wind, Condition condition) { Location = location; Atmosphere = atmosphere; Wind = wind; Condition = condition; } } public class Location { //some properties } public class Atmosphere { //some properties } public class Wind { //some properties } public class Condition { //some properties }
+
public class Weather { public Location Location { get; set; } public Atmosphere Atmosphere { get; set; } public Wind Wind { get; set; } public Condition Condition { get; set; } public Weather(Location location, Atmosphere atmosphere, Wind wind, Condition condition) { Location = location; Atmosphere = atmosphere; Wind = wind; Condition = condition; } } public class Location { //some properties } public class Atmosphere { //some properties } public class Wind { //some properties } public class Condition { //some properties }

Before we can resolve the concrete Weather type, we need an instance of an Container object. As mentioned earlier, these objects defines a generic GetInstance method which can build us an instance of the Weather type.

You can create a container yourself or use the statically accessed container.
-
var container = new Container(); var weather1 = container.GetInstance<Weather>(); var weather2 = container.GetInstance<Weather>(); weather2 = container.GetInstance<Weather>(); //short version for above.
+
var container = new Container(); var weather1 = container.GetInstance<Weather>(); var weather2 = container.GetInstance<Weather>(); weather2 = container.GetInstance<Weather>(); //short version for above.

The reason why we don't need to supply any configuration is because StructureMap supports a concept called Auto Wiring. It's basically a smart way of building instances of types by looking to the constructors of the requested and all the needed underlaying types. During this inspection StructureMap also uses any provided configuration to help building the requested service or dependency.

In our example, where there isn't any configuration available, StructureMap looks at the constructor of the requested Weather type. It sees that it depends on four concrete types which all have a default constructor. StructureMap is therefore able to create an instance for all of them and inject them into the Weather constructor. After that the Weather instance is returned to the caller.

Most of the time you will be mapping abstractions to concrete types, but as you have seen StructureMap supports other use cases as well.
diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html old mode 100644 new mode 100755 index 1c68576..65d4e58 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Passing Arguments at Runtime

Previous
Try Getting an Optional Service by Plugin Type

@@ -91,7 +91,7 @@
Try Geting an Optional Service by Plugin Type and Name [Fact] public void TryGetInstanceViaNameAndGeneric_ReturnsInstance_WhenTypeFound() { addColorInstance("Red"); addColorInstance("Orange"); addColorInstance("Blue"); // "Orange" exists, so an object should be returned var instance = _container.TryGetInstance<Rule>("Orange"); instance.ShouldBeOfType(typeof(ColorRule)); } +
[Fact] public void TryGetInstanceViaNameAndGeneric_ReturnsInstance_WhenTypeFound() { addColorInstance("Red"); addColorInstance("Orange"); addColorInstance("Blue"); // "Orange" exists, so an object should be returned var instance = _container.TryGetInstance<Rule>("Orange"); instance.ShouldBeOfType(typeof(ColorRule)); }

diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html old mode 100644 new mode 100755 index 6bed72c..2598d2a --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Try Geting an Optional Service by Plugin Type and Name

Previous
Get all Services by Plugin Type

@@ -97,24 +97,24 @@
Try Getting an Optional Service by Plugin Type optional dependencies through the usage of the IContainer.TryGetInstance() methods.

Say you have a simple interface IFoo that may or may not be registered in the Container:
-
public interface IFoo { } public class Foo : IFoo { }
+
public interface IFoo { } public class Foo : IFoo { }

In your own code you might request the IFoo service like the code below, knowing that you'll take responsibility yourself for building the IFoo service if StructureMap doesn't have a registration for IFoo:
-
public class MyFoo : IFoo { } [Fact] public void real_usage() { var container = new Container(); // if the container doesn't know about it, // I'll build it myself var foo = container.TryGetInstance<IFoo>() ?? new MyFoo(); }
+
public class MyFoo : IFoo { } [Fact] public void real_usage() { var container = new Container(); // if the container doesn't know about it, // I'll build it myself var foo = container.TryGetInstance<IFoo>() ?? new MyFoo(); }

Just to make this perfectly clear, if StructureMap has a default registration for IFoo, you get this behavior:
-
[Fact] public void i_have_got_that() { var container = new Container(_ => _.For<IFoo>().Use<Foo>()); container.TryGetInstance<IFoo>() .ShouldNotBeNull(); // -- or -- container.TryGetInstance(typeof(IFoo)) .ShouldNotBeNull(); }
+
[Fact] public void i_have_got_that() { var container = new Container(_ => _.For<IFoo>().Use<Foo>()); container.TryGetInstance<IFoo>() .ShouldNotBeNull(); // -- or -- container.TryGetInstance(typeof(IFoo)) .ShouldNotBeNull(); }

If StructureMap knows nothing about IFoo, you get a null:
-
[Fact] public void i_do_not_have_that() { var container = new Container(); container.TryGetInstance<IFoo>() .ShouldBeNull(); // -- or -- container.TryGetInstance(typeof(IFoo)) .ShouldBeNull(); }
+
[Fact] public void i_do_not_have_that() { var container = new Container(); container.TryGetInstance<IFoo>() .ShouldBeNull(); // -- or -- container.TryGetInstance(typeof(IFoo)) .ShouldBeNull(); }

Concrete Types

Since it's not a perfect world, there are some gotchas you need to be aware of. While StructureMap will happily auto-resolve concrete types that aren't registered, that does not apply to the TryGetInstance mechanism:
-
public class ConcreteThing { } [Fact] public void no_auto_resolution_of_concrete_types() { var container = new Container(); container.TryGetInstance<ConcreteThing>() .ShouldBeNull(); // now register ConcreteThing and do it again container.Configure(_ => { _.For<ConcreteThing>().Use<ConcreteThing>(); }); container.TryGetInstance<ConcreteThing>() .ShouldNotBeNull(); }
+
public class ConcreteThing { } [Fact] public void no_auto_resolution_of_concrete_types() { var container = new Container(); container.TryGetInstance<ConcreteThing>() .ShouldBeNull(); // now register ConcreteThing and do it again container.Configure(_ => { _.For<ConcreteThing>().Use<ConcreteThing>(); }); container.TryGetInstance<ConcreteThing>() .ShouldNotBeNull(); }

Optional Generic Types

If you are using open generic types, the TryGetInstance() mechanism can close the open generic registration to satisfy the optional dependency like this sample:
-
public interface IThing<T> { } public class Thing<T> : IThing<T> { } [Fact] public void can_try_get_open_type_resolution() { var container = new Container(_ => { _.For(typeof(IThing<>)).Use(typeof(Thing<>)); }); container.TryGetInstance<IThing<string>>() .ShouldBeOfType<Thing<string>>(); }
+
public interface IThing<T> { } public class Thing<T> : IThing<T> { } [Fact] public void can_try_get_open_type_resolution() { var container = new Container(_ => { _.For(typeof(IThing<>)).Use(typeof(Thing<>)); }); container.TryGetInstance<IThing<string>>() .ShouldBeOfType<Thing<string>>(); }

diff --git a/roadmap/index.html b/roadmap/index.html old mode 100644 new mode 100755 index 192dfbf..c71f0ba --- a/roadmap/index.html +++ b/roadmap/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
A Gentle Quickstart

Previous
Documentation

diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100644 new mode 100755 index 1cc9840..a7cdd71 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Registration

Previous
Software Design Concepts

@@ -100,7 +100,7 @@
Setter Injection Explicit Setter Injection with [SetterProperty] Attributes

The simplest conceptual way to force StructureMap into making public setters mandatory service dependencies by decorating setter properties with the [SetterProperty] attribute like this example:
-
public class Repository { private IDataProvider _provider; // Adding the SetterProperty to a setter directs // StructureMap to use this property when // constructing a Repository instance [SetterProperty] public IDataProvider Provider { set { _provider = value; } } [SetterProperty] public bool ShouldCache { get; set; } }
+
public class Repository { private IDataProvider _provider; // Adding the SetterProperty to a setter directs // StructureMap to use this property when // constructing a Repository instance [SetterProperty] public IDataProvider Provider { set { _provider = value; } } [SetterProperty] public bool ShouldCache { get; set; } }

Without the [SetterProperty] attributes decorating the setters, StructureMap would ignore the Provider and ShouldCache properties when it builds up a Repository object. With the attributes, StructureMap will try to build and attach values for the two properties as part of object construction.

If you were to look at StructureMap's "build plan" for the Repository class, you would see something like this:

@@ -113,7 +113,7 @@
Explicit Sette
If you intensely dislike runaway attribute usage, that's okay because there are other ways to enable setter injection in StructureMap.

Inline Setter Configuration

Any setter property not configured with [SetterProperty] or the setter policies in the next section can still be filled by StructureMap if an inline dependency is configured matching that setter property as shown in the example below:
-
public class RuleWithSetters : IEventRule { public ICondition Condition { get; set; } public IAction Action { get; set; } public void ProcessEvent(SomeEvent @event) { if (Condition.Matches(@event)) { Action.PerformWork(@event); } } } public class RuleWithSettersRegistry : Registry { public RuleWithSettersRegistry() { For<IEventRule>().Use<RuleWithSetters>() .Setter<ICondition>().Is<Condition1>() // or .Setter(x => x.Action).Is(new Action1()) // or if you need to specify the name .Setter<IAction>("Action").Is<Action2>() // or you can configure values *after* the object // is constructed with the SetProperty method .SetProperty(x => x.Action = new Action2()); } }
+
public class RuleWithSetters : IEventRule { public ICondition Condition { get; set; } public IAction Action { get; set; } public void ProcessEvent(SomeEvent @event) { if (Condition.Matches(@event)) { Action.PerformWork(@event); } } } public class RuleWithSettersRegistry : Registry { public RuleWithSettersRegistry() { For<IEventRule>().Use<RuleWithSetters>() .Setter<ICondition>().Is<Condition1>() // or .Setter(x => x.Action).Is(new Action1()) // or if you need to specify the name .Setter<IAction>("Action").Is<Action2>() // or you can configure values *after* the object // is constructed with the SetProperty method .SetProperty(x => x.Action = new Action2()); } }

See also:

Inline Dependencies
@@ -121,12 +121,12 @@
Inline Setter Configuration

Setter Injection Policies

Lastly, you can give StructureMap some criteria for determining which setters should be mandatory dependencies with the Registry.Policies.SetAllProperties() method during Container setup as shown in this example below:
-
public class ClassWithNamedProperties { public int Age { get; set; } public string LastName { get; set; } public string FirstName { get; set; } public IGateway Gateway { get; set; } public IService Service { get; set; } } [Fact] public void specify_setter_policy_and_construct_an_object() { var theService = new ColorService("red"); var container = new Container(x => { x.For<IService>().Use(theService); x.For<IGateway>().Use<DefaultGateway>(); x.ForConcreteType<ClassWithNamedProperties>().Configure.Setter<int>().Is(5); x.Policies.SetAllProperties( policy => policy.WithAnyTypeFromNamespace("StructureMap.Testing.Widget3")); }); var description = container.Model.For<ClassWithNamedProperties>().Default.DescribeBuildPlan(); Debug.WriteLine(description); var target = container.GetInstance<ClassWithNamedProperties>(); target.Service.ShouldBeTheSameAs(theService); target.Gateway.ShouldBeOfType<DefaultGateway>(); }
+
public class ClassWithNamedProperties { public int Age { get; set; } public string LastName { get; set; } public string FirstName { get; set; } public IGateway Gateway { get; set; } public IService Service { get; set; } } [Fact] public void specify_setter_policy_and_construct_an_object() { var theService = new ColorService("red"); var container = new Container(x => { x.For<IService>().Use(theService); x.For<IGateway>().Use<DefaultGateway>(); x.ForConcreteType<ClassWithNamedProperties>().Configure.Setter<int>().Is(5); x.Policies.SetAllProperties( policy => policy.WithAnyTypeFromNamespace("StructureMap.Testing.Widget3")); }); var description = container.Model.For<ClassWithNamedProperties>().Default.DescribeBuildPlan(); Debug.WriteLine(description); var target = container.GetInstance<ClassWithNamedProperties>(); target.Service.ShouldBeTheSameAs(theService); target.Gateway.ShouldBeOfType<DefaultGateway>(); }

All calls to Registry.Policies.SetAllProperties() are additive, meaning you can use as many criteria as possible for setter injection.

Filling Setter's of an Object

You can run into situations where you'll want StructureMap to fill the setter dependencies of an object that is built outside of your own code and cannot be built by StructureMap itself. Action filter attributes from ASP.Net MVC are an obvious example.

You're still in luck because StructureMap has the BuildUp(object) method for just this scenario as shown in this example from the unit tests:
-
public class BuildUpTarget1 { public IGateway Gateway { get; set; } public IService Service { get; set; } } [Fact] public void create_a_setter_rule_and_see_it_applied_in_BuildUp() { var theGateway = new DefaultGateway(); var container = new Container(x => { x.For<IGateway>().Use(theGateway); x.Policies.SetAllProperties(y => y.OfType<IGateway>()); }); var target = new BuildUpTarget1(); container.BuildUp(target); target.Gateway.ShouldBeTheSameAs(theGateway); target.Service.ShouldBeNull(); }
+
public class BuildUpTarget1 { public IGateway Gateway { get; set; } public IService Service { get; set; } } [Fact] public void create_a_setter_rule_and_see_it_applied_in_BuildUp() { var theGateway = new DefaultGateway(); var container = new Container(x => { x.For<IGateway>().Use(theGateway); x.Policies.SetAllProperties(y => y.OfType<IGateway>()); }); var target = new BuildUpTarget1(); container.BuildUp(target); target.Gateway.ShouldBeTheSameAs(theGateway); target.Service.ShouldBeNull(); }

The normal rules for what setters should be filled as described above apply to BuildUp().

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html old mode 100644 new mode 100755 index 22d3038..396c45b --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Setter Injection

Previous
Features

@@ -96,10 +96,10 @@
Inversion of Control

An IoC container like StructureMap uses the Inversion of Control concept to simplify your internal services by freeing them from having to know how to find, build, or clean up their dependencies.

Dependency Injection

Dependency Injection is nothing more than pushing dependencies of an object into constructor functions or setter properties instead of that object doing everything for itself. If you are strictly using Dependency Injection to fill the dependencies of your classes, your code should have no coupling to StructureMap itself.
-
public interface IDatabase { } public class DatabaseUser { // Using Constructor Injection public DatabaseUser(IDatabase database) { } } public class OtherDatabaseUser { // Setter Injection public IDatabase Database { get; set; } }
+
public interface IDatabase { } public class DatabaseUser { // Using Constructor Injection public DatabaseUser(IDatabase database) { } } public class OtherDatabaseUser { // Setter Injection public IDatabase Database { get; set; } }

Service Locator

StructureMap also fills the role of a service locator. In this usage, your code would directly access StructureMap's Container class to build or resolve services upon demand like this sample:
-
public class ThirdDatabaseUser { private IDatabase _database; public ThirdDatabaseUser(IContainer container) { // This is service location _database = container.GetInstance<IDatabase>(); } }
+
public class ThirdDatabaseUser { private IDatabase _database; public ThirdDatabaseUser(IContainer container) { // This is service location _database = container.GetInstance<IDatabase>(); } }

Since IoC tools like StructureMap have come onto the software scene, many developers have very badly overused the service locator pattern and many other developers have become very vocal in their distaste for service location. The StructureMap team simply recommends that you favor Dependency Injection wherever possible, but that some service location in your system where you may need more advanced building options or lazy resolution of services is probably just fine.

diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html old mode 100644 new mode 100755 index c837df4..918b382 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Building Objects with Lambdas

Previous
The Container

@@ -91,18 +91,18 @@
Auto Wiring -
// This is the wrong way to use an IoC container. Do NOT invoke the container from // the constructor function. This tightly couples the ShippingScreenPresenter to // the IoC container in a harmful way. This class cannot be used in either // production or testing without a valid IoC configuration. Plus, you're writing more // code public ShippingScreenPresenter(IContainer container) { // It's even worse if you use a static facade to retrieve // a service locator! _service = container.GetInstance<IShippingService>(); _repository = container.GetInstance<IRepository>(); }
+
// This is the wrong way to use an IoC container. Do NOT invoke the container from // the constructor function. This tightly couples the ShippingScreenPresenter to // the IoC container in a harmful way. This class cannot be used in either // production or testing without a valid IoC configuration. Plus, you're writing more // code public ShippingScreenPresenter(IContainer container) { // It's even worse if you use a static facade to retrieve // a service locator! _service = container.GetInstance<IShippingService>(); _repository = container.GetInstance<IRepository>(); }

Instead of binding ShippingScreenPresenter so tightly to StructureMap and having to explicitly fetch its dependencies, let's switch it to using StructureMap a little more idiomatically and just exposing a constructor function with the necessary dependencies as arguments:
-
// This is the way to write a Constructor Function with an IoC tool // Let the IoC container "inject" services from outside, and keep // ShippingScreenPresenter ignorant of the IoC infrastructure public ShippingScreenPresenter(IShippingService service, IRepository repository) { _service = service; _repository = repository; }
+
// This is the way to write a Constructor Function with an IoC tool // Let the IoC container "inject" services from outside, and keep // ShippingScreenPresenter ignorant of the IoC infrastructure public ShippingScreenPresenter(IShippingService service, IRepository repository) { _service = service; _repository = repository; }

As long as a StructureMap Container knows how to resolve the IRepository and IShippingService interfaces, StructureMap can build ShippingScreenPresenter by using "auto-wiring." All this means is that instead of forcing you to explicitly configure all the dependencies for ShippingScreenPresenter, StructureMap can infer from the public constructor function and public property setters what dependencies ShippingScreenPresenter needs and uses the defaults of both to build it out.

Looking at the build plan for ShippingScreenPresenter:
-
public void ShowBuildPlan() { var container = new Container(_ => { _.For<IShippingService>().Use<InternalShippingService>(); _.For<IRepository>().Use<SimpleRepository>(); }); // Just proving that we can build ShippingScreenPresenter;) container.GetInstance<ShippingScreenPresenter>().ShouldNotBeNull(); var buildPlan = container.Model.For<ShippingScreenPresenter>().Default.DescribeBuildPlan(1); Debug.WriteLine(buildPlan); }
+
public void ShowBuildPlan() { var container = new Container(_ => { _.For<IShippingService>().Use<InternalShippingService>(); _.For<IRepository>().Use<SimpleRepository>(); }); // Just proving that we can build ShippingScreenPresenter;) container.GetInstance<ShippingScreenPresenter>().ShouldNotBeNull(); var buildPlan = container.Model.For<ShippingScreenPresenter>().Default.DescribeBuildPlan(1); Debug.WriteLine(buildPlan); }

give us:

PluginType: StructureMap.Testing.DocumentationExamples.ShippingScreenPresenter diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html old mode 100644 new mode 100755 index 9a4f115..de6e948 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Working with Primitive Types

Previous
Lazy Resolution

@@ -92,13 +92,13 @@
StructureMap and IDisposable Singletons

This one is easy, any object marked as the Singleton lifecycle that implements IDisposable is disposed when the root container is disposed:
-
[Fact] public void singletons_are_disposed_when_the_container_is_disposed() { var container = new Container(_ => { _.ForSingletonOf<DisposableSingleton>(); }); // As a singleton-scoped object, every request for DisposableSingleton // will return the same object var singleton = container.GetInstance<DisposableSingleton>(); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.WasDisposed.ShouldBeFalse(); // now, dispose the Container container.Dispose(); // the SingletonThing scoped object should be disposed singleton.WasDisposed.ShouldBeTrue(); }
+
[Fact] public void singletons_are_disposed_when_the_container_is_disposed() { var container = new Container(_ => { _.ForSingletonOf<DisposableSingleton>(); }); // As a singleton-scoped object, every request for DisposableSingleton // will return the same object var singleton = container.GetInstance<DisposableSingleton>(); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>()); singleton.WasDisposed.ShouldBeFalse(); // now, dispose the Container container.Dispose(); // the SingletonThing scoped object should be disposed singleton.WasDisposed.ShouldBeTrue(); }

Ejecting a singleton-scoped object will also force it to be disposed. See Using the Container Model for more information on how to eject singletons from a running Container.

Nested Containers

As discussed in Nested Containers (Per Request/Transaction), any transient, AlwaysUnique (as of 4.0), or container-scoped object that implements IDisposable and is created by a nested container will be disposed as the nested container is disposed:
-
[Fact] public void nested_container_disposal() { var container = new Container(_ => { // A SingletonThing scoped service _.ForSingletonOf<IColorCache>().Use<ColorCache>(); // A transient scoped service _.For<IColor>().Use<Green>(); // An AlwaysUnique scoped service _.For<Purple>().AlwaysUnique(); }); ColorCache singleton = null; Green nestedGreen = null; Blue nestedBlue = null; Purple nestedPurple = null; using (var nested = container.GetNestedContainer()) { // SingletonThing's are really built by the parent singleton = nested.GetInstance<IColorCache>() .ShouldBeOfType<ColorCache>(); nestedGreen = nested.GetInstance<IColor>() .ShouldBeOfType<Green>(); nestedBlue = nested.GetInstance<Blue>(); nestedPurple = nested.GetInstance<Purple>(); } // Transients created by the Nested Container // are disposed nestedGreen.WasDisposed.ShouldBeTrue(); nestedBlue.WasDisposed.ShouldBeTrue(); // Unique's created by the Nested Container // are disposed nestedPurple.WasDisposed.ShouldBeTrue(); // NOT disposed because it's owned by // the parent container singleton.WasDisposed.ShouldBeFalse(); }
+
[Fact] public void nested_container_disposal() { var container = new Container(_ => { // A SingletonThing scoped service _.ForSingletonOf<IColorCache>().Use<ColorCache>(); // A transient scoped service _.For<IColor>().Use<Green>(); // An AlwaysUnique scoped service _.For<Purple>().AlwaysUnique(); }); ColorCache singleton = null; Green nestedGreen = null; Blue nestedBlue = null; Purple nestedPurple = null; using (var nested = container.GetNestedContainer()) { // SingletonThing's are really built by the parent singleton = nested.GetInstance<IColorCache>() .ShouldBeOfType<ColorCache>(); nestedGreen = nested.GetInstance<IColor>() .ShouldBeOfType<Green>(); nestedBlue = nested.GetInstance<Blue>(); nestedPurple = nested.GetInstance<Purple>(); } // Transients created by the Nested Container // are disposed nestedGreen.WasDisposed.ShouldBeTrue(); nestedBlue.WasDisposed.ShouldBeTrue(); // Unique's created by the Nested Container // are disposed nestedPurple.WasDisposed.ShouldBeTrue(); // NOT disposed because it's owned by // the parent container singleton.WasDisposed.ShouldBeFalse(); }

Transients

Regardless of the new tracking/release mode, the StructureMap team still strongly recommends using a nested container per HTTP request or service bus message handling session or logical transaction to deal with disposing transient objects.
@@ -106,7 +106,7 @@
Transients
IDisposable is completely up to the user in this case. The StructureMap team has long believed that trying to track transient disposables with an explicit Release(object) mode as other IoC containers behave would do more harm than good (memory leaks from forgetting to call Release(), more work on the user).

That all being said, in order to comply with the new ASP.Net vNext compliance behavior, StructureMap 4.0 introduces a new opt-in transient tracking mode with the prerequisite Release(object) method:
-
[Fact] public void release_transient_created_by_root_container() { var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode); container.TransientTracking.ShouldBeOfType<TrackingTransientCache>(); var transient1 = container.GetInstance<DisposableGuy>(); var transient2 = container.GetInstance<DisposableGuy>(); transient1.WasDisposed.ShouldBeFalse(); transient2.WasDisposed.ShouldBeFalse(); // release ONLY transient2 container.Release(transient2); transient1.WasDisposed.ShouldBeFalse(); transient2.WasDisposed.ShouldBeTrue(); // transient2 should no longer be // tracked by the container container.TransientTracking.Tracked .Single() .ShouldBeTheSameAs(transient1); } [Fact] public void disposing_the_container_disposes_tracked_transients() { var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode); var transient1 = container.GetInstance<DisposableGuy>(); var transient2 = container.GetInstance<DisposableGuy>(); transient1.WasDisposed.ShouldBeFalse(); transient2.WasDisposed.ShouldBeFalse(); container.Dispose(); transient1.WasDisposed.ShouldBeTrue(); transient2.WasDisposed.ShouldBeTrue(); }
+
[Fact] public void release_transient_created_by_root_container() { var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode); container.TransientTracking.ShouldBeOfType<TrackingTransientCache>(); var transient1 = container.GetInstance<DisposableGuy>(); var transient2 = container.GetInstance<DisposableGuy>(); transient1.WasDisposed.ShouldBeFalse(); transient2.WasDisposed.ShouldBeFalse(); // release ONLY transient2 container.Release(transient2); transient1.WasDisposed.ShouldBeFalse(); transient2.WasDisposed.ShouldBeTrue(); // transient2 should no longer be // tracked by the container container.TransientTracking.Tracked .Single() .ShouldBeTheSameAs(transient1); } [Fact] public void disposing_the_container_disposes_tracked_transients() { var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode); var transient1 = container.GetInstance<DisposableGuy>(); var transient2 = container.GetInstance<DisposableGuy>(); transient1.WasDisposed.ShouldBeFalse(); transient2.WasDisposed.ShouldBeFalse(); container.Dispose(); transient1.WasDisposed.ShouldBeTrue(); transient2.WasDisposed.ShouldBeTrue(); }

As of right now, StructureMap will only track the top level object requested from a Container and not all the other IDisposable objects that may have been created as part of the main object graph.
diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html old mode 100644 new mode 100755 index 904161f..9b28ea9 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Profiles and Child Containers

Previous
Working with the IContext at Build Time

@@ -97,14 +97,14 @@
Registering a Single Instance Against Multiple PluginTypes IReader interface for that role. Other consumers will only make updates to the StatefulCache, so we'll also have an IWriter interface as shown below:
-
public interface IWriter { } public interface IReader { } public class StatefulCache : IReader, IWriter { }
+
public interface IWriter { } public interface IReader { } public class StatefulCache : IReader, IWriter { }

What we need from StructureMap is a way to make all requests to either IReader and IWriter resolve to the same singleton object instance of StatefulCache.

StructureMap provides the Forward<TFrom, TTo>() mechanism for exactly this purpose:
-
[Fact] public void stateful_cache_serves_multiple_interfaces() { var container = new Container(_ => { // Let's make StatefulCache a SingletonThing in the container _.ForConcreteType<StatefulCache>().Configure.Singleton(); _.Forward<StatefulCache, IReader>(); _.Forward<StatefulCache, IWriter>(); }); container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>(); container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>(); }
+
[Fact] public void stateful_cache_serves_multiple_interfaces() { var container = new Container(_ => { // Let's make StatefulCache a SingletonThing in the container _.ForConcreteType<StatefulCache>().Configure.Singleton(); _.Forward<StatefulCache, IReader>(); _.Forward<StatefulCache, IWriter>(); }); container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>(); container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>(); }

And because the syntax has consistently been confusing to users (including me even though I wrote it), here's how to effect the same registration with lambda registrations:
-
[Fact] public void equivalent() { var container = new Container(_ => { // Let's make StatefulCache a SingletonThing in the container _.ForConcreteType<StatefulCache>().Configure.Singleton(); _.For<IReader>().Use(c => c.GetInstance<StatefulCache>()); _.For<IWriter>().Use(c => c.GetInstance<StatefulCache>()); }); container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>(); container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>(); }
+
[Fact] public void equivalent() { var container = new Container(_ => { // Let's make StatefulCache a SingletonThing in the container _.ForConcreteType<StatefulCache>().Configure.Singleton(); _.For<IReader>().Use(c => c.GetInstance<StatefulCache>()); _.For<IWriter>().Use(c => c.GetInstance<StatefulCache>()); }); container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>(); container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>(); }

diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html old mode 100644 new mode 100755 index fef38af..cc54ab3 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Lazy Resolution

Previous
Working with Enumerable Types

@@ -95,31 +95,31 @@
Handling Missing Named Instances Missing Named Instance feature in StructureMap.

I've always thought of this feature as being somewhat akin to Ruby's Method Missing language feature.

Using the contrived example from the StructureMap tests for this feature, let's say that you have a simple interface and object implementation like this:
-
public interface Rule { } public class ColorRule : Rule { public string Color { get; set; } public ColorRule(string color) { Color = color; } }
+
public interface Rule { } public class ColorRule : Rule { public string Color { get; set; } public ColorRule(string color) { Color = color; } }

If a user asks the container for a named Rule by a name and that rule doesn't exist, we'll just build a ColorRule where the Color property should be the name of the Instance requested. That registration and the usage is shown below:
-
[Fact] public void configure_and_use_missing_instance() { var container = new Container(x => { x.For<Rule>().MissingNamedInstanceIs .ConstructedBy(context => new ColorRule(context.RequestedName)); }); container.GetInstance<Rule>("red") .ShouldBeOfType<ColorRule>().Color.ShouldBe("red"); container.GetInstance<Rule>("green") .ShouldBeOfType<ColorRule>().Color.ShouldBe("green"); container.GetInstance<Rule>("blue") .ShouldBeOfType<ColorRule>().Color.ShouldBe("blue"); }
+
[Fact] public void configure_and_use_missing_instance() { var container = new Container(x => { x.For<Rule>().MissingNamedInstanceIs .ConstructedBy(context => new ColorRule(context.RequestedName)); }); container.GetInstance<Rule>("red") .ShouldBeOfType<ColorRule>().Color.ShouldBe("red"); container.GetInstance<Rule>("green") .ShouldBeOfType<ColorRule>().Color.ShouldBe("green"); container.GetInstance<Rule>("blue") .ShouldBeOfType<ColorRule>().Color.ShouldBe("blue"); }

The missing named instance rules are evaluated last, meaning that the container will still resolve explicitly registered instances:
-
[Fact] public void does_not_override_explicit_registrations() { var container = new Container(x => { x.For<Rule>().Add(new ColorRule("DarkRed")).Named("red"); x.For<Rule>().MissingNamedInstanceIs .ConstructedBy(context => new ColorRule(context.RequestedName)); }); container.GetInstance<Rule>("red") .ShouldBeOfType<ColorRule>() .Color.ShouldBe("DarkRed"); }
+
[Fact] public void does_not_override_explicit_registrations() { var container = new Container(x => { x.For<Rule>().Add(new ColorRule("DarkRed")).Named("red"); x.For<Rule>().MissingNamedInstanceIs .ConstructedBy(context => new ColorRule(context.RequestedName)); }); container.GetInstance<Rule>("red") .ShouldBeOfType<ColorRule>() .Color.ShouldBe("DarkRed"); }

You also have the ability to explicitly supply an Instance to be evaluated in the missing named instance resolution:
-
[Fact] public void configure_and_use_missing_instance_by_generic_registration() { var instance = new LambdaInstance<ColorRule>(c => new ColorRule(c.RequestedName)); var container = new Container(x => { x.For(typeof(Rule)) .MissingNamedInstanceIs(instance); }); container.GetInstance<Rule>("red").ShouldBeOfType<ColorRule>().Color.ShouldBe("red"); container.GetInstance<Rule>("green").ShouldBeOfType<ColorRule>().Color.ShouldBe("green"); container.GetInstance<Rule>("blue").ShouldBeOfType<ColorRule>().Color.ShouldBe("blue"); }
+
[Fact] public void configure_and_use_missing_instance_by_generic_registration() { var instance = new LambdaInstance<ColorRule>(c => new ColorRule(c.RequestedName)); var container = new Container(x => { x.For(typeof(Rule)) .MissingNamedInstanceIs(instance); }); container.GetInstance<Rule>("red").ShouldBeOfType<ColorRule>().Color.ShouldBe("red"); container.GetInstance<Rule>("green").ShouldBeOfType<ColorRule>().Color.ShouldBe("green"); container.GetInstance<Rule>("blue").ShouldBeOfType<ColorRule>().Color.ShouldBe("blue"); }

Multi-Tenancy

To the best of my recollection, the feature described in this section was designed for a multi-tenancy situation where we needed to allow the business rules to vary by client, but most clients would still be using the default rules. In our implemenation, we would make a service location call to the container for the rules by the client id and use the object returned to calculate the business rules (it was an invoice processing service).

If our rules logic class structure looked like:
-
public interface Rule { } public class DefaultRule : Rule { } public class Client1Rule : Rule { } public class Client2Rule : Rule { }
+
public interface Rule { } public class DefaultRule : Rule { } public class Client1Rule : Rule { } public class Client2Rule : Rule { }

then we could allow client specific rules while still allowing the container to fall through to the default rules for clients that don't need customized rules:
-
[Fact] public void use_customer_overrides() { var container = new Container(_ => { _.For<Rule>().MissingNamedInstanceIs.Type<DefaultRule>(); _.For<Rule>().Add<Client1Rule>().Named("client1"); _.For<Rule>().Add<Client2Rule>().Named("client2"); }); // Client1 & Client2 have explicit registrations container.GetInstance<Rule>("client1").ShouldBeOfType<Client1Rule>(); container.GetInstance<Rule>("client2").ShouldBeOfType<Client2Rule>(); // Client3 has no explicit registration, so falls through to // DefaultRule container.GetInstance<Rule>("client3").ShouldBeOfType<DefaultRule>(); }
+
[Fact] public void use_customer_overrides() { var container = new Container(_ => { _.For<Rule>().MissingNamedInstanceIs.Type<DefaultRule>(); _.For<Rule>().Add<Client1Rule>().Named("client1"); _.For<Rule>().Add<Client2Rule>().Named("client2"); }); // Client1 & Client2 have explicit registrations container.GetInstance<Rule>("client1").ShouldBeOfType<Client1Rule>(); container.GetInstance<Rule>("client2").ShouldBeOfType<Client2Rule>(); // Client3 has no explicit registration, so falls through to // DefaultRule container.GetInstance<Rule>("client3").ShouldBeOfType<DefaultRule>(); }

In a more complex usage, maybe you need to pull client specific information from a database or configuration files to construct the rules object. The code below is a partial sample of how you might use the missing named instance feature to do data lookups inside of StructureMap:
-
public interface IClientRulesRepsitory { ClientRulesData Find(string clientName); } public class ClientRulesData { } public class DataUsingRule : Rule { private readonly ClientRulesData _data; public DataUsingRule(ClientRulesData data) { _data = data; } } [Fact] public void register_by_looking_up_data() { var container = new Container(_ => { _.For<Rule>().MissingNamedInstanceIs.ConstructedBy( "Building client rules by looking up client data", c => { var data = c.GetInstance<IClientRulesRepsitory>() .Find(c.RequestedName); return new DataUsingRule(data); }); }); }
+
public interface IClientRulesRepsitory { ClientRulesData Find(string clientName); } public class ClientRulesData { } public class DataUsingRule : Rule { private readonly ClientRulesData _data; public DataUsingRule(ClientRulesData data) { _data = data; } } [Fact] public void register_by_looking_up_data() { var container = new Container(_ => { _.For<Rule>().MissingNamedInstanceIs.ConstructedBy( "Building client rules by looking up client data", c => { var data = c.GetInstance<IClientRulesRepsitory>() .Find(c.RequestedName); return new DataUsingRule(data); }); }); }

diff --git a/the-container/index.html b/the-container/index.html old mode 100644 new mode 100755 index 2d3b6ad..55a2900 --- a/the-container/index.html +++ b/the-container/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Auto Wiring

Previous
Resolving Services

diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100644 new mode 100755 index f7120cd..0564318 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Working with the IContext at Build Time

Previous
Auto Wiring

@@ -92,10 +92,10 @@
Building Objects with Lambdas Lambda function that can be called to create an object at resolution time.

Using NHibernate's ISession as an example of an object that typically has to be built by using an ISessionFactory object:
-
public interface ISession { } public interface ISessionFactory { ISession Build(); }
+
public interface ISession { } public interface ISessionFactory { ISession Build(); }

If we want to allow StructureMap to control the ISession lifecycle and creation, we have to register a Lambda function as the means of creating ISession as shown in this example below:
-
public class SessionFactoryRegistry : Registry { // Let's not worry about how ISessionFactory is built // in this example public SessionFactoryRegistry(ISessionFactory factory) { For<ISessionFactory>().Use(factory); // Build ISession with a lambda: For<ISession>().Use("Build ISession from ISessionFactory", c => { // To resolve ISession, I first pull out // ISessionFactory from the IContext and use that // to build a new ISession. return c.GetInstance<ISessionFactory>().Build(); }); } }
+
public class SessionFactoryRegistry : Registry { // Let's not worry about how ISessionFactory is built // in this example public SessionFactoryRegistry(ISessionFactory factory) { For<ISessionFactory>().Use(factory); // Build ISession with a lambda: For<ISession>().Use("Build ISession from ISessionFactory", c => { // To resolve ISession, I first pull out // ISessionFactory from the IContext and use that // to build a new ISession. return c.GetInstance<ISessionFactory>().Build(); }); } }

Lambda registrations can be done with any of the following four signatures:

(Expression<Func<IContext, T>> builder) -- a simple, one line Lambda to build T using IContext
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html old mode 100644 new mode 100755 index 774f7cc..a6aa78b --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
StructureMap and IDisposable

Previous
Handling Missing Named Instances

@@ -101,21 +101,21 @@
Lazy Resolution Lazy<T>

Assuming that StructureMap either has an existing configuration for T or can derive a way to build T, you can just declare a dependency on Lazy<T> like this sample:
-
public class WidgetLazyUser { private readonly Lazy<IWidget> _widget; public WidgetLazyUser(Lazy<IWidget> widget) { _widget = widget; } public IWidget Widget { get { return _widget.Value; } } } [Fact] public void lazy_resolution_in_action() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); }); container.GetInstance<WidgetLazyUser>() .Widget.ShouldBeOfType<AWidget>(); }
+
public class WidgetLazyUser { private readonly Lazy<IWidget> _widget; public WidgetLazyUser(Lazy<IWidget> widget) { _widget = widget; } public IWidget Widget { get { return _widget.Value; } } } [Fact] public void lazy_resolution_in_action() { var container = new Container(_ => { _.For<IWidget>().Use<AWidget>(); }); container.GetInstance<WidgetLazyUser>() .Widget.ShouldBeOfType<AWidget>(); }

Func<T>

Likewise, you can also declare a dependency on Func<T> with very similar mechanics:
-
[Fact] public void build_a_func_that_returns_a_singleton() { var container = new Container(x => { x.ForSingletonOf<IWidget>().Use<ColorWidget>().Ctor<string>("color").Is("green"); }); var func = container.GetInstance<Func<IWidget>>(); var w1 = func(); var w2 = func(); var w3 = func(); w1.ShouldBeOfType<ColorWidget>().Color.ShouldBe("green"); w1.ShouldBeTheSameAs(w2); w1.ShouldBeTheSameAs(w3); w2.ShouldBeTheSameAs(w3); }
+
[Fact] public void build_a_func_that_returns_a_singleton() { var container = new Container(x => { x.ForSingletonOf<IWidget>().Use<ColorWidget>().Ctor<string>("color").Is("green"); }); var func = container.GetInstance<Func<IWidget>>(); var w1 = func(); var w2 = func(); var w3 = func(); w1.ShouldBeOfType<ColorWidget>().Color.ShouldBe("green"); w1.ShouldBeTheSameAs(w2); w1.ShouldBeTheSameAs(w3); w2.ShouldBeTheSameAs(w3); }

This functionality predates the introduction of the Lazy type to .Net

Func<string, T>

Finally, you can also declare a dependency on Func<string, T> that will allow you to lazily resolve a dependency of T by name:
-
[Fact] public void build_a_func_by_string() { var container = new Container(x => { x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("green").Named("green"); x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("blue").Named("blue"); x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("red").Named("red"); }); var func = container.GetInstance<Func<string, IWidget>>(); func("green").ShouldBeOfType<ColorWidget>().Color.ShouldBe("green"); }
+
[Fact] public void build_a_func_by_string() { var container = new Container(x => { x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("green").Named("green"); x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("blue").Named("blue"); x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("red").Named("red"); }); var func = container.GetInstance<Func<string, IWidget>>(); func("green").ShouldBeOfType<ColorWidget>().Color.ShouldBe("green"); }

Bi-relational Dependency Workaround

StructureMap does not directly support bi-directional dependency relationships -- but will happily tell you in an exception when you accidentally manage to create one without cratering your AppDomain with a StackOverflowException.

Either Func<T> or Lazy<T> can be used as a workaround for purposeful bi-directional dependencies between types. The following is an example of using this strategy:
-
[Singleton] public class Thing1 { private readonly Lazy<Thing2> _thing2; public Thing1(Lazy<Thing2> thing2) { _thing2 = thing2; } public Thing2 Thing2 { get { return _thing2.Value; } } } [Singleton] public class Thing2 { public Thing1 Thing1 { get; set; } public Thing2(Thing1 thing1) { Thing1 = thing1; } } [Fact] public void use_lazy_as_workaround_for_bi_directional_dependency() { var container = new Container(); var thing1 = container.GetInstance<Thing1>(); var thing2 = container.GetInstance<Thing2>(); thing1.Thing2.ShouldBeSameAs(thing2); thing2.Thing1.ShouldBeSameAs(thing1); }
+
[Singleton] public class Thing1 { private readonly Lazy<Thing2> _thing2; public Thing1(Lazy<Thing2> thing2) { _thing2 = thing2; } public Thing2 Thing2 { get { return _thing2.Value; } } } [Singleton] public class Thing2 { public Thing1 Thing1 { get; set; } public Thing2(Thing1 thing1) { Thing1 = thing1; } } [Fact] public void use_lazy_as_workaround_for_bi_directional_dependency() { var container = new Container(); var thing1 = container.GetInstance<Thing1>(); var thing2 = container.GetInstance<Thing2>(); thing1.Thing2.ShouldBeSameAs(thing2); thing2.Thing1.ShouldBeSameAs(thing1); }

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html old mode 100644 new mode 100755 index 53b70e9..3d8e5c5 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Working with Enumerable Types

Previous
Profiles and Child Containers

@@ -113,7 +113,7 @@
Who uses it?
MassTransit, and NServiceBus.

Creation

Creating a nested container is as simple as calling the IContainer.GetNestedContainer() method as shown below:
-
public interface IWorker { void DoWork(); } public class Worker : IWorker, IDisposable { public void DoWork() { // do stuff! } public void Dispose() { // clean up } } [Fact] public void creating_a_nested_container() { // From an IContainer object var container = new Container(_ => { _.For<IWorker>().Use<Worker>(); }); using (var nested = container.GetNestedContainer()) { // This object is disposed when the nested container // is disposed var worker = nested.GetInstance<IWorker>(); worker.DoWork(); } }
+
public interface IWorker { void DoWork(); } public class Worker : IWorker, IDisposable { public void DoWork() { // do stuff! } public void Dispose() { // clean up } } [Fact] public void creating_a_nested_container() { // From an IContainer object var container = new Container(_ => { _.For<IWorker>().Use<Worker>(); }); using (var nested = container.GetNestedContainer()) { // This object is disposed when the nested container // is disposed var worker = nested.GetInstance<IWorker>(); worker.DoWork(); } }

Lifecycle Rules

While StructureMap supports several object instance lifecycles out of the box, in idiomatic usage of StructureMap the only common lifecyles are:

@@ -121,9 +121,9 @@
Lifecycle Rules

Singleton - One instance is constructed and used over the entire Container lifetime

In the context of a Nested Container however, the Transient scoping now applies to the Nested Container itself:
-
[Fact] public void nested_container_behavior_of_transients() { // "Transient" is the default lifecycle // in StructureMap var container = new Container(_ => { _.For<IColor>().Use<Green>(); }); // In a normal Container, a "transient" lifecycle // Instance will be built up once in every request // to the Container container.GetInstance<IColor>() .ShouldNotBeTheSameAs(container.GetInstance<IColor>()); // From a nested container, the "transient" lifecycle // is tracked to the nested container using (var nested = container.GetNestedContainer()) { nested.GetInstance<IColor>() .ShouldBeTheSameAs(nested.GetInstance<IColor>()); // One more time nested.GetInstance<IColor>() .ShouldBeTheSameAs(nested.GetInstance<IColor>()); } }
+
[Fact] public void nested_container_behavior_of_transients() { // "Transient" is the default lifecycle // in StructureMap var container = new Container(_ => { _.For<IColor>().Use<Green>(); }); // In a normal Container, a "transient" lifecycle // Instance will be built up once in every request // to the Container container.GetInstance<IColor>() .ShouldNotBeTheSameAs(container.GetInstance<IColor>()); // From a nested container, the "transient" lifecycle // is tracked to the nested container using (var nested = container.GetNestedContainer()) { nested.GetInstance<IColor>() .ShouldBeTheSameAs(nested.GetInstance<IColor>()); // One more time nested.GetInstance<IColor>() .ShouldBeTheSameAs(nested.GetInstance<IColor>()); } }

Instances scoped to anything but Transient or AlwaysUnique are resolved as normal, but through the parent container:
-
[Fact] public void nested_container_usage_of_singletons() { var container = new Container(_ => { _.ForSingletonOf<IColorCache>().Use<ColorCache>(); }); var singleton = container.GetInstance<IColorCache>(); // SingletonThing's are resolved from the parent container using (var nested = container.GetNestedContainer()) { nested.GetInstance<IColorCache>() .ShouldBeTheSameAs(singleton); } }
+
[Fact] public void nested_container_usage_of_singletons() { var container = new Container(_ => { _.ForSingletonOf<IColorCache>().Use<ColorCache>(); }); var singleton = container.GetInstance<IColorCache>(); // SingletonThing's are resolved from the parent container using (var nested = container.GetNestedContainer()) { nested.GetInstance<IColorCache>() .ShouldBeTheSameAs(singleton); } }

See Object Lifecycles for more information on supported object lifecycles.

Overriding Services from the Parent

A nested container is a new Container object that still retains access to the parent container that created it so that it can @@ -133,7 +133,7 @@
Overriding Services from the Parent
The FubuMVC web framework uses a nested container per HTTP request. During an HTTP request, FubuMVC injects services for the current HTTP request and response to a nested container before creating the actual services that will handle the request. The FubuMVC mechanics are conceptually similar to this code sample:
-
[Fact] public void overriding_services_in_a_nested_container() { var container = new Container(_ => { _.For<IHttpRequest>().Use<StandInHttpRequest>(); _.For<IHttpResponse>().Use<StandInHttpResponse>(); }); var request = new HttpRequest(); var response = new HttpResponse(); using (var nested = container.GetNestedContainer()) { // Override the HTTP request and response for this // nested container nested.Configure(_ => { _.For<IHttpRequest>().Use(request); _.For<IHttpResponse>().Use(response); }); var handler = nested.GetInstance<HttpRequestHandler>(); handler.Request.ShouldBeTheSameAs(request); handler.Response.ShouldBeTheSameAs(response); } // Outside the nested container, we still have the original // registrations container.GetInstance<IHttpRequest>() .ShouldBeOfType<StandInHttpRequest>(); container.GetInstance<IHttpResponse>() .ShouldBeOfType<StandInHttpResponse>(); }
+
[Fact] public void overriding_services_in_a_nested_container() { var container = new Container(_ => { _.For<IHttpRequest>().Use<StandInHttpRequest>(); _.For<IHttpResponse>().Use<StandInHttpResponse>(); }); var request = new HttpRequest(); var response = new HttpResponse(); using (var nested = container.GetNestedContainer()) { // Override the HTTP request and response for this // nested container nested.Configure(_ => { _.For<IHttpRequest>().Use(request); _.For<IHttpResponse>().Use(response); }); var handler = nested.GetInstance<HttpRequestHandler>(); handler.Request.ShouldBeTheSameAs(request); handler.Response.ShouldBeTheSameAs(response); } // Outside the nested container, we still have the original // registrations container.GetInstance<IHttpRequest>() .ShouldBeOfType<StandInHttpRequest>(); container.GetInstance<IHttpResponse>() .ShouldBeOfType<StandInHttpResponse>(); }

The StructureMap team strongly cautions against altering the configuration of the main application container, but overriding services in a nested container is useful (but please upgrade to at least version 3.1.2) and should not incur any problems with locking across threads.

When handling requests for new services, a nested container first checks its own configuration if it has its own explicit registration for the request. If the nested container does have an explicit registration, it uses that registration. Otherwise, a nested container will attempt to build an object using the registered configuration of its parent container.
@@ -143,21 +143,21 @@
Overriding Services from the Parent
Lazy Resolution

Nested container object lifecycles equally apply to objects resolved lazily with either Lazy<T>, Func<T>, or Func<string, T> as shown below:
-
public class Foo { } public class FooHolder { public IContainer Container { get; set; } public Func<Foo> Func { get; set; } public Lazy<Foo> Lazy { get; set; } public FooHolder(IContainer container, Func<Foo> func, Lazy<Foo> lazy) { Container = container; Func = func; Lazy = lazy; } } [Fact] public void service_location_and_container_resolution_inside_nested_containers() { var container = new Container(); using (var nested = container.GetNestedContainer()) { var holder = nested.GetInstance<FooHolder>(); // The injected IContainer is the nested container holder.Container.ShouldBeTheSameAs(nested); // Func<T> and Lazy<T> values will be built by // the nested container w/ the nested container // scoping var nestedFoo = nested.GetInstance<Foo>(); holder.Func().ShouldBeTheSameAs(nestedFoo); holder.Lazy.Value.ShouldBeTheSameAs(nestedFoo); } }
+
public class Foo { } public class FooHolder { public IContainer Container { get; set; } public Func<Foo> Func { get; set; } public Lazy<Foo> Lazy { get; set; } public FooHolder(IContainer container, Func<Foo> func, Lazy<Foo> lazy) { Container = container; Func = func; Lazy = lazy; } } [Fact] public void service_location_and_container_resolution_inside_nested_containers() { var container = new Container(); using (var nested = container.GetNestedContainer()) { var holder = nested.GetInstance<FooHolder>(); // The injected IContainer is the nested container holder.Container.ShouldBeTheSameAs(nested); // Func<T> and Lazy<T> values will be built by // the nested container w/ the nested container // scoping var nestedFoo = nested.GetInstance<Foo>(); holder.Func().ShouldBeTheSameAs(nestedFoo); holder.Lazy.Value.ShouldBeTheSameAs(nestedFoo); } }

Do note that the IContainer object injected above was the nested container that created the FooHandler object. If you do want to use service location within an object, just take in IContainer as a constructor dependency and you will always get the correctly scoped IContainer.

Profiles

You can created nested containers from profile containers as shown in the sample below:
-
[Fact] public void nested_container_from_profile_container() { var container = new Container(x => { x.For<IColor>().Use<Red>(); x.Profile("Blue", _ => _.For<IColor>().Use<Blue>()); x.Profile("Green", _ => _.For<IColor>().Use<Green>()); }); using (var nested = container.GetProfile("Blue").GetNestedContainer()) { nested.GetInstance<IColor>().ShouldBeOfType<Blue>(); } using (var nested = container.GetNestedContainer("Green")) { nested.GetInstance<IColor>().ShouldBeOfType<Green>(); } }
+
[Fact] public void nested_container_from_profile_container() { var container = new Container(x => { x.For<IColor>().Use<Red>(); x.Profile("Blue", _ => _.For<IColor>().Use<Blue>()); x.Profile("Green", _ => _.For<IColor>().Use<Green>()); }); using (var nested = container.GetProfile("Blue").GetNestedContainer()) { nested.GetInstance<IColor>().ShouldBeOfType<Blue>(); } using (var nested = container.GetNestedContainer("Green")) { nested.GetInstance<IColor>().ShouldBeOfType<Green>(); } }

See Profiles and Child Containers for more information about using profiles.

Disposing Services

As stated above, disposing a nested container will also dispose all objects created with the default Transient lifecycle by the nested container that implement the IDisposable interface. That behavior is demonstrated below:
-
[Fact] public void nested_container_disposal() { var container = new Container(_ => { // A SingletonThing scoped service _.ForSingletonOf<IColorCache>().Use<ColorCache>(); // A transient scoped service _.For<IColor>().Use<Green>(); // An AlwaysUnique scoped service _.For<Purple>().AlwaysUnique(); }); ColorCache singleton = null; Green nestedGreen = null; Blue nestedBlue = null; Purple nestedPurple = null; using (var nested = container.GetNestedContainer()) { // SingletonThing's are really built by the parent singleton = nested.GetInstance<IColorCache>() .ShouldBeOfType<ColorCache>(); nestedGreen = nested.GetInstance<IColor>() .ShouldBeOfType<Green>(); nestedBlue = nested.GetInstance<Blue>(); nestedPurple = nested.GetInstance<Purple>(); } // Transients created by the Nested Container // are disposed nestedGreen.WasDisposed.ShouldBeTrue(); nestedBlue.WasDisposed.ShouldBeTrue(); // Unique's created by the Nested Container // are disposed nestedPurple.WasDisposed.ShouldBeTrue(); // NOT disposed because it's owned by // the parent container singleton.WasDisposed.ShouldBeFalse(); }
+
[Fact] public void nested_container_disposal() { var container = new Container(_ => { // A SingletonThing scoped service _.ForSingletonOf<IColorCache>().Use<ColorCache>(); // A transient scoped service _.For<IColor>().Use<Green>(); // An AlwaysUnique scoped service _.For<Purple>().AlwaysUnique(); }); ColorCache singleton = null; Green nestedGreen = null; Blue nestedBlue = null; Purple nestedPurple = null; using (var nested = container.GetNestedContainer()) { // SingletonThing's are really built by the parent singleton = nested.GetInstance<IColorCache>() .ShouldBeOfType<ColorCache>(); nestedGreen = nested.GetInstance<IColor>() .ShouldBeOfType<Green>(); nestedBlue = nested.GetInstance<Blue>(); nestedPurple = nested.GetInstance<Purple>(); } // Transients created by the Nested Container // are disposed nestedGreen.WasDisposed.ShouldBeTrue(); nestedBlue.WasDisposed.ShouldBeTrue(); // Unique's created by the Nested Container // are disposed nestedPurple.WasDisposed.ShouldBeTrue(); // NOT disposed because it's owned by // the parent container singleton.WasDisposed.ShouldBeFalse(); }

For the sake of clarity, the classes used in the sample above are:
-
public interface IColor { } public class Red : IColor { } public class Purple : Blue { } public class Blue : IColor, IDisposable { public bool WasDisposed; public void Dispose() { WasDisposed = true; } } public class Green : IColor, IDisposable { public bool WasDisposed; public void Dispose() { WasDisposed = true; } } public interface IColorCache { } public class ColorCache : IColorCache, IDisposable { public bool WasDisposed; public void Dispose() { WasDisposed = true; } }
+
public interface IColor { } public class Red : IColor { } public class Purple : Blue { } public class Blue : IColor, IDisposable { public bool WasDisposed; public void Dispose() { WasDisposed = true; } } public class Green : IColor, IDisposable { public bool WasDisposed; public void Dispose() { WasDisposed = true; } } public interface IColorCache { } public class ColorCache : IColorCache, IDisposable { public bool WasDisposed; public void Dispose() { WasDisposed = true; } }

diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100644 new mode 100755 index 41470f2..5ab13b3 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Object Lifecycles

Previous
StructureMap and IDisposable

@@ -94,7 +94,7 @@
Working with Primitive Types inline dependencies.

To make this concrete, if you ask StructureMap to build a concrete type that has dependencies on simple types without like this example, StructureMap will throw an exception telling you that it cannot build the instance:
-
public class GuyWithNoDefaultName { // StructureMap will not use any kind of auto-wiring // on name public GuyWithNoDefaultName(string name) { } } [Fact] public void cannot_build_simple_arguments() { var container = new Container(); Exception<StructureMapBuildPlanException>.ShouldBeThrownBy(() => { container.GetInstance<GuyWithNoDefaultName>(); }); }
+
public class GuyWithNoDefaultName { // StructureMap will not use any kind of auto-wiring // on name public GuyWithNoDefaultName(string name) { } } [Fact] public void cannot_build_simple_arguments() { var container = new Container(); Exception<StructureMapBuildPlanException>.ShouldBeThrownBy(() => { container.GetInstance<GuyWithNoDefaultName>(); }); }

Part of the exception message thrown in the unit test shown above is the erroneous build plan showing you that the name parameter has to be defined:

@@ -103,14 +103,14 @@
Working with Primitive Types [Fact] public void can_build_with_explicit_argument() { var container = new Container(_ => { _.ForConcreteType<GuyWithNoDefaultName>() .Configure.Ctor<string>("name").Is("Steve Winwood"); }); container.GetInstance<GuyWithNoDefaultName>() .ShouldNotBeNull(); }
+
[Fact] public void can_build_with_explicit_argument() { var container = new Container(_ => { _.ForConcreteType<GuyWithNoDefaultName>() .Configure.Ctor<string>("name").Is("Steve Winwood"); }); container.GetInstance<GuyWithNoDefaultName>() .ShouldNotBeNull(); }

See Construction Policies for an example of using a constructor policy to set a dependency on a "connectionString" argument in a conventional way.

Default Values

As a new feature in the 4.0 release, StructureMap can finally take advantage of default parameter arguments to derive the values for a primitive argument (or setter value) while still allowing you to explicitly define that parameter or setter value:
-
// I was listening to Jim Croce's "I've got a Name" song // when I wrote this feature;) public class GuyWithName { public GuyWithName(string name = "Jim Croce") { Name = name; } public string Name { get; set; } } [Fact] public void uses_the_default_value_if_one_exists() { var container = new Container(); // Should happily build with the default // value of 'name' container.GetInstance<GuyWithName>() .Name.ShouldBe("Jim Croce"); } [Fact] public void uses_the_default_value_if_one_exists_2() { var container = new Container(_ => { _.ForConcreteType<GuyWithName>(); }); // Should happily build with the default // value of 'name' container.GetInstance<GuyWithName>() .Name.ShouldBe("Jim Croce"); } [Fact] public void use_explicit_dependency_if_one_exists() { var container = new Container(_ => { _.ForConcreteType<GuyWithName>() .Configure.Ctor<string>("name").Is("Eric Clapton"); }); container.GetInstance<GuyWithName>() .Name.ShouldBe("Eric Clapton"); }
+
// I was listening to Jim Croce's "I've got a Name" song // when I wrote this feature;) public class GuyWithName { public GuyWithName(string name = "Jim Croce") { Name = name; } public string Name { get; set; } } [Fact] public void uses_the_default_value_if_one_exists() { var container = new Container(); // Should happily build with the default // value of 'name' container.GetInstance<GuyWithName>() .Name.ShouldBe("Jim Croce"); } [Fact] public void uses_the_default_value_if_one_exists_2() { var container = new Container(_ => { _.ForConcreteType<GuyWithName>(); }); // Should happily build with the default // value of 'name' container.GetInstance<GuyWithName>() .Name.ShouldBe("Jim Croce"); } [Fact] public void use_explicit_dependency_if_one_exists() { var container = new Container(_ => { _.ForConcreteType<GuyWithName>() .Configure.Ctor<string>("name").Is("Eric Clapton"); }); container.GetInstance<GuyWithName>() .Name.ShouldBe("Eric Clapton"); }

diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html old mode 100644 new mode 100755 index 5a40d5e..8f46e9e --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Nested Containers (Per Request/Transaction)

Previous
Registering a Single Instance Against Multiple PluginTypes

@@ -96,7 +96,7 @@
Profiles and Child Containers Child Containers

The easiest way to explain a child container is to just show it in action:
-
[Fact] public void show_a_child_container_in_action() { var parent = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.For<IService>().Use<AService>(); }); // Create a child container and override the // IService registration var child = parent.CreateChildContainer(); child.Configure(_ => { _.For<IService>().Use<ChildSpecialService>(); }); // The child container has a specific registration // for IService, so use that one child.GetInstance<IService>() .ShouldBeOfType<ChildSpecialService>(); // The child container does not have any // override of IWidget, so it uses its parent's // configuration to resolve IWidget child.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); }
+
[Fact] public void show_a_child_container_in_action() { var parent = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.For<IService>().Use<AService>(); }); // Create a child container and override the // IService registration var child = parent.CreateChildContainer(); child.Configure(_ => { _.For<IService>().Use<ChildSpecialService>(); }); // The child container has a specific registration // for IService, so use that one child.GetInstance<IService>() .ShouldBeOfType<ChildSpecialService>(); // The child container does not have any // override of IWidget, so it uses its parent's // configuration to resolve IWidget child.GetInstance<IWidget>() .ShouldBeOfType<AWidget>(); }

Child Containers are a mechanism to make a completely new Container that can override some of the parent Container's registrations but still fall back to the parent Container to fulfill any request that is not explicitly configured to the child container. The behavior of a child container in how it resolves services and allows you to override the parent container is very similar to a nested container, but the crucial difference is in how the two concepts handle lifecycles and calling IDisposable.Dispose().
@@ -113,14 +113,14 @@
Profiles
a way to vary StructureMap registrations by development environment as the code moved from running locally on a developer's box to testing servers to production. While that usage is still valid, it is probably more common to use profiles to define overrides for how StructureMap should resolve services in different modes of the application (connected vs offline) or different types of system users.
-
[Fact] public void Add_default_instance_with_concrete_type() { IContainer container = new Container(registry => { registry.Profile("something", p => { p.For<IWidget>().Use<AWidget>(); p.For<Rule>().Use<DefaultRule>(); }); }); var profile = container.GetProfile("something"); profile.GetInstance<IWidget>().ShouldBeOfType<AWidget>(); profile.GetInstance<Rule>().ShouldBeOfType<DefaultRule>(); }
+
[Fact] public void Add_default_instance_with_concrete_type() { IContainer container = new Container(registry => { registry.Profile("something", p => { p.For<IWidget>().Use<AWidget>(); p.For<Rule>().Use<DefaultRule>(); }); }); var profile = container.GetProfile("something"); profile.GetInstance<IWidget>().ShouldBeOfType<AWidget>(); profile.GetInstance<Rule>().ShouldBeOfType<DefaultRule>(); }

Child Containers and Singletons

If you register a new Instance directly to a child container, that registration is really scoped as a singleton within the usage of that particular child container:
-
[Fact] public void singletons_to_child_container_are_isolated() { var parentContainer = new Container(_ => { _.For<IDependency>().Use<Dependency>(); }); var child1 = parentContainer.CreateChildContainer(); child1.Configure(x => { x.ForSingletonOf<IRoot>().Use<Root>(); }); var child2 = parentContainer.CreateChildContainer(); child2.Configure(x => { x.ForSingletonOf<IRoot>().Use<Root>(); }); // IRoot is a "singleton" within child1 usage child1.GetInstance<IRoot>().ShouldBeSameAs(child1.GetInstance<IRoot>()); // IRoot is a "singleton" within child2 usage child2.GetInstance<IRoot>().ShouldBeSameAs(child2.GetInstance<IRoot>()); // but, child1 and child2 both have a different IRoot child1.GetInstance<IRoot>() .ShouldNotBeTheSameAs(child2.GetInstance<IRoot>()); }
+
[Fact] public void singletons_to_child_container_are_isolated() { var parentContainer = new Container(_ => { _.For<IDependency>().Use<Dependency>(); }); var child1 = parentContainer.CreateChildContainer(); child1.Configure(x => { x.ForSingletonOf<IRoot>().Use<Root>(); }); var child2 = parentContainer.CreateChildContainer(); child2.Configure(x => { x.ForSingletonOf<IRoot>().Use<Root>(); }); // IRoot is a "singleton" within child1 usage child1.GetInstance<IRoot>().ShouldBeSameAs(child1.GetInstance<IRoot>()); // IRoot is a "singleton" within child2 usage child2.GetInstance<IRoot>().ShouldBeSameAs(child2.GetInstance<IRoot>()); // but, child1 and child2 both have a different IRoot child1.GetInstance<IRoot>() .ShouldNotBeTheSameAs(child2.GetInstance<IRoot>()); }

Creating a Nested Container from a Child Container

It is perfectly valid to create a nested container from a child container for short-lived requests or transactions:
-
[Fact] public void nested_container_from_child() { var parent = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.For<IService>().Use<AService>(); }); // Create a child container and override the // IService registration var child = parent.CreateChildContainer(); child.Configure(_ => { _.For<IService>().Use<ChildSpecialService>(); }); using (var nested = child.GetNestedContainer()) { nested.GetInstance<IService>() .ShouldBeOfType<ChildSpecialService>(); } }
+
[Fact] public void nested_container_from_child() { var parent = new Container(_ => { _.For<IWidget>().Use<AWidget>(); _.For<IService>().Use<AService>(); }); // Create a child container and override the // IService registration var child = parent.CreateChildContainer(); child.Configure(_ => { _.For<IService>().Use<ChildSpecialService>(); }); using (var nested = child.GetNestedContainer()) { nested.GetInstance<IService>() .ShouldBeOfType<ChildSpecialService>(); } }

Example: Child Containers in Automated Testing

My shop has been somewhat successful in writing automated integration tests in a whitebox testing style where we happily "swap out" a handful of external services with a stubbed service that we can happily control @@ -132,7 +132,7 @@
Example: Child Containers we've introduced the idea of using a clean child container per integration test so that the test harness tools can happily swap in stubs without impacting other tests in the test suite.

In action, that usage looks something like this:
-
public class TheRealService : IService { } public class StubbedService : IService { } [Fact] public void in_testing() { var container = new Container(_ => { _.For<IService>().Use<TheRealService>(); }); // Create a new child container for only this test var testContainer = container.CreateChildContainer(); // Override a service with a stub that's easier to control var stub = new StubbedService(); testContainer.Inject<IService>(stub); // Now, continue with the test resolving application // services through the new child container.... }
+
public class TheRealService : IService { } public class StubbedService : IService { } [Fact] public void in_testing() { var container = new Container(_ => { _.For<IService>().Use<TheRealService>(); }); // Create a new child container for only this test var testContainer = container.CreateChildContainer(); // Override a service with a stub that's easier to control var stub = new StubbedService(); testContainer.Inject<IService>(stub); // Now, continue with the test resolving application // services through the new child container.... }

diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html old mode 100644 new mode 100755 index a996a1f..8231626 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Handling Missing Named Instances

Previous
Nested Containers (Per Request/Transaction)

@@ -105,15 +105,15 @@
Working with Enumerable Types
Here's an acceptance test from the StructureMap codebase that demonstrates this:
-
[Fact] public void collection_types_are_all_possible_by_default() { // NOTE that we do NOT make any explicit registration of // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[] var container = new Container(_ => { _.For<IWidget>().Add<AWidget>(); _.For<IWidget>().Add<BWidget>(); _.For<IWidget>().Add<CWidget>(); }); // IList<T> container.GetInstance<IList<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // ICollection<T> container.GetInstance<ICollection<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // Array of T container.GetInstance<IWidget[]>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); }
+
[Fact] public void collection_types_are_all_possible_by_default() { // NOTE that we do NOT make any explicit registration of // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[] var container = new Container(_ => { _.For<IWidget>().Add<AWidget>(); _.For<IWidget>().Add<BWidget>(); _.For<IWidget>().Add<CWidget>(); }); // IList<T> container.GetInstance<IList<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // ICollection<T> container.GetInstance<ICollection<IWidget>>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); // Array of T container.GetInstance<IWidget[]>() .Select(x => x.GetType()) .ShouldHaveTheSameElementsAs(typeof(AWidget), typeof(BWidget), typeof(CWidget)); }

And another showing how you can override this behavior with explicit configuration:
-
[Fact] public void override_enumeration_behavior() { var container = new Container(_ => { _.For<IWidget>().Add<AWidget>(); _.For<IWidget>().Add<BWidget>(); _.For<IWidget>().Add<CWidget>(); // Explicit registration should have precedence over the default // behavior _.For<IWidget[]>().Use(new IWidget[] { new DefaultWidget() }); }); container.GetInstance<IWidget[]>() .Single().ShouldBeOfType<DefaultWidget>(); }
+
[Fact] public void override_enumeration_behavior() { var container = new Container(_ => { _.For<IWidget>().Add<AWidget>(); _.For<IWidget>().Add<BWidget>(); _.For<IWidget>().Add<CWidget>(); // Explicit registration should have precedence over the default // behavior _.For<IWidget[]>().Use(new IWidget[] { new DefaultWidget() }); }); container.GetInstance<IWidget[]>() .Single().ShouldBeOfType<DefaultWidget>(); }

Sample Usage: Validation Rules

One of the ways that I have used the built in IEnumerable handling is for extensible validation rules. Say that we are building a system to process IWidget objects. As part of processing a widget, we first need to validate that widget with a series of rules that we might model with the IWidgetValidator interface shown below and used within the main WidgetProcessor class:
-
public interface IWidgetValidator { IEnumerable<string> Validate(IWidget widget); } public class WidgetProcessor { private readonly IEnumerable<IWidgetValidator> _validators; public WidgetProcessor(IEnumerable<IWidgetValidator> validators) { _validators = validators; } public void Process(IWidget widget) { var validationMessages = _validators.SelectMany(x => x.Validate(widget)) .ToArray(); if (validationMessages.Any()) { // don't process the widget } } }
+
public interface IWidgetValidator { IEnumerable<string> Validate(IWidget widget); } public class WidgetProcessor { private readonly IEnumerable<IWidgetValidator> _validators; public WidgetProcessor(IEnumerable<IWidgetValidator> validators) { _validators = validators; } public void Process(IWidget widget) { var validationMessages = _validators.SelectMany(x => x.Validate(widget)) .ToArray(); if (validationMessages.Any()) { // don't process the widget } } }

We could simply configure all of the IWidgetValidator rules in one place with an explicit registration of IEnumerable<IWidgetValidator>, but what if we need to have an extensibility to add more validation rules later? What if we want to add these additional rules in addon packages? Or we just don't want to continuously break into the centralized Registry class every single time we add a new validation rule?
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html old mode 100644 new mode 100755 index 4484658..ea46e0a --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -31,7 +31,7 @@

- StructureMap 4.5.3 + StructureMap 4.6.0

@@ -74,7 +74,7 @@

-
+

Next
Registering a Single Instance Against Multiple PluginTypes

Previous
Building Objects with Lambdas

@@ -104,18 +104,18 @@
Working with the IContext at Build Time /// <summary> /// Access to the state and type resolution of the current "build session" /// during a request to a StructureMap container /// </summary> public interface IContext { /// <summary> /// The requested instance name of the object graph /// </summary> string RequestedName { get; } /// <summary> /// The "BuildUp" method takes in an already constructed object /// and uses Setter Injection to push in configured dependencies /// of that object /// </summary> /// <param name="target"></param> void BuildUp(object target); /// <summary> /// Get the object of type T that is valid for this build session. /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T GetInstance<T>(); /// <summary> /// Get the object of type T that is valid for this build session by name. /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T GetInstance<T>(string name); /// <summary> /// Get a service from the current build session by type /// </summary> /// <param name="pluginType"></param> /// <returns></returns> object GetInstance(Type pluginType); /// <summary> /// Creates or finds the named instance of the pluginType /// </summary> /// <param name="pluginType"></param> /// <param name="instanceKey"></param> /// <returns></returns> object GetInstance(Type pluginType, string instanceKey); /// <summary> /// Same as GetInstance, but can gracefully return null if /// the Type does not already exist /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T TryGetInstance<T>() where T : class; /// <summary> /// Same as GetInstance(name), but can gracefully return null if /// the Type and name does not already exist /// </summary> /// <typeparam name="T"></typeparam> /// <param name="name"></param> /// <returns></returns> T TryGetInstance<T>(string name) where T : class; /// <summary> /// Creates or finds the default instance of the pluginType. Returns null if the pluginType is not known to the container. /// </summary> /// <param name="pluginType"></param> /// <returns></returns> object TryGetInstance(Type pluginType); /// <summary> /// Creates or finds the named instance of the pluginType. Returns null if the named instance is not known to the container. /// </summary> /// <param name="pluginType"></param> /// <param name="instanceKey"></param> /// <returns></returns> object TryGetInstance(Type pluginType, string instanceKey); /// <summary> /// Gets all objects in the current object graph that can be cast /// to T that have already been created /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> IEnumerable<T> All<T>() where T : class; /// <summary> /// Creates/Resolves every configured instance of PlutinType T /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> IEnumerable<T> GetAllInstances<T>(); /// <summary> /// Creates or resolves all registered instances of the pluginType /// </summary> /// <param name="pluginType"></param> /// <returns></returns> IEnumerable<object> GetAllInstances(Type pluginType); /// <summary> /// The type of the parent object. Useful for constructing /// contextual logging dependencies /// </summary> Type ParentType { get; } /// <summary> /// The type of the requested object at the very top of the /// object graph /// </summary> Type RootType { get; } }
+
/// <summary> /// Access to the state and type resolution of the current "build session" /// during a request to a StructureMap container /// </summary> public interface IContext { /// <summary> /// The requested instance name of the object graph /// </summary> string RequestedName { get; } /// <summary> /// The "BuildUp" method takes in an already constructed object /// and uses Setter Injection to push in configured dependencies /// of that object /// </summary> /// <param name="target"></param> void BuildUp(object target); /// <summary> /// Get the object of type T that is valid for this build session. /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T GetInstance<T>(); /// <summary> /// Get the object of type T that is valid for this build session by name. /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T GetInstance<T>(string name); /// <summary> /// Get a service from the current build session by type /// </summary> /// <param name="pluginType"></param> /// <returns></returns> object GetInstance(Type pluginType); /// <summary> /// Creates or finds the named instance of the pluginType /// </summary> /// <param name="pluginType"></param> /// <param name="instanceKey"></param> /// <returns></returns> object GetInstance(Type pluginType, string instanceKey); /// <summary> /// Same as GetInstance, but can gracefully return null if /// the Type does not already exist /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T TryGetInstance<T>() where T : class; /// <summary> /// Same as GetInstance(name), but can gracefully return null if /// the Type and name does not already exist /// </summary> /// <typeparam name="T"></typeparam> /// <param name="name"></param> /// <returns></returns> T TryGetInstance<T>(string name) where T : class; /// <summary> /// Creates or finds the default instance of the pluginType. Returns null if the pluginType is not known to the container. /// </summary> /// <param name="pluginType"></param> /// <returns></returns> object TryGetInstance(Type pluginType); /// <summary> /// Creates or finds the named instance of the pluginType. Returns null if the named instance is not known to the container. /// </summary> /// <param name="pluginType"></param> /// <param name="instanceKey"></param> /// <returns></returns> object TryGetInstance(Type pluginType, string instanceKey); /// <summary> /// Gets all objects in the current object graph that can be cast /// to T that have already been created /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> IEnumerable<T> All<T>() where T : class; /// <summary> /// Creates/Resolves every configured instance of PlutinType T /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> IEnumerable<T> GetAllInstances<T>(); /// <summary> /// Creates or resolves all registered instances of the pluginType /// </summary> /// <param name="pluginType"></param> /// <returns></returns> IEnumerable<object> GetAllInstances(Type pluginType); /// <summary> /// The type of the parent object. Useful for constructing /// contextual logging dependencies /// </summary> Type ParentType { get; } /// <summary> /// The type of the requested object at the very top of the /// object graph /// </summary> Type RootType { get; } }

Example 1: Contextual Logging

All of the sample code in this example is in Github.

One of the canonical examples of using IContext is the integration of logging frameworks like NLog or Log4net that allow you to create logging policies by concrete type. With these tools, you generally have a static class (boo!) where you ask for the proper logging service for a type of object like this one:
-
public static class LoggerFactory { public static Logger LoggerFor(Type type) { return new Logger(type); } }
+
public static class LoggerFactory { public static Logger LoggerFor(Type type) { return new Logger(type); } }

Now, say you would want to have the proper Logger injected into every object that StructureMap creates that depends on Logger matching the concrete type of the object being created. That registration is shown below in a unit test from StructureMap's codebase:
-
[Fact] public void can_happily_use_the_parent_type() { var container = new Container(x => { // AlwaysUnique() is important so that every object created will get // their own Logger instead of sharing whichever one is created first x.For<Logger>().Use(c => LoggerFactory.LoggerFor(c.ParentType)).AlwaysUnique(); }); var top = container.GetInstance<LoggedClass1>(); top.Logger.ParentType.ShouldBe(typeof(LoggedClass1)); top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2)); top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3)); }
+
[Fact] public void can_happily_use_the_parent_type() { var container = new Container(x => { // AlwaysUnique() is important so that every object created will get // their own Logger instead of sharing whichever one is created first x.For<Logger>().Use(c => LoggerFactory.LoggerFor(c.ParentType)).AlwaysUnique(); }); var top = container.GetInstance<LoggedClass1>(); top.Logger.ParentType.ShouldBe(typeof(LoggedClass1)); top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2)); top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3)); }

Just for fun, here's the equivalent with the new construction policies from 4.0:
-
public class LoggerConvention : ConfiguredInstancePolicy { protected override void apply(Type pluginType, IConfiguredInstance instance) { instance.Constructor .GetParameters() .Where(param => param.ParameterType == typeof(Logger)) .Each(param => instance.Dependencies.Add(LoggerFactory.LoggerFor(instance.PluggedType))); } } [Fact] public void use_logger_convention() { var container = new Container(_ => { _.Policies.Add<LoggerConvention>(); }); var top = container.GetInstance<LoggedClass1>(); top.Logger.ParentType.ShouldBe(typeof(LoggedClass1)); top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2)); top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3)); }
+
public class LoggerConvention : ConfiguredInstancePolicy { protected override void apply(Type pluginType, IConfiguredInstance instance) { instance.Constructor .GetParameters() .Where(param => param.ParameterType == typeof(Logger)) .Each(param => instance.Dependencies.Add(LoggerFactory.LoggerFor(instance.PluggedType))); } } [Fact] public void use_logger_convention() { var container = new Container(_ => { _.Policies.Add<LoggerConvention>(); }); var top = container.GetInstance<LoggedClass1>(); top.Logger.ParentType.ShouldBe(typeof(LoggedClass1)); top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2)); top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3)); }

The LoggerConvention way of accomplishing the logging integration is technically more code and possibly harder to understand, but it's significantly more efficient at runtime because the decision about which Logger to use is only done once upfront. The conventional approach should also be more evident in StructureMap diagnostics.
@@ -124,10 +124,10 @@
Example 2: NHibernate Integration

If you're developing a system with NHibernate managed by StructureMap, you will frequently need to inject NHibernate's ISession service into your concrete classes. There's a little catch though, to create an ISession object you have to use NHibernate's ISessionFactory service:
-
public interface ISession { } public interface ISessionFactory { ISession Build(); }
+
public interface ISession { } public interface ISessionFactory { ISession Build(); }

Sidestepping the issue of how to build an ISessionFactory, here's a possible way to enable a StructureMap Container to build and resolve dependencies of ISession with a lambda builder:
-
public class SessionFactoryRegistry : Registry { // Let's not worry about how ISessionFactory is built // in this example public SessionFactoryRegistry(ISessionFactory factory) { For<ISessionFactory>().Use(factory); // Build ISession with a lambda: For<ISession>().Use("Build ISession from ISessionFactory", c => { // To resolve ISession, I first pull out // ISessionFactory from the IContext and use that // to build a new ISession. return c.GetInstance<ISessionFactory>().Build(); }); } }
+
public class SessionFactoryRegistry : Registry { // Let's not worry about how ISessionFactory is built // in this example public SessionFactoryRegistry(ISessionFactory factory) { For<ISessionFactory>().Use(factory); // Build ISession with a lambda: For<ISession>().Use("Build ISession from ISessionFactory", c => { // To resolve ISession, I first pull out // ISessionFactory from the IContext and use that // to build a new ISession. return c.GetInstance<ISessionFactory>().Build(); }); } }

From 6f56cbf093bddd673806c0fa099bfd04d5c2d217 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Thu, 12 Jul 2018 08:45:21 -0500 Subject: [PATCH 53/55] Documentation Update for 4.7.0 --- autofactory/index.html | 6 ++--- best-practices/index.html | 4 ++-- diagnostics/build-plans/index.html | 4 ++-- diagnostics/environment-tests/index.html | 4 ++-- diagnostics/index.html | 4 ++-- diagnostics/type-scanning/index.html | 4 ++-- .../using-the-container-model/index.html | 4 ++-- .../index.html | 4 ++-- diagnostics/whatdoihave/index.html | 4 ++-- documentation/index.html | 4 ++-- dynamic-interception/index.html | 4 ++-- features/index.html | 4 ++-- generics/index.html | 4 ++-- get-structuremap/index.html | 4 ++-- glossary/index.html | 4 ++-- history/index.html | 4 ++-- instances/index.html | 4 ++-- integrations/index.html | 4 ++-- interception-and-decorators/index.html | 6 ++--- interpreting-exceptions/index.html | 4 ++-- .../configuring-lifecycles/index.html | 4 ++-- object-lifecycle/custom-lifecycles/index.html | 4 ++-- object-lifecycle/index.html | 4 ++-- .../supported-lifecycles/index.html | 22 ++++--------------- quickstart/index.html | 4 ++-- registration/attributes/index.html | 6 ++--- .../index.html | 13 +++++++---- .../index.html | 4 ++-- registration/clear-or-replace/index.html | 4 ++-- registration/configured-instance/index.html | 6 ++--- registration/constructor-selection/index.html | 4 ++-- registration/existing-objects/index.html | 4 ++-- registration/fallback-services/index.html | 4 ++-- registration/index.html | 4 ++-- registration/inline-dependencies/index.html | 4 ++-- .../on-missing-family-policies/index.html | 6 ++--- registration/policies/index.html | 8 +++---- registration/registry-dsl/index.html | 4 ++-- release-notes/index.html | 12 +++++----- .../index.html | 4 ++-- .../get-a-service-by-plugintype/index.html | 4 ++-- .../index.html | 4 ++-- resolving/index.html | 4 ++-- .../passing-arguments-at-runtime/index.html | 4 ++-- .../requesting-a-concrete-type/index.html | 4 ++-- .../index.html | 4 ++-- .../index.html | 4 ++-- roadmap/index.html | 4 ++-- setter-injection/index.html | 4 ++-- software-design-concepts/index.html | 4 ++-- the-container/auto-wiring/index.html | 4 ++-- the-container/disposing/index.html | 4 ++-- .../index.html | 4 ++-- .../index.html | 4 ++-- the-container/index.html | 4 ++-- the-container/lambdas/index.html | 4 ++-- the-container/lazy-resolution/index.html | 4 ++-- the-container/nested-containers/index.html | 4 ++-- the-container/primitives/index.html | 4 ++-- .../profiles-and-child-containers/index.html | 4 ++-- .../working-with-enumerable-types/index.html | 4 ++-- .../index.html | 6 ++--- 62 files changed, 145 insertions(+), 154 deletions(-) mode change 100755 => 100644 autofactory/index.html mode change 100755 => 100644 best-practices/index.html mode change 100755 => 100644 diagnostics/build-plans/index.html mode change 100755 => 100644 diagnostics/environment-tests/index.html mode change 100755 => 100644 diagnostics/index.html mode change 100755 => 100644 diagnostics/type-scanning/index.html mode change 100755 => 100644 diagnostics/using-the-container-model/index.html mode change 100755 => 100644 diagnostics/validating-container-configuration/index.html mode change 100755 => 100644 diagnostics/whatdoihave/index.html mode change 100755 => 100644 documentation/index.html mode change 100755 => 100644 dynamic-interception/index.html mode change 100755 => 100644 features/index.html mode change 100755 => 100644 generics/index.html mode change 100755 => 100644 get-structuremap/index.html mode change 100755 => 100644 glossary/index.html mode change 100755 => 100644 history/index.html mode change 100755 => 100644 instances/index.html mode change 100755 => 100644 integrations/index.html mode change 100755 => 100644 interception-and-decorators/index.html mode change 100755 => 100644 interpreting-exceptions/index.html mode change 100755 => 100644 object-lifecycle/configuring-lifecycles/index.html mode change 100755 => 100644 object-lifecycle/custom-lifecycles/index.html mode change 100755 => 100644 object-lifecycle/index.html mode change 100755 => 100644 object-lifecycle/supported-lifecycles/index.html mode change 100755 => 100644 quickstart/index.html mode change 100755 => 100644 registration/attributes/index.html mode change 100755 => 100644 registration/auto-registration-and-conventions/index.html mode change 100755 => 100644 registration/changing-configuration-at-runtime/index.html mode change 100755 => 100644 registration/clear-or-replace/index.html mode change 100755 => 100644 registration/configured-instance/index.html mode change 100755 => 100644 registration/constructor-selection/index.html mode change 100755 => 100644 registration/existing-objects/index.html mode change 100755 => 100644 registration/fallback-services/index.html mode change 100755 => 100644 registration/index.html mode change 100755 => 100644 registration/inline-dependencies/index.html mode change 100755 => 100644 registration/on-missing-family-policies/index.html mode change 100755 => 100644 registration/policies/index.html mode change 100755 => 100644 registration/registry-dsl/index.html mode change 100755 => 100644 release-notes/index.html mode change 100755 => 100644 resolving/get-a-service-by-plugin-type-and-name/index.html mode change 100755 => 100644 resolving/get-a-service-by-plugintype/index.html mode change 100755 => 100644 resolving/get-all-services-by-plugin-type/index.html mode change 100755 => 100644 resolving/index.html mode change 100755 => 100644 resolving/passing-arguments-at-runtime/index.html mode change 100755 => 100644 resolving/requesting-a-concrete-type/index.html mode change 100755 => 100644 resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html mode change 100755 => 100644 resolving/try-getting-an-optional-service-by-plugin-type/index.html mode change 100755 => 100644 roadmap/index.html mode change 100755 => 100644 setter-injection/index.html mode change 100755 => 100644 software-design-concepts/index.html mode change 100755 => 100644 the-container/auto-wiring/index.html mode change 100755 => 100644 the-container/disposing/index.html mode change 100755 => 100644 the-container/forwarding-requests-for-a-type-to-another-type/index.html mode change 100755 => 100644 the-container/handling-missing-named-instances/index.html mode change 100755 => 100644 the-container/index.html mode change 100755 => 100644 the-container/lambdas/index.html mode change 100755 => 100644 the-container/lazy-resolution/index.html mode change 100755 => 100644 the-container/nested-containers/index.html mode change 100755 => 100644 the-container/primitives/index.html mode change 100755 => 100644 the-container/profiles-and-child-containers/index.html mode change 100755 => 100644 the-container/working-with-enumerable-types/index.html mode change 100755 => 100644 the-container/working-with-the-icontext-at-build-time/index.html diff --git a/autofactory/index.html b/autofactory/index.html old mode 100755 new mode 100644 index ffdeb0a..ae163eb --- a/autofactory/index.html +++ b/autofactory/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Best Practices

Previous
Aspect Oriented Programming with StructureMap.DynamicInterception

@@ -118,7 +118,7 @@
Custom convention

IAutoFactoryMethodDefinition GetMethodDefinition(MethodInfo methodInfo, IList<object> arguments);

IAutoFactoryMethodDefinition is defined as follows:
-
/// <summary> /// Describes how AutoFactory should treat the specific method declared in an abstract factory interface. /// </summary> public interface IAutoFactoryMethodDefinition { /// <summary> /// The method type. See <see cref="AutoFactoryMethodType"/> for possible values. /// </summary> AutoFactoryMethodType MethodType { get; } /// <summary> /// The instance type to create. /// </summary> Type InstanceType { get; } /// <summary> /// The instance name if available. /// </summary> string InstanceName { get; } /// <summary> /// Explicit arguments if available. /// </summary> ExplicitArguments ExplicitArguments { get; } }
+
public interface IAutoFactoryMethodDefinition { AutoFactoryMethodType MethodType { get; } Type InstanceType { get; } string InstanceName { get; } ExplicitArguments ExplicitArguments { get; } }

diff --git a/best-practices/index.html b/best-practices/index.html old mode 100755 new mode 100644 index 23d04cb..3259303 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
History

Previous
Auto-factories

diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html old mode 100755 new mode 100644 index cf5b6da..11471d4 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Using the Container Model

Previous
Environment Tests

diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html old mode 100755 new mode 100644 index 189b60c..4adc233 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Build Plans

Previous
Validating Container Configuration

diff --git a/diagnostics/index.html b/diagnostics/index.html old mode 100755 new mode 100644 index 4891836..b7f1686 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
WhatDoIHave()

Previous
Interpreting Exceptions

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100755 new mode 100644 index ae46488..9555b3e --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Aspect Oriented Programming with StructureMap.DynamicInterception

Previous
Using the Container Model

diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html old mode 100755 new mode 100644 index f46a21f..1225f9b --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Type Scanning Diagnostics

Previous
Build Plans

diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html old mode 100755 new mode 100644 index f5d8ee4..260d995 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Environment Tests

Previous
WhatDoIHave()

diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html old mode 100755 new mode 100644 index e9bbbb8..c2be817 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Validating Container Configuration

Previous
Diagnostics

diff --git a/documentation/index.html b/documentation/index.html old mode 100755 new mode 100644 index 97a8cef..8c986f8 --- a/documentation/index.html +++ b/documentation/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Roadmap

Previous
StructureMap

diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html old mode 100755 new mode 100644 index d0c2a00..12b0d5e --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Auto-factories

Previous
Diagnostics

diff --git a/features/index.html b/features/index.html old mode 100755 new mode 100644 index e202b49..df7d84e --- a/features/index.html +++ b/features/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Software Design Concepts

Previous
Get StructureMap

diff --git a/generics/index.html b/generics/index.html old mode 100755 new mode 100644 index aac4ce6..2dfaa6c --- a/generics/index.html +++ b/generics/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Interception and Decorators

Previous
Object Lifecycles

diff --git a/get-structuremap/index.html b/get-structuremap/index.html old mode 100755 new mode 100644 index 3e11211..ae70601 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Features

Previous
Glossary

diff --git a/glossary/index.html b/glossary/index.html old mode 100755 new mode 100644 index 5d31855..b129b57 --- a/glossary/index.html +++ b/glossary/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Get StructureMap

Previous
A Gentle Quickstart

diff --git a/history/index.html b/history/index.html old mode 100755 new mode 100644 index 9e5640e..d36313f --- a/history/index.html +++ b/history/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Release Notes

Previous
Best Practices

diff --git a/instances/index.html b/instances/index.html old mode 100755 new mode 100644 index 7481557..ab22c0b --- a/instances/index.html +++ b/instances/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Integrating StructureMap into Common .Net Frameworks

Previous
Release Notes

diff --git a/integrations/index.html b/integrations/index.html old mode 100755 new mode 100644 index 3938edd..2199255 --- a/integrations/index.html +++ b/integrations/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Previous
Custom Instance Types

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html old mode 100755 new mode 100644 index aac2ac7..8911a77 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Interpreting Exceptions

Previous
Generic Types

@@ -143,7 +143,7 @@
Interception Policies
and activators by an individual Instance or by matching on implementing types. For more customized interception policies that don't fit these mechanisms, StructureMap allows you to directly define an interception policy with a class implementing this interface below:
-
/// <summary> /// User defined policy to conventionally attach interceptors /// to any pluginType/instance combination in a StructureMap /// container /// </summary> public interface IInterceptorPolicy : IDescribed { /// <summary> /// Determine what (if any) interceptors should be attached to the /// given instance and pluginType /// </summary> /// <param name="pluginType">The Type that is being requested</param> /// <param name="instance">The Instance being built</param> /// <returns></returns> IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance); }
+
public interface IInterceptorPolicy : IDescribed { IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance); }

For a simple example, let's say that we want to decorate any IWidget object with the WidgetHolder class from earlier. We could build a small custom interceptor policy like this one:
diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html old mode 100755 new mode 100644 index f874445..fc594ce --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Diagnostics

Previous
Interception and Decorators

diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html old mode 100755 new mode 100644 index a290aa3..1c49ec6 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Custom Lifecycles

Previous
Supported Lifecycles

diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html old mode 100755 new mode 100644 index 30d7f51..24ca822 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Generic Types

Previous
Configuring Lifecycles

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html old mode 100755 new mode 100644 index 3879404..694ac48 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Supported Lifecycles

Previous
The Container

diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html old mode 100755 new mode 100644 index afb5a14..904343d --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Configuring Lifecycles

Previous
Object Lifecycles

@@ -100,8 +100,8 @@
Supported Lifecycles Transient

Older versions of StructureMap referred to Transient as PerRequest, which might be a more accurate reflection of how this lifecycle behaves but -causes some confusion with ASP.Net HTTP scoping. The easiest way to think of Transient is that a single object instance will be created for each top level -call to Container.GetInstance() (or any other object resolution method on the IContainer interface). Transient objects resolved from a nested container, Transient's are scoped to the lifecycle +causes some confusion with ASP.NET HTTP scoping. The easiest way to think of Transient is that a single object instance will be created for each top level +call to Container.GetInstance() (or any other object resolution method on the IContainer interface). Transient objects resolved from a nested container, Transients are scoped to the lifecycle of the nested container itself. See Nested Containers (Per Request/Transaction) for more information.

StructureMap's behavior for transient objects that implement IDisposable changed in 4.0 to introduce an "opt-in" tracking mode. Please see StructureMap and IDisposable for the details.

The following unit test demonstrates how Transient lifecycles work in both root and nested containers.
@@ -131,20 +131,6 @@
ContainerScoped

ThreadLocal

The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test:

public class ThreadLocalStorageLifecycleTester { public ThreadLocalStorageLifecycleTester() { _lifecycle = new ThreadLocalStorageLifecycle(); container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red"))); } private ThreadLocalStorageLifecycle _lifecycle; private ColorRule _rule1; private ColorRule _rule2; private ColorRule _rule3; private Container container; private void findRule1() { _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule1.ShouldBeTheSameAs(rule); } private void findRule2() { _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule2.ShouldBeTheSameAs(rule); } private void findRule3() { _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>(); _rule3.ShouldBeTheSameAs(rule); } [Fact] public void object_has_been_created() { container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse(); var r1 = container.GetInstance<Rule>(); container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue(); } [Fact] public void FindUniqueInstancePerThread() { var t1 = new Thread(findRule1); var t2 = new Thread(findRule2); var t3 = new Thread(findRule3); t1.Start(); t2.Start(); t3.Start(); t1.Join(); t2.Join(); t3.Join(); _rule1.ShouldNotBeTheSameAs(_rule2); _rule1.ShouldNotBeTheSameAs(_rule3); _rule2.ShouldNotBeTheSameAs(_rule3); (_rule1.ID != _rule2.ID).ShouldBeTrue(); (_rule1.ID != _rule3.ID).ShouldBeTrue(); (_rule2.ID != _rule3.ID).ShouldBeTrue(); } }
-
Legacy ASP.Net Lifecycles
-
The StructureMap team strongly recommends against using the old ASP.Net lifecycles. Most modern web frameworks in .Net will use a Nested Container per request to accomplish the same scoping in a better way.
- -
In addition, the StructureMap.Web package adds the legacy ASP.Net related lifecycles for:
-
-
HttpContext
-
HttpSession (requires objects to be Serializable, not recommended but still present for legacy code
-
Hybrid -- uses ThreadLocalStorage in the absence of an active HttpContext
-
HybridSession
-
-
Missing code sample 'AspNet-Lifecycles' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh
-
If you do use any of the HttpContext lifecycles, make sure you also do:
-
Missing code sample 'clean-up-http-context' -- Wait for dotnet stdocs to catch up reading samples or CTRL+SHIFT+R to force refresh
-
at the end of your HTTP request.

diff --git a/quickstart/index.html b/quickstart/index.html old mode 100755 new mode 100644 index 4e392b2..223677e --- a/quickstart/index.html +++ b/quickstart/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Glossary

Previous
Roadmap

diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100755 new mode 100644 index 1713609..3b78e1e --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Resolving Services

Previous
Replace or Clear Out Previous Registrations

@@ -97,7 +97,7 @@
Using Attributes for Configuration /// <summary> /// Base class for custom configuration attributes /// </summary> public abstract class StructureMapAttribute : Attribute { /// <summary> /// Override this method to apply a configuration change to an entire /// PluginFamily (every Instance of a certain PluginType) /// </summary> /// <param name="family"></param> public virtual void Alter(PluginFamily family) { } /// <summary> /// Make configuration alterations to a single IConfiguredInstance object /// </summary> /// <param name="instance"></param> public virtual void Alter(IConfiguredInstance instance) { } /// <summary> /// Apply configuration customization to a single setter property /// </summary> /// <param name="instance"></param> /// <param name="property"></param> public virtual void Alter(IConfiguredInstance instance, PropertyInfo property) { } /// <summary> /// Apply configuration customization for a single constructor parameter /// </summary> /// <param name="instance"></param> /// <param name="parameter"></param> public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter) { } } +
public abstract class StructureMapAttribute : Attribute { public virtual void Alter(PluginFamily family) { } public virtual void Alter(IConfiguredInstance instance) { } public virtual void Alter(IConfiguredInstance instance, PropertyInfo property) { } public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter) { } }

There's a couple thing to note, here about this new attibute:

StructureMap internals are looking for any attribute of the base class. Attributes that affect types are read and applied early, diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html old mode 100755 new mode 100644 index 6838a65..c8a7c81 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Working with IConfiguredInstance

Previous
Inline Dependencies

@@ -120,11 +120,11 @@
Scan for Registries

As of 4.0, this operation is now recursive and StructureMap has always been idempotent about adding Registry types

Search for Assemblies on the File System

StructureMap provides facilities for registering types by finding assemblies in the application bin path:
-
[Fact] public void scan_all_assemblies_in_a_folder() { Scan(x => x.AssembliesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory() { Scan(x => x.AssembliesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); }
+
[Fact] public void scan_all_assemblies_in_a_folder() { Scan(x => x.AssembliesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_a_folder_with_path_filter() { Scan(x => x.AssembliesFromPath(assemblyScanningFolder, path => !path.Contains("Widget5"))); shouldNotHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory() { Scan(x => x.AssembliesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory_with_path_filter() { Scan(x => x.AssembliesFromApplicationBaseDirectory(path => !path.Contains("Widget5"))); shouldNotHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldNotHaveFamilyWithSameName<IDefinedInExe>(); }

Do note that StructureMap 4.0 does not search for .exe files in the assembly search. The StructureMap team felt this was problematic and "nobody would ever actually want to do that." We were wrong, and due to many user requests, you can now opt in to scanning .exe files with a new public method on AssemblyScanner shown below:
-
[Fact] public void scan_all_assemblies_in_a_folder_including_exe() { Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory_including_exe() { Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); }
+
[Fact] public void scan_all_assemblies_in_a_folder_including_exe() { Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder)); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_a_folder_including_exe_with_path_filter() { Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder, path => !path.Contains("Widget5"))); shouldNotHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory_including_exe() { Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory()); shouldHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); } [Fact] public void scan_all_assemblies_in_application_base_directory_including_exe_with_path_filter() { Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory(path => !path.Contains("Widget5"))); shouldNotHaveFamilyWithSameName<IInterfaceInWidget5>(); shouldHaveFamilyWithSameName<IWorker>(); shouldHaveFamilyWithSameName<IDefinedInExe>(); }

Do be aware that while this technique is very powerful for extensibility, it's been extremely problematic for some folks in the past. The StructureMap team's recommendation for using this feature is to:

@@ -150,6 +150,11 @@
Custom Registration Conventions

Let's say that you'd like a custom convention that just registers a concrete type against all the interfaces that it implements. You could then build a custom IRegistrationConvention class like the following example:

public interface IFoo { } public interface IBar { } public interface IBaz { } public class BusyGuy : IFoo, IBar, IBaz { } // Custom IRegistrationConvention public class AllInterfacesConvention : IRegistrationConvention { public void ScanTypes(TypeSet types, Registry registry) { // Only work on concrete types types.FindTypes(TypeClassification.Concretes | TypeClassification.Closed).Each(type => { // Register against all the interfaces implemented // by this concrete class type.GetInterfaces().Each(@interface => registry.For(@interface).Use(type)); }); } } [Fact] public void use_custom_registration_convention() { var container = new Container(_ => { _.Scan(x => { // You're probably going to want to tightly filter // the Type's that are applicable to avoid unwanted // registrations x.TheCallingAssembly(); x.IncludeNamespaceContainingType<BusyGuy>(); // Register the custom policy x.Convention<AllInterfacesConvention>(); }); }); container.GetInstance<IFoo>().ShouldBeOfType<BusyGuy>(); container.GetInstance<IBar>().ShouldBeOfType<BusyGuy>(); container.GetInstance<IBaz>().ShouldBeOfType<BusyGuy>(); }
+
Composite Decorators
+
Sometimes you need to have many implementations of an interface, and to have all of them used together, which usually involves creating another implementation of the interface which takes all the others as dependencies.
+
If you try this in StructureMap, it will throw an exception as it detects a bi-directional dependency. This is because by default an IEnumerable<T> constructor parameter will be populated with all instances of T, which would include the implementation with the IEnumerable<T>parameter!
+
We can use a custom IRegistrationConvention however to tell StructureMap that when it constructs a Composite, it should only include implementations which are not the Composite:
+
public interface ISomething { IEnumerable<string> GetNames(); } public class One : ISomething { public IEnumerable<string> GetNames() => new[] { "one" }; } public class Two : ISomething { public IEnumerable<string> GetNames() => new[] { "two" }; } public class SomethingComposite : ISomething { private readonly IEnumerable<ISomething> _others; public SomethingComposite(IEnumerable<ISomething> others) { _others = others; } public IEnumerable<string> GetNames() => _others.SelectMany(other => other.GetNames()); } // Custom IRegistrationConvention public class CompositeDecorator<TComposite, TDependents> : IRegistrationConvention where TComposite : TDependents { public void ScanTypes(TypeSet types, Registry registry) { var dependents = types .FindTypes(TypeClassification.Concretes) .Where(t => t.CanBeCastTo<TDependents>() && t.HasConstructors()) .Where(t => t != typeof(TComposite)) .ToList(); registry.For<TDependents>() .Use<TComposite>() .EnumerableOf<TDependents>().Contains(x => dependents.ForEach(t => x.Type(t))); } } [Fact] public void use_custom_registration_convention_2() { var container = new Container(_ => { _.Scan(x => { x.AssemblyContainingType<ISomething>(); x.Convention<CompositeDecorator<SomethingComposite, ISomething>>(); }); }); var composite = container.GetInstance<ISomething>(); composite.ShouldBeOfType<SomethingComposite>(); composite.GetNames().ShouldBe(new[] { "one", "two" }, ignoreOrder: true); }

The Default ISomething/Something Convention

The "default" convention simply tries to connect concrete classes to interfaces using the I[Something]/[Something] naming convention as shown in this sample:
diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html old mode 100755 new mode 100644 index a9ea947..027528e --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
On Missing Family Policies

Previous
Construction Policies

diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100755 new mode 100644 index 0f7b119..80757eb --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Using Attributes for Configuration

Previous
Registering Existing Objects

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100755 new mode 100644 index 469ac69..5979e10 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Construction Policies

Previous
Auto-Registration and Conventions

@@ -95,7 +95,7 @@
Working with IConfiguredInstance Registry DSL fluent interface provides the main way of explicitly configuring concrete type creation, the IConfiguredInstance interface is meant to support conventional registration, configuration attributes, and construction policies.
-
/// <summary> /// Represents a configured Instance object that /// is built by StructureMap directly by calling /// constructor functions and property setters /// </summary> public interface IConfiguredInstance { /// <summary> /// The Instance name /// </summary> string Name { get; set; } /// <summary> /// The actual concrete type built by this Instance /// </summary> Type PluggedType { get; } /// <summary> /// The explicitly configured inline dependencies that override /// auto-wiring /// </summary> DependencyCollection Dependencies { get; } /// <summary> /// Add an interceptor to only this Instance /// </summary> /// <param name="interceptor"></param> void AddInterceptor(IInterceptor interceptor); /// <summary> /// Set the lifecycle of only this Instance to the ILifecycle type. /// </summary> /// <typeparam name="T"></typeparam> /// <example> /// SetLifecycleTo<SingletonLifecycle>() /// </example> void SetLifecycleTo<T>() where T : ILifecycle, new(); /// <summary> /// Set the lifecycle of only this Instance to a certain lifecycle /// </summary> /// <param name="lifecycle"></param> void SetLifecycleTo(ILifecycle lifecycle); /// <summary> /// The current Lifecycle that will be used for this Instance /// </summary> ILifecycle Lifecycle { get; } /// <summary> /// Explicitly choose a constructor /// </summary> ConstructorInfo Constructor { get; set; } /// <summary> /// Has a build plan already been created for this instance? /// </summary> /// <returns></returns> bool HasBuildPlan(); /// <summary> /// Clears out any cached IBuildPlan for this Instance. /// </summary> void ClearBuildPlan(); }
+
public interface IConfiguredInstance { string Name { get; set; } Type PluggedType { get; } DependencyCollection Dependencies { get; } void AddInterceptor(IInterceptor interceptor); void SetLifecycleTo<T>() where T : ILifecycle, new(); void SetLifecycleTo(ILifecycle lifecycle); ILifecycle Lifecycle { get; } ConstructorInfo Constructor { get; set; } bool HasBuildPlan(); void ClearBuildPlan(); }

Changing the Instance Lifecycle

You can override the lifecycle of a single IConfiguredInstance by calling the LifecycleIs() methods and either supplying a type of ILifecycle or an ILifecycle object. As a quick helper, there are also extension methods for common lifecycles:
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html old mode 100755 new mode 100644 index 14aaf2a..7fb043c --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Fallback Services

Previous
On Missing Family Policies

diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html old mode 100755 new mode 100644 index fa22cd4..542e1ea --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Replace or Clear Out Previous Registrations

Previous
Fallback Services

diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html old mode 100755 new mode 100644 index dca372f..f5e1151 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Registering Existing Objects

Previous
Constructor Selection

diff --git a/registration/index.html b/registration/index.html old mode 100755 new mode 100644 index 2db6a99..1d2dd01 --- a/registration/index.html +++ b/registration/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Registry DSL

Previous
Setter Injection

diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html old mode 100755 new mode 100644 index a068d5f..59060e3 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Auto-Registration and Conventions

Previous
Registry DSL

diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html old mode 100755 new mode 100644 index 0a8b5c4..cd8b161 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Constructor Selection

Previous
Changing Configuration at Runtime

@@ -92,7 +92,7 @@
On Missing Family Policies /// <summary> /// Allows StructureMap to fill in missing registrations by unknown plugin types /// at runtime /// </summary> public interface IFamilyPolicy { /// <summary> /// Allows you to create missing registrations for an unknown plugin type /// at runtime. /// Return null if this policy does not apply to the given type /// </summary> PluginFamily Build(Type type); /// <summary> /// Should this policy be used to determine whether or not the Container has /// registrations for a plugin type in the PluginGraph.HasFamily(type) method /// </summary> bool AppliesToHasFamilyChecks { get; } } +
public interface IFamilyPolicy { PluginFamily Build(Type type); bool AppliesToHasFamilyChecks { get; } }

Internally, if you make a request to IContainer.GetInstance(type) for a type that the active Container does not recognize, StructureMap will next try to apply all the registered IFamilyPolicy policies to create a PluginFamily object for that plugin type that models the registrations for that plugin type, including the default, additional named instances, interceptors or decorators, and lifecycle rules.

The simplest built in example is the EnumerableFamilyPolicy shown below that can fill in requests for IList<T>, ICollection<T>, and T[] with a collection of all the known registrations of the type T:
diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100755 new mode 100644 index 95c62b6..8905800 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Changing Configuration at Runtime

Previous
Working with IConfiguredInstance

@@ -94,7 +94,7 @@
Construction Policies interception policies. The 4.0 release extends StructureMap's support for conventional build policies with a new mechanism for altering how object instances are built based on user created meta-conventions using the IInstancePolicy shown below:
-
/// <summary> /// Custom policy on Instance construction that is evaluated /// as part of creating a "build plan" /// </summary> public interface IInstancePolicy { /// <summary> /// Apply any conventional changes to the configuration /// of a single Instance /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> void Apply(Type pluginType, Instance instance); }
+
public interface IInstancePolicy { void Apply(Type pluginType, Instance instance); }

These policies are registered as part of the registry dsl with the Policies.Add() method:

var container = new Container(_ => { _.Policies.Add<MyCustomPolicy>(); // or _.Policies.Add(new MyCustomPolicy()); });
@@ -109,7 +109,7 @@
Construction Policies public abstract class ConfiguredInstancePolicy : IInstancePolicy { /// <summary> /// Applies explicit configuration to an IConfiguredInstance /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> public void Apply(Type pluginType, Instance instance) { var configured = instance as IConfiguredInstance; if (configured != null) { apply(pluginType, configured); } } /// <summary> /// This method is called against any Instance that implements the /// IConfiguredInstance interface /// </summary> /// <param name="pluginType"></param> /// <param name="instance"></param> protected abstract void apply(Type pluginType, IConfiguredInstance instance); } +
public abstract class ConfiguredInstancePolicy : IInstancePolicy { public void Apply(Type pluginType, Instance instance) { var configured = instance as IConfiguredInstance; if (configured != null) { apply(pluginType, configured); } } protected abstract void apply(Type pluginType, IConfiguredInstance instance); }

For more information, see:

Build Plans
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html old mode 100755 new mode 100644 index f313dae..6290e1c --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Inline Dependencies

Previous
Registration

diff --git a/release-notes/index.html b/release-notes/index.html old mode 100755 new mode 100644 index 871ae29..d8d3b68 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Custom Instance Types

Previous
History

@@ -186,10 +186,10 @@
Release Notes 3.0

Related links:

-
http://jeremydmiller.com/2014/02/18/structuremap-3-is-gonna-tell-you-whats-wrong-and-where-it-hurts/
-
http://jeremydmiller.com/2014/01/17/structuremap-3-0-is-very-nearly-done-no-seriously/
-
http://jeremydmiller.com/2013/02/22/big-update-on-structuremap-3-0-progress/
-
http://jeremydmiller.com/2013/01/30/lets-try-this-again-structuremap-3-0-in-en-route-as-of-now/
+
http://jeremydmiller.com/2014/02/18/structuremap-3-is-gonna-tell-you-whats-wrong-and-where-it-hurts/
+
http://jeremydmiller.com/2014/01/17/structuremap-3-0-is-very-nearly-done-no-seriously/
+
http://jeremydmiller.com/2013/02/22/big-update-on-structuremap-3-0-progress/
+
http://jeremydmiller.com/2013/01/30/lets-try-this-again-structuremap-3-0-in-en-route-as-of-now/

diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html old mode 100755 new mode 100644 index e335a48..0647168 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Get all Services by Plugin Type

Previous
Get a Service by PluginType

diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html old mode 100755 new mode 100644 index 803e694..b64e999 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Get a Service by Plugin Type and Name

Previous
Resolving Services

diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html old mode 100755 new mode 100644 index 5806cfa..0c9ec0b --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Try Getting an Optional Service by Plugin Type

Previous
Get a Service by Plugin Type and Name

diff --git a/resolving/index.html b/resolving/index.html old mode 100755 new mode 100644 index 1571e5b..06839df --- a/resolving/index.html +++ b/resolving/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Get a Service by PluginType

Previous
Registration

diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html old mode 100755 new mode 100644 index 20c94ad..da263b5 --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Auto Resolving Concrete Types

Previous
Try Geting an Optional Service by Plugin Type and Name

diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html old mode 100755 new mode 100644 index 129a66e..31cf124 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
The Container

Previous
Passing Arguments at Runtime

diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html old mode 100755 new mode 100644 index 65d4e58..06a982a --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Passing Arguments at Runtime

Previous
Try Getting an Optional Service by Plugin Type

diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html old mode 100755 new mode 100644 index 2598d2a..8f5e80d --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Try Geting an Optional Service by Plugin Type and Name

Previous
Get all Services by Plugin Type

diff --git a/roadmap/index.html b/roadmap/index.html old mode 100755 new mode 100644 index c71f0ba..5e1dc60 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
A Gentle Quickstart

Previous
Documentation

diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100755 new mode 100644 index a7cdd71..14257ec --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Registration

Previous
Software Design Concepts

diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html old mode 100755 new mode 100644 index 396c45b..2d127d7 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Setter Injection

Previous
Features

diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html old mode 100755 new mode 100644 index 918b382..d00ffcd --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Building Objects with Lambdas

Previous
The Container

diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html old mode 100755 new mode 100644 index de6e948..2cfc305 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Working with Primitive Types

Previous
Lazy Resolution

diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html old mode 100755 new mode 100644 index 9b28ea9..66d8ff7 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Profiles and Child Containers

Previous
Working with the IContext at Build Time

diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html old mode 100755 new mode 100644 index cc54ab3..79d6123 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Lazy Resolution

Previous
Working with Enumerable Types

diff --git a/the-container/index.html b/the-container/index.html old mode 100755 new mode 100644 index 55a2900..3f456db --- a/the-container/index.html +++ b/the-container/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Auto Wiring

Previous
Resolving Services

diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100755 new mode 100644 index 0564318..8cb764b --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Working with the IContext at Build Time

Previous
Auto Wiring

diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html old mode 100755 new mode 100644 index a6aa78b..9c782de --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
StructureMap and IDisposable

Previous
Handling Missing Named Instances

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html old mode 100755 new mode 100644 index 3d8e5c5..82059b5 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Working with Enumerable Types

Previous
Profiles and Child Containers

diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100755 new mode 100644 index 5ab13b3..52aa666 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Object Lifecycles

Previous
StructureMap and IDisposable

diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html old mode 100755 new mode 100644 index 8f46e9e..2889383 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Nested Containers (Per Request/Transaction)

Previous
Registering a Single Instance Against Multiple PluginTypes

diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html old mode 100755 new mode 100644 index 8231626..fcf6176 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Handling Missing Named Instances

Previous
Nested Containers (Per Request/Transaction)

diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html old mode 100755 new mode 100644 index ea46e0a..49e653e --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -31,7 +31,7 @@

- StructureMap 4.6.0 + StructureMap 4.7.0

@@ -74,7 +74,7 @@

-
+

Next
Registering a Single Instance Against Multiple PluginTypes

Previous
Building Objects with Lambdas

@@ -104,7 +104,7 @@
Working with the IContext at Build Time /// <summary> /// Access to the state and type resolution of the current "build session" /// during a request to a StructureMap container /// </summary> public interface IContext { /// <summary> /// The requested instance name of the object graph /// </summary> string RequestedName { get; } /// <summary> /// The "BuildUp" method takes in an already constructed object /// and uses Setter Injection to push in configured dependencies /// of that object /// </summary> /// <param name="target"></param> void BuildUp(object target); /// <summary> /// Get the object of type T that is valid for this build session. /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T GetInstance<T>(); /// <summary> /// Get the object of type T that is valid for this build session by name. /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T GetInstance<T>(string name); /// <summary> /// Get a service from the current build session by type /// </summary> /// <param name="pluginType"></param> /// <returns></returns> object GetInstance(Type pluginType); /// <summary> /// Creates or finds the named instance of the pluginType /// </summary> /// <param name="pluginType"></param> /// <param name="instanceKey"></param> /// <returns></returns> object GetInstance(Type pluginType, string instanceKey); /// <summary> /// Same as GetInstance, but can gracefully return null if /// the Type does not already exist /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> T TryGetInstance<T>() where T : class; /// <summary> /// Same as GetInstance(name), but can gracefully return null if /// the Type and name does not already exist /// </summary> /// <typeparam name="T"></typeparam> /// <param name="name"></param> /// <returns></returns> T TryGetInstance<T>(string name) where T : class; /// <summary> /// Creates or finds the default instance of the pluginType. Returns null if the pluginType is not known to the container. /// </summary> /// <param name="pluginType"></param> /// <returns></returns> object TryGetInstance(Type pluginType); /// <summary> /// Creates or finds the named instance of the pluginType. Returns null if the named instance is not known to the container. /// </summary> /// <param name="pluginType"></param> /// <param name="instanceKey"></param> /// <returns></returns> object TryGetInstance(Type pluginType, string instanceKey); /// <summary> /// Gets all objects in the current object graph that can be cast /// to T that have already been created /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> IEnumerable<T> All<T>() where T : class; /// <summary> /// Creates/Resolves every configured instance of PlutinType T /// </summary> /// <typeparam name="T"></typeparam> /// <returns></returns> IEnumerable<T> GetAllInstances<T>(); /// <summary> /// Creates or resolves all registered instances of the pluginType /// </summary> /// <param name="pluginType"></param> /// <returns></returns> IEnumerable<object> GetAllInstances(Type pluginType); /// <summary> /// The type of the parent object. Useful for constructing /// contextual logging dependencies /// </summary> Type ParentType { get; } /// <summary> /// The type of the requested object at the very top of the /// object graph /// </summary> Type RootType { get; } } +
public interface IContext { string RequestedName { get; } void BuildUp(object target); T GetInstance<T>(); T GetInstance<T>(string name); object GetInstance(Type pluginType); object GetInstance(Type pluginType, string instanceKey); T TryGetInstance<T>() where T : class; T TryGetInstance<T>(string name) where T : class; object TryGetInstance(Type pluginType); object TryGetInstance(Type pluginType, string instanceKey); IEnumerable<T> All<T>() where T : class; IEnumerable<T> GetAllInstances<T>(); IEnumerable<object> GetAllInstances(Type pluginType); Type ParentType { get; } Type RootType { get; } }

Example 1: Contextual Logging

All of the sample code in this example is in Github.

One of the canonical examples of using IContext is the integration of logging frameworks like NLog or Log4net From e946ceabb47d2cab4982e29eff0d26a32eeef354 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Thu, 12 Jul 2018 09:00:59 -0500 Subject: [PATCH 54/55] Documentation Update for 4.7.0 --- autofactory/index.html | 8 ++++++++ best-practices/index.html | 8 ++++++++ diagnostics/build-plans/index.html | 8 ++++++++ diagnostics/environment-tests/index.html | 8 ++++++++ diagnostics/index.html | 8 ++++++++ diagnostics/type-scanning/index.html | 8 ++++++++ diagnostics/using-the-container-model/index.html | 8 ++++++++ diagnostics/validating-container-configuration/index.html | 8 ++++++++ diagnostics/whatdoihave/index.html | 8 ++++++++ documentation/index.html | 8 ++++++++ dynamic-interception/index.html | 8 ++++++++ features/index.html | 8 ++++++++ generics/index.html | 8 ++++++++ get-structuremap/index.html | 8 ++++++++ glossary/index.html | 8 ++++++++ history/index.html | 8 ++++++++ index.html | 2 ++ instances/index.html | 8 ++++++++ integrations/index.html | 8 ++++++++ interception-and-decorators/index.html | 8 ++++++++ interpreting-exceptions/index.html | 8 ++++++++ object-lifecycle/configuring-lifecycles/index.html | 8 ++++++++ object-lifecycle/custom-lifecycles/index.html | 8 ++++++++ object-lifecycle/index.html | 8 ++++++++ object-lifecycle/supported-lifecycles/index.html | 8 ++++++++ quickstart/index.html | 8 ++++++++ registration/attributes/index.html | 8 ++++++++ registration/auto-registration-and-conventions/index.html | 8 ++++++++ registration/changing-configuration-at-runtime/index.html | 8 ++++++++ registration/clear-or-replace/index.html | 8 ++++++++ registration/configured-instance/index.html | 8 ++++++++ registration/constructor-selection/index.html | 8 ++++++++ registration/existing-objects/index.html | 8 ++++++++ registration/fallback-services/index.html | 8 ++++++++ registration/index.html | 8 ++++++++ registration/inline-dependencies/index.html | 8 ++++++++ registration/on-missing-family-policies/index.html | 8 ++++++++ registration/policies/index.html | 8 ++++++++ registration/registry-dsl/index.html | 8 ++++++++ release-notes/index.html | 8 ++++++++ .../get-a-service-by-plugin-type-and-name/index.html | 8 ++++++++ resolving/get-a-service-by-plugintype/index.html | 8 ++++++++ resolving/get-all-services-by-plugin-type/index.html | 8 ++++++++ resolving/index.html | 8 ++++++++ resolving/passing-arguments-at-runtime/index.html | 8 ++++++++ resolving/requesting-a-concrete-type/index.html | 8 ++++++++ .../index.html | 8 ++++++++ .../index.html | 8 ++++++++ roadmap/index.html | 8 ++++++++ setter-injection/index.html | 8 ++++++++ software-design-concepts/index.html | 8 ++++++++ the-container/auto-wiring/index.html | 8 ++++++++ the-container/disposing/index.html | 8 ++++++++ .../index.html | 8 ++++++++ the-container/handling-missing-named-instances/index.html | 8 ++++++++ the-container/index.html | 8 ++++++++ the-container/lambdas/index.html | 8 ++++++++ the-container/lazy-resolution/index.html | 8 ++++++++ the-container/nested-containers/index.html | 8 ++++++++ the-container/primitives/index.html | 8 ++++++++ the-container/profiles-and-child-containers/index.html | 8 ++++++++ the-container/working-with-enumerable-types/index.html | 8 ++++++++ .../working-with-the-icontext-at-build-time/index.html | 8 ++++++++ 63 files changed, 498 insertions(+) diff --git a/autofactory/index.html b/autofactory/index.html index ae163eb..9bf0313 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Best Practices
diff --git a/best-practices/index.html b/best-practices/index.html index 3259303..1bbacac 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
History
diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index 11471d4..71f9fe3 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Using the Container Model
diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html index 4adc233..92437c6 100644 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Build Plans
diff --git a/diagnostics/index.html b/diagnostics/index.html index b7f1686..bedf274 100644 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
WhatDoIHave()
diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html index 9555b3e..8185408 100644 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Aspect Oriented Programming with StructureMap.DynamicInterception
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index 1225f9b..caf6df2 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Type Scanning Diagnostics
diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index 260d995..d318dec 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Environment Tests
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html index c2be817..6e6620d 100644 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Validating Container Configuration
diff --git a/documentation/index.html b/documentation/index.html index 8c986f8..575101e 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Roadmap
diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html index 12b0d5e..fcb4daf 100644 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Auto-factories
diff --git a/features/index.html b/features/index.html index df7d84e..1ff9995 100644 --- a/features/index.html +++ b/features/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Software Design Concepts
diff --git a/generics/index.html b/generics/index.html index 2dfaa6c..2d9805e 100644 --- a/generics/index.html +++ b/generics/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Interception and Decorators
diff --git a/get-structuremap/index.html b/get-structuremap/index.html index ae70601..e1f1baf 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Features
diff --git a/glossary/index.html b/glossary/index.html index b129b57..1d686bb 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Get StructureMap
diff --git a/history/index.html b/history/index.html index d36313f..6701e6a 100644 --- a/history/index.html +++ b/history/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Release Notes
diff --git a/index.html b/index.html index e7e693c..3d7abfd 100644 --- a/index.html +++ b/index.html @@ -54,6 +54,8 @@

StructureMap

+StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ StructureMap is the oldest, continuously used IoC/DI container for .Net dating back to its first public release and production usage all the way back in June 2004 on .Net 1.1. The current 4.* release represents 12+ years of lessons learned in the StructureMap and greater .Net community -- while also wiping away a great deal of legacy design decisions that no longer make sense today. diff --git a/instances/index.html b/instances/index.html index ab22c0b..ebe8152 100644 --- a/instances/index.html +++ b/instances/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Integrating StructureMap into Common .Net Frameworks
diff --git a/integrations/index.html b/integrations/index.html index 2199255..06112a5 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index 8911a77..c581a0c 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Interpreting Exceptions
diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index fc594ce..91797dd 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Diagnostics
diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index 1c49ec6..b603341 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Custom Lifecycles
diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index 24ca822..cea284c 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Generic Types
diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index 694ac48..ab409bc 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Supported Lifecycles
diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 904343d..8d8219a 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Configuring Lifecycles
diff --git a/quickstart/index.html b/quickstart/index.html index 223677e..f3967be 100644 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Glossary
diff --git a/registration/attributes/index.html b/registration/attributes/index.html index 3b78e1e..d8c4355 100644 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Resolving Services
diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index c8a7c81..f34919f 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Working with IConfiguredInstance
diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index 027528e..d1bb4c0 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
On Missing Family Policies
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index 80757eb..bb37816 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Using Attributes for Configuration
diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index 5979e10..dda7f1a 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Construction Policies
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index 7fb043c..2de8d2f 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Fallback Services
diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html index 542e1ea..c5c698e 100644 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Replace or Clear Out Previous Registrations
diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index f5e1151..f9004c5 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Registering Existing Objects
diff --git a/registration/index.html b/registration/index.html index 1d2dd01..5aff465 100644 --- a/registration/index.html +++ b/registration/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Registry DSL
diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index 59060e3..bf345d1 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Auto-Registration and Conventions
diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index cd8b161..ecdb842 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Constructor Selection
diff --git a/registration/policies/index.html b/registration/policies/index.html index 8905800..ed7bc22 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Changing Configuration at Runtime
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 6290e1c..636e516 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Inline Dependencies
diff --git a/release-notes/index.html b/release-notes/index.html index d8d3b68..8be4f6b 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Custom Instance Types
diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html index 0647168..74c32ad 100644 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Get all Services by Plugin Type
diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html index b64e999..5a0bb07 100644 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Get a Service by Plugin Type and Name
diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html index 0c9ec0b..79e6f08 100644 --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Try Getting an Optional Service by Plugin Type
diff --git a/resolving/index.html b/resolving/index.html index 06839df..1ff70d2 100644 --- a/resolving/index.html +++ b/resolving/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Get a Service by PluginType
diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html index da263b5..ee39ca0 100644 --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Auto Resolving Concrete Types
diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index 31cf124..0352cd5 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
The Container
diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html index 06a982a..88c3325 100644 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Passing Arguments at Runtime
diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html index 8f5e80d..384beae 100644 --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Try Geting an Optional Service by Plugin Type and Name
diff --git a/roadmap/index.html b/roadmap/index.html index 5e1dc60..1bfafc1 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
A Gentle Quickstart
diff --git a/setter-injection/index.html b/setter-injection/index.html index 14257ec..3c7df71 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Registration
diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index 2d127d7..fdaa0fc 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Setter Injection
diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index d00ffcd..ad5979d 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Building Objects with Lambdas
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index 2cfc305..a73dd4a 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Working with Primitive Types
diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index 66d8ff7..1a7de23 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Profiles and Child Containers
diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index 79d6123..a1db1d9 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Lazy Resolution
diff --git a/the-container/index.html b/the-container/index.html index 3f456db..0807228 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Auto Wiring
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 8cb764b..179e899 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Working with the IContext at Build Time
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html index 9c782de..3f39e48 100644 --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
StructureMap and IDisposable
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 82059b5..334443b 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Working with Enumerable Types
diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index 52aa666..2728bbc 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Object Lifecycles
diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index 2889383..74163aa 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Nested Containers (Per Request/Transaction)
diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index fcf6176..b11f053 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Handling Missing Named Instances
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index 49e653e..e7a023a 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -72,7 +72,15 @@
+
+
+ + StructureMap has been sunsetted. Please see Lamar as a possible replacement.

+ +
+ +

Next
Registering a Single Instance Against Multiple PluginTypes
From 3cb3db87db92932bb84b324a9451f05ec4e6b6d9 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Tue, 2 Apr 2019 14:46:07 -0500 Subject: [PATCH 55/55] Documentation Update for 4.7.0 --- autofactory/index.html | 8 -------- best-practices/index.html | 8 -------- diagnostics/build-plans/index.html | 8 -------- diagnostics/environment-tests/index.html | 8 -------- diagnostics/index.html | 8 -------- diagnostics/type-scanning/index.html | 8 -------- diagnostics/using-the-container-model/index.html | 8 -------- .../validating-container-configuration/index.html | 8 -------- diagnostics/whatdoihave/index.html | 8 -------- documentation/index.html | 8 -------- dynamic-interception/index.html | 8 -------- features/index.html | 8 -------- generics/index.html | 8 -------- get-structuremap/index.html | 8 -------- glossary/index.html | 8 -------- history/index.html | 8 -------- index.html | 2 -- instances/index.html | 8 -------- integrations/index.html | 8 -------- interception-and-decorators/index.html | 8 -------- interpreting-exceptions/index.html | 8 -------- object-lifecycle/configuring-lifecycles/index.html | 8 -------- object-lifecycle/custom-lifecycles/index.html | 8 -------- object-lifecycle/index.html | 8 -------- object-lifecycle/supported-lifecycles/index.html | 8 -------- quickstart/index.html | 8 -------- registration/attributes/index.html | 8 -------- .../auto-registration-and-conventions/index.html | 8 -------- .../changing-configuration-at-runtime/index.html | 8 -------- registration/clear-or-replace/index.html | 8 -------- registration/configured-instance/index.html | 8 -------- registration/constructor-selection/index.html | 8 -------- registration/existing-objects/index.html | 8 -------- registration/fallback-services/index.html | 8 -------- registration/index.html | 8 -------- registration/inline-dependencies/index.html | 10 +--------- registration/on-missing-family-policies/index.html | 8 -------- registration/policies/index.html | 8 -------- registration/registry-dsl/index.html | 8 -------- release-notes/index.html | 8 -------- .../get-a-service-by-plugin-type-and-name/index.html | 8 -------- resolving/get-a-service-by-plugintype/index.html | 8 -------- resolving/get-all-services-by-plugin-type/index.html | 8 -------- resolving/index.html | 8 -------- resolving/passing-arguments-at-runtime/index.html | 8 -------- resolving/requesting-a-concrete-type/index.html | 8 -------- .../index.html | 8 -------- .../index.html | 8 -------- roadmap/index.html | 8 -------- setter-injection/index.html | 8 -------- software-design-concepts/index.html | 8 -------- the-container/auto-wiring/index.html | 8 -------- the-container/disposing/index.html | 8 -------- .../index.html | 8 -------- .../handling-missing-named-instances/index.html | 8 -------- the-container/index.html | 8 -------- the-container/lambdas/index.html | 8 -------- the-container/lazy-resolution/index.html | 8 -------- the-container/nested-containers/index.html | 8 -------- the-container/primitives/index.html | 8 -------- the-container/profiles-and-child-containers/index.html | 8 -------- the-container/working-with-enumerable-types/index.html | 8 -------- .../working-with-the-icontext-at-build-time/index.html | 8 -------- 63 files changed, 1 insertion(+), 499 deletions(-) diff --git a/autofactory/index.html b/autofactory/index.html index 9bf0313..ae163eb 100644 --- a/autofactory/index.html +++ b/autofactory/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Best Practices
diff --git a/best-practices/index.html b/best-practices/index.html index 1bbacac..3259303 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
History
diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html index 71f9fe3..11471d4 100644 --- a/diagnostics/build-plans/index.html +++ b/diagnostics/build-plans/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Using the Container Model
diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html index 92437c6..4adc233 100644 --- a/diagnostics/environment-tests/index.html +++ b/diagnostics/environment-tests/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Build Plans
diff --git a/diagnostics/index.html b/diagnostics/index.html index bedf274..b7f1686 100644 --- a/diagnostics/index.html +++ b/diagnostics/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
WhatDoIHave()
diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html index 8185408..9555b3e 100644 --- a/diagnostics/type-scanning/index.html +++ b/diagnostics/type-scanning/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Aspect Oriented Programming with StructureMap.DynamicInterception
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index caf6df2..1225f9b 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Type Scanning Diagnostics
diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index d318dec..260d995 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Environment Tests
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html index 6e6620d..c2be817 100644 --- a/diagnostics/whatdoihave/index.html +++ b/diagnostics/whatdoihave/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Validating Container Configuration
diff --git a/documentation/index.html b/documentation/index.html index 575101e..8c986f8 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Roadmap
diff --git a/dynamic-interception/index.html b/dynamic-interception/index.html index fcb4daf..12b0d5e 100644 --- a/dynamic-interception/index.html +++ b/dynamic-interception/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Auto-factories
diff --git a/features/index.html b/features/index.html index 1ff9995..df7d84e 100644 --- a/features/index.html +++ b/features/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Software Design Concepts
diff --git a/generics/index.html b/generics/index.html index 2d9805e..2dfaa6c 100644 --- a/generics/index.html +++ b/generics/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Interception and Decorators
diff --git a/get-structuremap/index.html b/get-structuremap/index.html index e1f1baf..ae70601 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Features
diff --git a/glossary/index.html b/glossary/index.html index 1d686bb..b129b57 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Get StructureMap
diff --git a/history/index.html b/history/index.html index 6701e6a..d36313f 100644 --- a/history/index.html +++ b/history/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Release Notes
diff --git a/index.html b/index.html index 3d7abfd..e7e693c 100644 --- a/index.html +++ b/index.html @@ -54,8 +54,6 @@

StructureMap

-StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- StructureMap is the oldest, continuously used IoC/DI container for .Net dating back to its first public release and production usage all the way back in June 2004 on .Net 1.1. The current 4.* release represents 12+ years of lessons learned in the StructureMap and greater .Net community -- while also wiping away a great deal of legacy design decisions that no longer make sense today. diff --git a/instances/index.html b/instances/index.html index ebe8152..ab22c0b 100644 --- a/instances/index.html +++ b/instances/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Integrating StructureMap into Common .Net Frameworks
diff --git a/integrations/index.html b/integrations/index.html index 06112a5..2199255 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index c581a0c..8911a77 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Interpreting Exceptions
diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index 91797dd..fc594ce 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Diagnostics
diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index b603341..1c49ec6 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Custom Lifecycles
diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index cea284c..24ca822 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Generic Types
diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index ab409bc..694ac48 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Supported Lifecycles
diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 8d8219a..904343d 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Configuring Lifecycles
diff --git a/quickstart/index.html b/quickstart/index.html index f3967be..223677e 100644 --- a/quickstart/index.html +++ b/quickstart/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Glossary
diff --git a/registration/attributes/index.html b/registration/attributes/index.html index d8c4355..3b78e1e 100644 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Resolving Services
diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index f34919f..c8a7c81 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Working with IConfiguredInstance
diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index d1bb4c0..027528e 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
On Missing Family Policies
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html index bb37816..80757eb 100644 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Using Attributes for Configuration
diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index dda7f1a..5979e10 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Construction Policies
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html index 2de8d2f..7fb043c 100644 --- a/registration/constructor-selection/index.html +++ b/registration/constructor-selection/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Fallback Services
diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html index c5c698e..542e1ea 100644 --- a/registration/existing-objects/index.html +++ b/registration/existing-objects/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Replace or Clear Out Previous Registrations
diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index f9004c5..f5e1151 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Registering Existing Objects
diff --git a/registration/index.html b/registration/index.html index 5aff465..1d2dd01 100644 --- a/registration/index.html +++ b/registration/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Registry DSL
diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index bf345d1..fafd2c9 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Auto-Registration and Conventions
@@ -121,7 +113,7 @@
Constructor Parameters by Type

Now, since SimpleRule has only a single dependency on both IAction and ICondition, we can create new rules by registering new Instance's of SimpleRule with different combinations of its dependencies:

public class InlineCtorArgs : Registry { public InlineCtorArgs() { // Defining args by type For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is<Condition1>() .Ctor<IAction>().Is<Action1>() .Named("One"); // Pass the explicit values for dependencies For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is(new Condition2()) .Ctor<IAction>().Is(new Action2()) .Named("Two"); // Use Lambda construction For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().Is(() => new Condition3()) .Ctor<IAction>().Is("some crazy builder", c => c.GetInstance<Action3>()) .Named("Three"); // Rarely used, but gives you a "do any crazy thing" option // Pass in your own Instance object For<IEventRule>().Use<SimpleRule>() .Ctor<IAction>().Is(new MySpecialActionInstance()); // Inline configuration of your dependency's dependencies For<IEventRule>().Use<SimpleRule>() .Ctor<ICondition>().IsSpecial(_ => _.Type<BigCondition>().Ctor<int>().Is(100)) // or .Ctor<ICondition>().Is(new SmartInstance<BigCondition>().Ctor<int>().Is(100)); } public class BigCondition : ICondition { public BigCondition(int number) { } public bool Matches(SomeEvent @event) { throw new NotImplementedException(); } } public class MySpecialActionInstance : LambdaInstance<Action3> { public MySpecialActionInstance() : base(() => new Action3()) { } } }
-
The inline dependency configuration using the Ctor<T>().Is() syntax supports all the common StructureMap configuration options: define by type, by lambdas, by value, or if you really want to risk severe eye strain, you can use your own Instance objects and define the configuration of your dependency's dependencies.
+
The inline dependency configuration using the Ctor<T>().Is() syntax supports all the common StructureMap configuration options: define by type, by lambdas, by value, or if you really want to risk severe eye strain, you can use your own Instance objects and define the configuration of your dependency's dependencies.

Specifying the Argument Name

If for some reason you need to specify an inline constructor argument dependency, and the concrete type has more than one dependency for that type, you just need to specify the parameter name as shown in this sample:
diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index ecdb842..cd8b161 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Constructor Selection
diff --git a/registration/policies/index.html b/registration/policies/index.html index ed7bc22..8905800 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Changing Configuration at Runtime
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 636e516..6290e1c 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Inline Dependencies
diff --git a/release-notes/index.html b/release-notes/index.html index 8be4f6b..d8d3b68 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Custom Instance Types
diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html index 74c32ad..0647168 100644 --- a/resolving/get-a-service-by-plugin-type-and-name/index.html +++ b/resolving/get-a-service-by-plugin-type-and-name/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Get all Services by Plugin Type
diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html index 5a0bb07..b64e999 100644 --- a/resolving/get-a-service-by-plugintype/index.html +++ b/resolving/get-a-service-by-plugintype/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Get a Service by Plugin Type and Name
diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html index 79e6f08..0c9ec0b 100644 --- a/resolving/get-all-services-by-plugin-type/index.html +++ b/resolving/get-all-services-by-plugin-type/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Try Getting an Optional Service by Plugin Type
diff --git a/resolving/index.html b/resolving/index.html index 1ff70d2..06839df 100644 --- a/resolving/index.html +++ b/resolving/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Get a Service by PluginType
diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html index ee39ca0..da263b5 100644 --- a/resolving/passing-arguments-at-runtime/index.html +++ b/resolving/passing-arguments-at-runtime/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Auto Resolving Concrete Types
diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index 0352cd5..31cf124 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
The Container
diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html index 88c3325..06a982a 100644 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Passing Arguments at Runtime
diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html index 384beae..8f5e80d 100644 --- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html +++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Try Geting an Optional Service by Plugin Type and Name
diff --git a/roadmap/index.html b/roadmap/index.html index 1bfafc1..5e1dc60 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
A Gentle Quickstart
diff --git a/setter-injection/index.html b/setter-injection/index.html index 3c7df71..14257ec 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Registration
diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html index fdaa0fc..2d127d7 100644 --- a/software-design-concepts/index.html +++ b/software-design-concepts/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Setter Injection
diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index ad5979d..d00ffcd 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Building Objects with Lambdas
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html index a73dd4a..2cfc305 100644 --- a/the-container/disposing/index.html +++ b/the-container/disposing/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Working with Primitive Types
diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index 1a7de23..66d8ff7 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Profiles and Child Containers
diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index a1db1d9..79d6123 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Lazy Resolution
diff --git a/the-container/index.html b/the-container/index.html index 0807228..3f456db 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Auto Wiring
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 179e899..8cb764b 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Working with the IContext at Build Time
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html index 3f39e48..9c782de 100644 --- a/the-container/lazy-resolution/index.html +++ b/the-container/lazy-resolution/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
StructureMap and IDisposable
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 334443b..82059b5 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Working with Enumerable Types
diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index 2728bbc..52aa666 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Object Lifecycles
diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index 74163aa..2889383 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Nested Containers (Per Request/Transaction)
diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index b11f053..fcf6176 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Handling Missing Named Instances
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index e7a023a..49e653e 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -72,15 +72,7 @@
-
-
- - StructureMap has been sunsetted. Please see Lamar as a possible replacement.

- -
- -

Next
Registering a Single Instance Against Multiple PluginTypes

@@ -79,7 +79,7 @@

StructureMap 3.1.6

Internals and Architecture

Type Scanning Diagnostics

Build Plans

@@ -94,7 +94,120 @@

Using the Container Model

TODO(Write some content!)

Querying for Plugin Types

The WhatDoIHave() mechanism works by just iterating over the Container.Model.PluginTypes collection as shown below:


+            container.Model.PluginTypes.Where(x => x.PluginType.Assembly == Assembly.GetExecutingAssembly())
+                .Each(pluginType => Debug.WriteLine(pluginType.PluginType));
+

Working with a Plugin Type

The IPluginTypeConfiguration interface allows you to query and manipulate all the configured Instance's for a given plugin type.

See the entire IPluginTypeConfiguration interface here.

Finding the Default for a Plugin Type

To simply find out what the default concrete type would be for a requested plugin type, use one of these two methods:


+            // Finding the concrete type of the default
+            // IDevice service
+            container.Model.DefaultTypeFor<IDevice>()
+                .ShouldBe(typeof (DefaultDevice));
+
+            // Find the configuration model for the default
+            // IDevice service
+            container.Model.For<IDevice>().Default
+                .ReturnedType.ShouldBe(typeof (DefaultDevice));
+

Finding an Instance by Type and Name

Use this syntax to find information about an Instance in a given plugin type and name:


+            var redRule = container.Model.Find<Rule>("Red");
+

All Instances for a Plugin Type

This sample shows how you could iterate or query over all the registered instances for a single plugin type:


+            container.Model.For<Rule>().Instances.Each(i =>
+            {
+                Debug.WriteLine(i.Instance.Description);
+            });
+

Ejecting Services and/or Configuration

To remove and dispose previously built singleton scoped objects from a Container, use this code:


+            // ONLY ejects any built object for this Instance from the singleton
+            // cache
+            container.Model.For<IDevice>().Default.EjectObject();
+

To completely eject any singletons and permanently remove all related configuration, use this code:


+            // Removes all configurations and objects already built as singletons 
+            // related to types in the current Assembly
+            container.Model.EjectAndRemoveTypes(type => type.Assembly == Assembly.GetExecutingAssembly());
+
+            // Removes all configurations and objects already built as singletons
+            // that were registered to IDevice
+            container.Model.EjectAndRemove(typeof(IDevice));
+

Testing for Registrations

To troubleshoot or automate testing of Container configuration, you can use code like the sample below to +test for the presence of expected configurations:


+            // Is there a default instance for IDevice?
+            container.Model.HasDefaultImplementationFor<IDevice>().ShouldBeTrue();
+
+            // Are there any configured instances for IDevice?
+            container.Model.HasImplementationsFor<IDevice>().ShouldBeTrue();
+

Finding all Possible Implementors of an Interface

If our interface is this below:


+    public interface IStartable
+    {
+        bool WasStarted { get; }
+        void Start();
+    }
+

We could walk through the entire StructureMap model and find every registered instance that implements this interface, create each, and call the Start() method like in this code below:


+            var allStartables = container.Model.GetAllPossible<IStartable>();
+            allStartables.ToArray()
+                .Each(x => x.Start());
+

I've also used this mechanism in automated testing to reach out to all singleton services that may have state to clear out their data between tests.

Working with Individual Instances

You can manipulate an individual instance in several ways:


+            // First, find the model for a single Instance
+            var instance = container.Model.For<IDevice>().Default;
+
+            // build or resolve an object for this Instance cast to
+            // the type specified to the Get() method
+            instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>();
+
+            // if the instance is configured as a singleton, test
+            // if the singleton object has already been created
+            var hasSingletonBeenCreated = instance.ObjectHasBeenCreated();
+
+            if (hasSingletonBeenCreated)
+            {
+                // remove the singleton object from the cache so that
+                // StructureMap will be forced to rebuild this object
+                instance.EjectObject();
+            }
+
+            // test the lifecycle of this instance
+            instance.Lifecycle.ShouldBeOfType<SingletonLifecycle>();
+
+            // Visualize the build plan no more than 3 levels deep
+            Debug.WriteLine(instance.DescribeBuildPlan(3));
+
+            // Get at the underlying Instance model that StructureMap itself
+            // uses. Be cautious using this.
+            var rawModel = instance.Instance;
+
+

@@ -108,7 +221,7 @@

Using the Container Model

- Next: Internals and Architecture + Next: Type Scanning Diagnostics diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html index 4563510..3dc9f94 100644 --- a/diagnostics/validating-container-configuration/index.html +++ b/diagnostics/validating-container-configuration/index.html @@ -94,7 +94,34 @@

Validating Container Configuration

TODO(Write some content!)


+            container.AssertConfigurationIsValid();
+

Running this method will walk over every single registration in your Container and:

Try to create a build plan for that Instance that will flush out any problems with missing dependencies or invalid inline configuration
Try to build every single configured Instance
Call any methods on built objects decorated with the [ValidationMethod] attribute to perform environment tests. See Environment Tests for more information on this usage.

If StructureMap encounters any errors of any kind during this method, it will throw an exception summarizing all of the problems that it encountered. That output will look something like:

+StructureMap.StructureMapConfigurationException
+StructureMap Failures:  1 Build/Configuration Failures and 0 Validation Errors
+
+Profile 'DEFAULT'
+
+-----------------------------------------------------------------------------------------------------
+Build Error on Instance 'StructureMap.Testing.Diagnostics.NamedWidget'
+    for PluginType StructureMap.Testing.Diagnostics.IWidget
+
+Unable to create a build plan for concrete type StructureMap.Testing.Diagnostics.NamedWidget
+new NamedWidget(String name)
+  ┗ String name = Required primitive dependency is not explicitly defined
+
+

Standin Dependencies for Runtime Dependencies

diff --git a/documentation/index.html b/documentation/index.html index cd04860..2d6ecef 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index 6b0151e..6f8a716 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -97,6 +97,7 @@

Auto-Registration and Conventions

StructureMap has rich support for registering types by scanning assemblies. Between scanning and default conventions, configurations are often just a few lines.

Also see Type Scanning Diagnostics for help in understanding the assembly scanning behavior in your system.

Scan the Calling Assembly

One of the easiest ways to register types is by scanning the assembly your registry is placed in.

@@ -205,7 +206,7 @@

Custom Registration Conventions


     public interface IRegistrationConvention
     {
-        void Process(Type type, Registry registry);
+        void ScanTypes(TypeSet types, Registry registry);
     }

Let's say that you'd like a custom convention that just registers a concrete type against all the interfaces @@ -230,14 +231,15 @@

Custom Registration Conventions

// Custom IRegistrationConvention public class AllInterfacesConvention : IRegistrationConvention { - public void Process(Type type, Registry registry) + public void ScanTypes(TypeSet types, Registry registry) { // Only work on concrete types - if (!type.IsConcrete() || type.IsGenericType) return; - - // Register against all the interfaces implemented - // by this concrete class - type.GetInterfaces().Each(@interface => { registry.For(@interface).Use(type); }); + types.FindTypes(TypeClassification.Concretes | TypeClassification.Closed).Each(type => + { + // Register against all the interfaces implemented + // by this concrete class + type.GetInterfaces().Each(@interface => registry.For(@interface).Use(type)); + }); } } diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index a3ce2d1..46edb87 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -47,7 +47,7 @@

Join the chat at https://gitter.im/structuremap/structuremap

@@ -79,7 +79,7 @@

StructureMap 3.1.6

Setter Injection Policies

On Missing Family Policies

Inline Dependencies

@@ -141,7 +141,7 @@

Best Practices

- Next: Setter Injection Policies + Next: On Missing Family Policies diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html new file mode 100644 index 0000000..d01703b --- /dev/null +++ b/registration/configured-instance/index.html @@ -0,0 +1,156 @@ + + + + + + + + StructureMap - Configuring Instance Construction + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 3.1.6

+
+ + + +

Fallback Services

Configuring the Raw Model

+ + +

Configuring Instance Construction

+ +

TODO(Content!)

+ + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/configuring-the-raw-model/index.html b/registration/configuring-the-raw-model/index.html index 21988dc..d21c8ef 100644 --- a/registration/configuring-the-raw-model/index.html +++ b/registration/configuring-the-raw-model/index.html @@ -47,7 +47,7 @@

@@ -79,7 +79,7 @@

StructureMap 3.1.6

Fallback Services

Configuring Instance Construction

Constructor Selection

@@ -108,7 +108,7 @@

Configuring the Raw Model

- Next: Fallback Services + Next: Configuring Instance Construction diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index 300dc0b..e07c0cf 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -46,7 +46,7 @@

@@ -103,7 +103,7 @@

Fallback Services

- Previous: Configuring the Raw Model + Previous: Configuring Instance Construction diff --git a/registration/index.html b/registration/index.html index 0d77e91..d92cb9f 100644 --- a/registration/index.html +++ b/registration/index.html @@ -46,7 +46,7 @@

@@ -222,7 +222,7 @@

Registration

- Previous: Software Design Concepts + Previous: Setter Injection diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index 9500172..9c8dbc1 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -46,7 +46,7 @@

@@ -300,7 +300,7 @@

Using a Custom IFamilyPolicy" id="custom">

- Previous: Setter Injection Policies + Previous: Changing Configuration at Runtime diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 34a4173..8baaacd 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -102,7 +102,7 @@

Registry DSL

The Registry Class

On all but the smallest systems, the main unit of configuration will probably be the Registry class. Typically, you would subclass the Registry class, then -use the Fluent Interface methods exposed by the Registry class to create Container +use the fluent interface methods exposed by the Registry class to create Container configuration. Here's a sample Registry class below used to configure an instance of an IWidget interface:


@@ -117,7 +117,7 @@ The Registry Class

Including Registries

The next question is "how does my new Registry class get used?"

When you set up a Container or ObjectFactory, you need to simply direct the +

When you set up a Container, you need to simply direct the Container to use the configuration in that Registry class:


         [Test]
diff --git a/setter-injection/index.html b/setter-injection/index.html
new file mode 100644
index 0000000..a61e39c
--- /dev/null
+++ b/setter-injection/index.html
@@ -0,0 +1,274 @@
+
+
+    
+         
+        
+        
+        
+		StructureMap - Setter Injection
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Setter Injection
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 3.1.6
+		      	

+
+				
+
+		        
+
+		        	Next
Registration
+		        	Previous
Software Design Concepts
+
+		        
+		      

+		      
+		      
+		      
+			      	Setter Injection
+			      
+			      	
+
+			      	
+			      		
+
+In all cases, Setter Injection is an opt-in feature in StructureMap that has to be explicitly enabled
+    on a case by case basis.
+StructureMap can inject dependencies into public setter properties as part of its construction process using the Setter Injection form of Dependency Injection. The StructureMap team strongly recommends using constructor injection wherever possible instead of setter injection. That being said,
+there are few cases where setter injection is probably easier (inheritance hierarchies), not to mention legacy or third party tools that
+simply cannot support constructor injection cough ASP.Net cough.
+See this discussion from Martin Fowler on Constructor vs Setter Injection.
+If you are having any trouble with setter injection in your StructureMap usage, make sure you're familiar with using Build Plans
+to help in troubleshooting
+Explicit Setter Injection with [SetterProperty] Attributes
+The simplest conceptual way to force StructureMap into making public setters mandatory service dependencies by decorating setter properties with the [SetterProperty] attribute like this example:
+
+    public class Repository
+    {
+        private IDataProvider _provider;
+
+        // Adding the SetterProperty to a setter directs
+        // StructureMap to use this property when
+        // constructing a Repository instance
+        [SetterProperty]
+        public IDataProvider Provider
+        {
+            set { _provider = value; }
+        }
+
+        [SetterProperty]
+        public bool ShouldCache { get; set; }
+    }
+
+Without the [SetterProperty] attributes decorating the setters, StructureMap would ignore the Provider and ShouldCache properties when it builds up a Repository object. With the attributes, StructureMap will try to build and attach values for the two properties as part of object construction.
+If you were to look at StructureMap's "build plan" for the Repository class, you would see something like this:
++PluginType: StructureMap.Testing.DocumentationExamples.Repository
+Lifecycle: Transient
+new Repository()
+    Set IDataProvider Provider = **Default**
+    Set Boolean ShouldCache = Value: False
+
+If you intensely dislike runaway attribute usage, that's okay because there are other ways to enable setter injection in StructureMap.
+Inline Setter Configuration
+Any setter property not configured with [SetterProperty] or the setter policies in the next section can still be filled by StructureMap if an inline dependency is configured matching that setter property as shown in the example below:
+
+        public class RuleWithSetters : IEventRule
+        {
+            public ICondition Condition { get; set; }
+            public IAction Action { get; set; }
+
+            public void ProcessEvent(SomeEvent @event)
+            {
+                if (Condition.Matches(@event))
+                {
+                    Action.PerformWork(@event);
+                }
+            }
+        }
+
+        public class RuleWithSettersRegistry : Registry
+        {
+            public RuleWithSettersRegistry()
+            {
+                For<IEventRule>().Use<RuleWithSetters>()
+                    .Setter<ICondition>().Is<Condition1>()
+
+                    // or
+                    .Setter(x => x.Action).Is(new Action1())
+
+                    // or if you need to specify the name
+                    .Setter<IAction>("Action").Is<Action2>()
+
+                    // or you can configure values *after* the object
+                    // is constructed with the SetProperty method
+                    .SetProperty(x => x.Action = new Action2());
+            }
+        }
+
+
+See also:
+
+Inline Dependencies
+Configuring Instance Construction
+
+Setter Injection Policies
+Lastly, you can give StructureMap some criteria for determining which setters should be mandatory dependencies with the Registry.Policies.SetAllProperties() method during Container setup as shown in this example below:
+
+        public class ClassWithNamedProperties
+        {
+            public int Age { get; set; }
+            public string LastName { get; set; }
+            public string FirstName { get; set; }
+            public IGateway Gateway { get; set; }
+            public IService Service { get; set; }
+        }
+
+
+        [Test]
+        public void specify_setter_policy_and_construct_an_object()
+        {
+            var theService = new ColorService("red");
+
+            var container = new Container(x =>
+            {
+                x.For<IService>().Use(theService);
+                x.For<IGateway>().Use<DefaultGateway>();
+
+                x.ForConcreteType<ClassWithNamedProperties>().Configure.Setter<int>().Is(5);
+
+                x.Policies.SetAllProperties(
+                    policy => policy.WithAnyTypeFromNamespace("StructureMap.Testing.Widget3"));
+            });
+
+            var description = container.Model.For<ClassWithNamedProperties>().Default.DescribeBuildPlan();
+            Debug.WriteLine(description);
+
+            var target = container.GetInstance<ClassWithNamedProperties>();
+            target.Service.ShouldBeTheSameAs(theService);
+            target.Gateway.ShouldBeOfType<DefaultGateway>();
+        }
+
+All calls to Registry.Policies.SetAllProperties() are additive, meaning you can use as many criteria as possible for setter injection.
+
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Software Design Concepts
+
+				        
+				        
+
+				        	Next: Registration
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html
index 715ffbe..c2d584d 100644
--- a/software-design-concepts/index.html
+++ b/software-design-concepts/index.html
@@ -47,7 +47,7 @@
 
 		        
 		      	Previous
-		      	Next
+		      	Next
 		      
       
         
@@ -79,7 +79,7 @@ StructureMap 3.1.6
 
 		        
 
-		        	Next
Registration
+		        	Next
Setter Injection
 		        	Previous
Features
 
 		        
@@ -94,10 +94,44 @@ Software Design Concepts
 			      	
 			      		
 
-TODO(adapt old blog posts here)
-Dependency Injection
 Inversion of Control
+Years ago I consulted for a company that had developed a successful software engine for pricing and analyzing potential energy trades. The next step for them was to adapt their pricing engine so that it could be embedded in other software packages or even a simple spreadsheet so that analysts could quickly try out "what if" scenarios before making any kind of deal. The immediate problem this firm had was that their pricing engine was archtected such that the pricing engine business logic directly invoked their proprietary database schema and configuration files. The strategic pricing engine logic was effectively useless without all the rest of their system, so forget embedding the logic into spreadsheet logic.
+With the benefit of hindsight, if we were to build an energy trading pricing engine from scratch, we would probably opt to use the software design concept of Inversion of Control such that the actual pricing logic code would be handed all the pricing metadata it needed to perform its work instead of making the pricing logic reach out to get it. In its most general usage, Inversion of Control simply means that a component is given some sort of dependent data or service or configuration instead of that component having to "know" how to fetch or find that resource.
+An IoC container like StructureMap uses the Inversion of Control concept to simplify your internal services by freeing them from having to know how to find, build, or clean up their dependencies.
+Dependency Injection
+Dependency Injection is nothing more than pushing dependencies of an object into constructor functions or setter properties instead of that object doing everything for itself. If you are strictly using Dependency Injection to fill the dependencies of your classes, your code should have no coupling to StructureMap itself.
+
+        public interface IDatabase { }
+
+        public class DatabaseUser
+        {
+            // Using Constructor Injection
+            public DatabaseUser(IDatabase database)
+            {
+            }
+        }
+
+        public class OtherDatabaseUser
+        {
+            // Setter Injection
+            public IDatabase Database { get; set; }
+        }
+
 Service Locator
+StructureMap also fills the role of a service locator. In this usage, your code would directly access StructureMap's Container class to build or resolve services upon demand like this sample:
+
+        public class ThirdDatabaseUser
+        {
+            private IDatabase _database;
+
+            public ThirdDatabaseUser(IContainer container)
+            {
+                // This is service location
+                _database = container.GetInstance<IDatabase>();
+            }
+        }
+
+Since IoC tools like StructureMap have come onto the software scene, many developers have very badly overused the service locator pattern and many other developers have become very vocal in their distaste for service location. The StructureMap team simply recommends that you favor Dependency Injection wherever possible, but that some service location in your system where you may need more advanced building options or lazy resolution of services is probably just fine.
 
 
 			      	
@@ -111,7 +145,7 @@ Service Locator
 				        
 				        
 
-				        	Next: Registration
+				        	Next: Setter Injection



From 3ec60bb4bb68f9e6de7796db29e1aa4d116b0a0c Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Thu, 1 Oct 2015 10:18:57 -0500
Subject: [PATCH 03/55] Documentation Update

---
 setter-injection/index.html | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/setter-injection/index.html b/setter-injection/index.html
index a61e39c..170a4ca 100644
--- a/setter-injection/index.html
+++ b/setter-injection/index.html
@@ -212,6 +212,35 @@ Setter Injection Policies
         }

All calls to Registry.Policies.SetAllProperties() are additive, meaning you can use as many criteria as possible for setter injection.

Filling Setter's of an Object

You're still in luck because StructureMap has the BuildUp(object) method for just this scenario as shown in this example from the unit tests:


+        public class BuildUpTarget1
+        {
+            public IGateway Gateway { get; set; }
+            public IService Service { get; set; }
+        }
+
+        [Test]
+        public void create_a_setter_rule_and_see_it_applied_in_BuildUp()
+        {
+            
+            var theGateway = new DefaultGateway();
+            var container = new Container(x =>
+            {
+                x.For<IGateway>().Use(theGateway);
+                x.Policies.SetAllProperties(y => y.OfType<IGateway>());
+            });
+
+            var target = new BuildUpTarget1();
+            container.BuildUp(target);
+
+            target.Gateway.ShouldBeTheSameAs(theGateway);
+            target.Service.ShouldBeNull();
+        }
+

The normal rules for what setters should be filled as described above apply to BuildUp().

From 679155f105ad9b4984a68ef69904cb2de3d4871d Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Thu, 1 Oct 2015 10:23:44 -0500 Subject: [PATCH 04/55] Documentation Update --- roadmap/index.html | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/roadmap/index.html b/roadmap/index.html index 375f888..1a2c53b 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -94,18 +94,10 @@

Roadmap

StructureMap 3.0 marked a huge change in the StructureMap internals and public API's. -At this point, the StructureMap team is only focusing on bug fixes encountered by users and incremental features requested -on GitHub. Please log any suspected bugs or feature requests on StructureMap's GitHub page.

Future Plans

Nothing definite has been planned at this point, but these are some of the things that the StructureMap team is considering for the future:

We would be interested in supporting the Xamarin runtimes for Android and iPhone devices, but we need help from someone who is actually -developing on these platforms. StructureMap 3.* targets PCL compliance, so this should be easy, right? Right?
4.0 will likely target the new K runtime and possibly try to take advantage of the Roslyn compiler abilities for metaprogramming
With the closing down of the FubuMVC project, some functionality from the FubuCore library may -migrate to a future version of StructureMap.

StructureMap 3.0 marked a huge change in the StructureMap internals and public API's. 4.0 is a much smaller release that primarily improves type scanning, +diagnostics, and performance. The only breaking changes from 3 to 4 are in custom type scanning conventions.

Please log any suspected bugs or feature requests on StructureMap's GitHub page.

After 4.0 is released, the StructureMap team will finally focus on the new DNX platform and officially support a StructureMap adapter for DNX.

From 91cbf1cfdc2c3871c55c621b52f427bd36ad7fe7 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Mon, 5 Oct 2015 09:03:14 -0500 Subject: [PATCH 05/55] Documentation Update --- documentation/index.html | 2 +- registration/attributes/index.html | 155 ++++++++++ .../index.html | 12 +- .../index.html | 6 +- registration/configured-instance/index.html | 269 +++++++++++++++++- .../configuring-the-raw-model/index.html | 6 +- registration/fallback-services/index.html | 12 +- registration/inline-dependencies/index.html | 12 +- registration/policies/index.html | 155 ++++++++++ registration/registry-dsl/index.html | 6 +- setter-injection/index.html | 2 +- 11 files changed, 597 insertions(+), 40 deletions(-) create mode 100644 registration/attributes/index.html create mode 100644 registration/policies/index.html diff --git a/documentation/index.html b/documentation/index.html index 2d6ecef..a469967 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/registration/attributes/index.html b/registration/attributes/index.html new file mode 100644 index 0000000..597b31f --- /dev/null +++ b/registration/attributes/index.html @@ -0,0 +1,155 @@ + + + + + + + + StructureMap - Using Attributes for Configuration + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 3.1.6

+
+ + + +

Resolving Services

Fallback Services

+ + +

Using Attributes for Configuration

+ +

+ + + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index 6f8a716..e2ebabb 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -46,8 +46,8 @@

@@ -79,8 +79,8 @@

StructureMap 3.1.6

Inline Dependencies

Registry DSL

Working with IConfiguredInstance

Inline Dependencies

@@ -275,12 +275,12 @@

Custom Registration Conventions

diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html index 46edb87..21ebcbf 100644 --- a/registration/changing-configuration-at-runtime/index.html +++ b/registration/changing-configuration-at-runtime/index.html @@ -46,7 +46,7 @@

@@ -136,7 +136,7 @@

Best Practices

- Previous: Inline Dependencies + Previous: Construction Policies diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index d01703b..91a6839 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -5,7 +5,7 @@ - StructureMap - Configuring Instance Construction + StructureMap - Working with IConfiguredInstance @@ -46,8 +46,8 @@

@@ -62,7 +62,7 @@

@@ -79,21 +79,268 @@

StructureMap 3.1.6

Fallback Services

Configuring the Raw Model

Construction Policies

Auto-Registration and Conventions

Configuring Instance Construction

Working with IConfiguredInstance

- -

TODO(Content!)

+ +

The most common way for StructureMap to build or resolve a requested object is to build a concrete type directly by calling a +public constructor function and optionally filling values in public setter properties. For this type of object construction, +StructureMap exposes the IConfiguredInstance interface as a means of querying and modifying how a concrete type will be +created or resolved. While the Registry DSL fluent interface provides the main way of explicitly configuring concrete type creation, +the IConfiguredInstance interface is meant to support conventional registration, +configuration attributes, and construction policies.


+    /// <summary>
+    /// Represents a configured Instance object that
+    /// is built by StructureMap directly by calling 
+    /// constructor functions and property setters
+    /// </summary>
+    public interface IConfiguredInstance
+    {
+        /// <summary>
+        /// The Instance name
+        /// </summary>
+        string Name { get; set; }
+
+        /// <summary>
+        /// The actual concrete type built by this Instance
+        /// </summary>
+        Type PluggedType { get; }
+
+        /// <summary>
+        /// The explicitly configured inline dependencies that override
+        /// auto-wiring
+        /// </summary>
+        DependencyCollection Dependencies { get; }
+
+        /// <summary>
+        /// Add an interceptor to only this Instance
+        /// </summary>
+        /// <param name="interceptor"></param>
+        void AddInterceptor(IInterceptor interceptor);
+
+        /// <summary>
+        /// Set the lifecycle of only this Instance to the ILifecycle type.
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <example>
+        /// SetLifecycleTo<SingletonLifecycle>()
+        /// </example>
+        void SetLifecycleTo<T>() where T : ILifecycle, new();
+
+        /// <summary>
+        /// Set the lifecycle of only this Instance to a certain lifecycle
+        /// </summary>
+        /// <param name="lifecycle"></param>
+        void SetLifecycleTo(ILifecycle lifecycle);
+
+        /// <summary>
+        /// The current Lifecycle that will be used for this Instance
+        /// </summary>
+        ILifecycle Lifecycle { get; }
+
+        /// <summary>
+        /// Explicitly choose a constructor
+        /// </summary>
+        ConstructorInfo Constructor { get; set; }
+    }
+

Changing the Instance Lifecycle

You can override the lifecycle of a single IConfiguredInstance by calling the LifecycleIs() methods and either supplying a +type of ILifecycle or an ILifecycle object. As a quick helper, there are also extension methods for common lifecycles:


+            IConfiguredInstance instance
+                = new ConfiguredInstance(typeof(WidgetHolder));
+
+            // Use the singleton lifecycle
+            instance.Singleton();
+
+            // or supply an ILifecycle type
+            instance.SetLifecycleTo<HttpContextLifecycle>();
+
+            // or supply an ILifecycle object
+            instance.SetLifecycleTo(new Lifecycles_Samples.MyCustomLifecycle());
+
+            // or override to the default "transient" lifecycle
+            instance.DefaultLifecycle();
+

Reflecting over Constructor Parameters

To find the constructor function parameters of an IConfiguredInstance, just use this syntax (it's just .Net Reflection):


+        public class GuyWithArguments
+        {
+            public GuyWithArguments(IWidget widget, Rule rule)
+            {
+            }
+        }
+
+        [Test]
+        public void reflecting_over_constructor_args()
+        {
+            IConfiguredInstance instance = new SmartInstance<GuyWithArguments>()
+                // I'm just forcing it to assign the constructor function
+                .SelectConstructor(() => new GuyWithArguments(null, null));
+
+
+            instance.Constructor.GetParameters().Select(x => x.Name)
+                .ShouldHaveTheSameElementsAs("widget", "rule");
+        }
+

The constructor function selection process takes place as the very first step in creating a build plan and will be +available in any kind of construction policy or configuration attribute on +parameters or properties.

Reflecting over Setter Properties

There's a helper extension method off of `IConfiguredInstance' for finding all of the settable properties +that StructureMap can work with as shown below:


+        public class GuyWithProperties
+        {
+            public IWidget Widget { get; set; }
+            public Rule Rule { get; private set; }
+        }
+
+        [Test]
+        public void get_settable_properties()
+        {
+            IConfiguredInstance instance 
+                = new ConfiguredInstance(typeof(GuyWithProperties));
+
+            instance.SettableProperties()
+                .Single().Name.ShouldBe("Widget");
+        }
+

Working with Dependencies

The IConfiguredInstance.Dependencies property is a collection of Argument objects that model inline dependencies. A +single Argument can refer to a public property or the parameter in a constructor function and consists of:

Type - the dependency type that would match a property or parameter argument
Name - matches the name of a property or parameter argument
Dependency - either an object or value of the dependency type or an Instance object that can be used to build the dependency

When StructureMap determines a build plan for a concrete type, it reflects over all the +parameters in the chosen constructor function and then the settable properties looking for any explicitly configured +dependencies by searching in order for:

An exact match by dependency type and name
A partial match by dependency type only
A partial match by name only

For primitive arguments like strings or numbers, the logic is to search first by name, then by type. All searching is done in +the order that the Argument objects are registered, so do watch the order in which you add arguments. There is a method to +insert new arguments at the front of the list if you need to do any kind of overrides of previous behavior.

There are several Add() overloads on IConfiguredInstance.Dependencies to add dependencies, or you can use the two helper +methods for constructor parameters and setter properties shown in the following sections.

Add a Dependency for a Setter Property

If you already have a PropertyInfo for the concrete type (like you might in a policy or attribute usage) and you want to register an inline dependency, there is the +Dependencies.AddForProperty() method as a convenience. For the actual value of the dependency, it needs to either be an object +that can be cast to the property type or an Instance object that returns a type that can be cast to the property type.

With a value:


+        [Test]
+        public void dependency_with_setter_with_value()
+        {
+            var instance 
+                = new ConfiguredInstance(typeof(GuyWithProperties));
+            var prop = instance.PluggedType.GetProperty("Widget");
+
+            var myWidget = new ColorWidget("red");
+            instance.Dependencies.AddForProperty(prop, myWidget);
+
+            var container = new Container();
+
+            container.GetInstance<GuyWithProperties>(instance)
+                .Widget.ShouldBeTheSameAs(myWidget);
+        }
+

With an Instance for the dependency value:


+        [Test]
+        public void dependency_with_setter_with_instance()
+        {
+            var instance
+                = new ConfiguredInstance(typeof(GuyWithProperties));
+            var prop = instance.PluggedType.GetProperty("Widget");
+
+            var dependency = new SmartInstance<AWidget>();
+            instance.Dependencies.AddForProperty(prop, dependency);
+
+            var container = new Container();
+
+            container.GetInstance<GuyWithProperties>(instance)
+                .Widget.ShouldBeOfType<AWidget>();
+        }
+

Add a Dependency for a Constructor Parameter

Likewise, you can add a dependency for a specific constructor parameter as either the actual value or an Instance object with the AddForConstructorParameter helper method:


+        public class GuyWithDatabaseConnection
+        {
+            public string ConnectionString { get; set; }
+
+            public GuyWithDatabaseConnection(string connectionString)
+            {
+                ConnectionString = connectionString;
+            }
+        }
+
+        [Test]
+        public void specify_dependency_by_constructor_parameter()
+        {
+            var instance = ConstructorInstance
+                .For<GuyWithDatabaseConnection>();
+
+            var parameter = instance.Constructor.GetParameters().Single();
+            parameter.Name.ShouldBe("connectionString");
+
+            var connString = 
+                "I haven't used sql server in years and I don't remember what connection strings look like";
+
+            instance.Dependencies.AddForConstructorParameter(parameter, connString);
+
+
+            var guy = new Container().GetInstance<GuyWithDatabaseConnection>(instance);
+
+            guy.ConnectionString.ShouldBe(connString);
+        }
+

Adding Interceptors

You can add interceptors directly to a single IConfiguredInstance with code like this:


+
+        public class SimpleWidget
+        {
+            public bool WasIntercepted = false;
+
+            public void Intercept()
+            {
+                WasIntercepted = true;
+            }
+        }
+
+        [Test]
+        public void add_interceptor()
+        {
+            var interceptor = 
+                new ActivatorInterceptor<SimpleWidget>(w => w.Intercept());
+            var instance = new SmartInstance<SimpleWidget>();
+
+            instance.AddInterceptor(interceptor);
+
+            new Container().GetInstance<SimpleWidget>(instance)
+                .WasIntercepted.ShouldBeTrue();
+        }
+

See Interception and Decorators for more information.

@@ -102,12 +349,12 @@

Configuring Instance Construction

diff --git a/registration/configuring-the-raw-model/index.html b/registration/configuring-the-raw-model/index.html index d21c8ef..21988dc 100644 --- a/registration/configuring-the-raw-model/index.html +++ b/registration/configuring-the-raw-model/index.html @@ -47,7 +47,7 @@

diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html index e07c0cf..f187362 100644 --- a/registration/fallback-services/index.html +++ b/registration/fallback-services/index.html @@ -46,8 +46,8 @@

@@ -79,8 +79,8 @@

StructureMap 3.1.6

Resolving Services

Configuring Instance Construction

Using Attributes for Configuration

Configuring the Raw Model

@@ -103,12 +103,12 @@

Fallback Services

diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html index 4f493c1..c557783 100644 --- a/registration/inline-dependencies/index.html +++ b/registration/inline-dependencies/index.html @@ -46,8 +46,8 @@

@@ -79,8 +79,8 @@

StructureMap 3.1.6

Changing Configuration at Runtime

Auto-Registration and Conventions

Registry DSL

@@ -468,12 +468,12 @@

Programmatic Configuration outside of the Registry DSL

diff --git a/registration/policies/index.html b/registration/policies/index.html new file mode 100644 index 0000000..1d826b2 --- /dev/null +++ b/registration/policies/index.html @@ -0,0 +1,155 @@ + + + + + + + + StructureMap - Construction Policies + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 3.1.6

+
+ + + +

Changing Configuration at Runtime

Working with IConfiguredInstance

+ + +

Construction Policies

+ +

+ + + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html index 8baaacd..4762ad2 100644 --- a/registration/registry-dsl/index.html +++ b/registration/registry-dsl/index.html @@ -47,7 +47,7 @@

@@ -79,7 +79,7 @@

StructureMap 3.1.6

Auto-Registration and Conventions

Inline Dependencies

Registration

@@ -181,7 +181,7 @@

Named Instances

- Next: Auto-Registration and Conventions + Next: Inline Dependencies diff --git a/setter-injection/index.html b/setter-injection/index.html index 170a4ca..2add00f 100644 --- a/setter-injection/index.html +++ b/setter-injection/index.html @@ -172,7 +172,7 @@

Inline Setter Configuration

Setter Injection Policies

From 89c9a463ce406b292b8b238eff7f8df5101a0f14 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Mon, 5 Oct 2015 12:13:15 -0500 Subject: [PATCH 06/55] Documentation Update --- registration/policies/index.html | 311 +++++++++++++++++++++++++++++++ 1 file changed, 311 insertions(+) diff --git a/registration/policies/index.html b/registration/policies/index.html index 1d826b2..ae2e1d2 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -93,6 +93,317 @@

Construction Policies

The features described in this page were all introduced in StructureMap 4.0.

StructureMap has long supported conventional policies for registration based on type scanning +and 3.0 introduced cleaner mechanisms for interception policies. +The 4.0 release extends StructureMap's support for conventional build policies with a new mechanism for altering +how object instances are built based on user created meta-conventions using the IInstancePolicy shown below:


+    /// <summary>
+    /// Custom policy on Instance construction that is evaluated
+    /// as part of creating a "build plan"
+    /// </summary>
+    public interface IInstancePolicy
+    {
+        /// <summary>
+        /// Apply any conventional changes to the configuration
+        /// of a single Instance
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <param name="instance"></param>
+        void Apply(Type pluginType, Instance instance);
+    }
+

These policies are registered as part of the registry dsl with +the Policies.Add() method:


+            var container = new Container(_ =>
+            {
+                _.Policies.Add<MyCustomPolicy>();
+                // or
+                _.Policies.Add(new MyCustomPolicy());
+            });
+

The IInstancePolicy mechanism probably works differently than other IoC containers in that the policy +is applied to the container's underlying configuration model instead of at runtime. Internally, StructureMap lazily creates +a "build plan" for each configured Instance at the first time +that that Instance is built or resolved. As part of creating that build plan, StructureMap runs +all the registered IInstancePolicy objects against the Instance in question to capture any +potential changes before "baking" the build plan into a .Net Expression that is then compiled into a Func +for actual construction.

The Instance objects will give you access to the types being created, the configured name of the Instance (if any), +the ability to add interceptors and to modify the lifecycle. If you wish to add inline dependencies to +Instances that are built by calling constructor function and setter properties, you may find it easier +to use the ConfiguredInstancePolicy base class as a convenience:


+    public abstract class ConfiguredInstancePolicy : IInstancePolicy
+    {
+        public void Apply(Type pluginType, Instance instance)
+        {
+            var configured = instance as IConfiguredInstance;
+            if (configured != null)
+            {
+                apply(pluginType, configured);
+            }
+        }
+
+        // This method is called against any Instance that implements 
+        // the IConfiguredInstance interface
+        protected abstract void apply(Type pluginType, IConfiguredInstance instance);
+    }
+

For more information, see:

A Quick Note on Using Policies Sanely

Example 1: Constructor arguments

So let me say upfront that I don't like this approach, but other folks have asked for this ability +over the years. Say that you have some legacy code where many concrete classes have a constructor argument +called "connectionString" that needs to be the connection string to the application database like these classes:


+        public class BigService
+        {
+            public BigService(IDatabase green)
+            {
+                DB = green;
+            }
+
+            public IDatabase DB { get; set; }
+        }
+
+        public class ImportantService
+        {
+            public ImportantService(IDatabase red)
+            {
+                DB = red;
+            }
+
+            public IDatabase DB { get; set; }
+        }
+
+        public class DoubleDatabaseUser
+        {
+            public DoubleDatabaseUser(IDatabase red, IDatabase green)
+            {
+                Red = red;
+                Green = green;
+            }
+
+            // Watch out for potential conflicts between setters
+            // and ctor params. The easiest thing is to just make
+            // setters private
+            public IDatabase Green { get; private set; }
+            public IDatabase Red { get; private set; }
+        }
+

Instead +of explicitly configuring every single concrete class in StructureMap with that inline constructor argument, +we can make a policy to do that in one place:


+        public class ConnectionStringPolicy : ConfiguredInstancePolicy
+        {
+            protected override void apply(Type pluginType, IConfiguredInstance instance)
+            {
+                var parameter = instance.Constructor.GetParameters().FirstOrDefault(x => x.Name == "connectionString");
+                if (parameter != null)
+                {
+                    var connectionString = findConnectionStringFromConfiguration();
+                    instance.Dependencies.AddForConstructorParameter(parameter, connectionString);
+                }
+            }
+
+            // find the connection string from whatever configuration
+            // strategy your application uses
+            private string findConnectionStringFromConfiguration()
+            {
+                return "the connection string";
+            }
+        }
+

Now, let's use that policy against the types that need "connectionString" and see what happens:


+        [Test]
+        public void use_the_connection_string_policy()
+        {
+            var container = new Container(_ =>
+            {
+                _.Policies.Add<ConnectionStringPolicy>();
+            });
+
+            container.GetInstance<DatabaseUser>()
+                .ConnectionString.ShouldBe("the connection string");
+
+            container.GetInstance<ConnectedThing>()
+                .ConnectionString.ShouldBe("the connection string");
+        }
+

Years ago StructureMap was knocked by an "IoC expert" for not having this functionality. I said at the +time -- and still would -- that I would strongly recommend that you simply don't directly +open database connections in more than one or a very few spots in your code anyway. If I did +need to configure a database connection string in multiple concrete classes, I prefer strong typed configuration.

Example 2: Connecting to Databases based on Parameter Name

From another common user request over the years, let's say that your application needs to connect to +multiple databases, but your data access service in both cases is an interface called IDatabase, and +that's all the consumers of any database should ever need to know.

To make this concrete, let's say that our data access is all behind an interface and concrete class pair named +Database/IDatabase like so:


+        public interface IDatabase { }
+
+        public class Database : IDatabase
+        {
+            public string ConnectionString { get; set; }
+
+            public Database(string connectionString)
+            {
+                ConnectionString = connectionString;
+            }
+
+            public override string ToString()
+            {
+                return string.Format("ConnectionString: {0}", ConnectionString);
+            }
+        }
+

For a registration policy, let's say that the parameter name of an IDatabase dependency +in a constructor function should match an identifier of one of the registered IDatabase services. +That policy would be:


+        public class InjectDatabaseByName : ConfiguredInstancePolicy
+        {
+            protected override void apply(Type pluginType, IConfiguredInstance instance)
+            {
+                instance.Constructor.GetParameters()
+                    .Where(x => x.ParameterType == typeof (IDatabase))
+                    .Each(param =>
+                    {
+                        // Using ReferencedInstance here tells StructureMap
+                        // to "use the IDatabase by this name"
+                        var db = new ReferencedInstance(param.Name);
+                        instance.Dependencies.AddForConstructorParameter(param, db);
+                    });
+            }
+        }
+

And because I'm generally pretty boring about picking test data names, let's say that two of +our databases are named "red" and "green" with this container registration below:


+            var container = new Container(_ =>
+            {
+                _.For<IDatabase>().Add<Database>().Named("red")
+                    .Ctor<string>("connectionString").Is("*red*");
+
+                _.For<IDatabase>().Add<Database>().Named("green")
+                    .Ctor<string>("connectionString").Is("*green*");
+                
+                _.Policies.Add<InjectDatabaseByName>();
+            });
+

For more context, the classes that use IDatabase would need to have constructor functions like +these below:


+        public class BigService
+        {
+            public BigService(IDatabase green)
+            {
+                DB = green;
+            }
+
+            public IDatabase DB { get; set; }
+        }
+
+        public class ImportantService
+        {
+            public ImportantService(IDatabase red)
+            {
+                DB = red;
+            }
+
+            public IDatabase DB { get; set; }
+        }
+
+        public class DoubleDatabaseUser
+        {
+            public DoubleDatabaseUser(IDatabase red, IDatabase green)
+            {
+                Red = red;
+                Green = green;
+            }
+
+            // Watch out for potential conflicts between setters
+            // and ctor params. The easiest thing is to just make
+            // setters private
+            public IDatabase Green { get; private set; }
+            public IDatabase Red { get; private set; }
+        }
+

Finally, we can exercise our new policy and see it in action:


+            // ImportantService should get the "red" database
+            container.GetInstance<ImportantService>()
+                .DB.As<Database>().ConnectionString.ShouldBe("*red*");
+
+            // BigService should get the "green" database
+            container.GetInstance<BigService>()
+                .DB.As<Database>().ConnectionString.ShouldBe("*green*");
+
+            // DoubleDatabaseUser gets both
+            var user = container.GetInstance<DoubleDatabaseUser>();
+
+            user.Green.As<Database>().ConnectionString.ShouldBe("*green*");
+            user.Red.As<Database>().ConnectionString.ShouldBe("*red*");
+

How I prefer to do this - my strong preference would be to use separate interfaces for the different +databases even if that type is just an empty type marker that implements the same base. +I feel like using separate interfaces makes the code easier to trace and understand than trying +to make StructureMap vary dependencies based on naming conventions or what namespace a concrete type +happens to be in. At least now though, you have the choice of my way or using policies based on +naming conventions.

Example 3: Make objects singletons based on type name

Unlike the top two examples, this is taken from a strategy that I used in FubuMVC +for its service registration. In that case, we wanted any concrete type whose name ended with +"Cache" to be a singleton in the container registration. With the new IInstancePolicy feature in StructureMap 4, +we could create a new policy class like so:


+        public class CacheIsSingleton : IInstancePolicy
+        {
+            public void Apply(Type pluginType, Instance instance)
+            {
+                if (instance.ReturnedType.Name.EndsWith("Cache"))
+                {
+                    instance.SetLifecycleTo<SingletonLifecycle>();
+                }
+            }
+        }
+

Now, let's say that we have an interface named IWidgets and a single implementation called WidgetCache that +should track our widgets in the application. Using our new policy, we should see WidgetCache being +made a singleton:


+        [Test]
+        public void set_cache_to_singleton()
+        {
+            var container = new Container(_ =>
+            {
+                _.Policies.Add<CacheIsSingleton>();
+
+                _.For<IWidgets>().Use<WidgetCache>();
+            });
+
+            // The policy is applied *only* at the time
+            // that StructureMap creates a "build plan"
+            container.GetInstance<IWidgets>()
+                .ShouldBeTheSameAs(container.GetInstance<IWidgets>());
+
+            // Now that the policy has executed, we 
+            // can verify that WidgetCache is a singleton
+            container.Model.For<IWidgets>().Default
+                .Lifecycle.ShouldBeOfType<SingletonLifecycle>();
+        }
+

From 58650f649eeaa774a624a8aeea2312904ca2e25e Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Mon, 5 Oct 2015 14:25:54 -0500 Subject: [PATCH 07/55] Documentation Update --- registration/policies/index.html | 34 +++++++++----------------------- 1 file changed, 9 insertions(+), 25 deletions(-) diff --git a/registration/policies/index.html b/registration/policies/index.html index ae2e1d2..d0e8907 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -158,45 +158,29 @@

Construction Policies

Working with IConfiguredInstance

Object Lifecycles

A Quick Note on Using Policies Sanely

Example 1: Constructor arguments


-        public class BigService
+        public class DatabaseUser
         {
-            public BigService(IDatabase green)
-            {
-                DB = green;
-            }
-
-            public IDatabase DB { get; set; }
-        }
+            public string ConnectionString { get; set; }
 
-        public class ImportantService
-        {
-            public ImportantService(IDatabase red)
+            public DatabaseUser(string connectionString)
             {
-                DB = red;
+                ConnectionString = connectionString;
             }
-
-            public IDatabase DB { get; set; }
         }
 
-        public class DoubleDatabaseUser
+        public class ConnectedThing
         {
-            public DoubleDatabaseUser(IDatabase red, IDatabase green)
+            public string ConnectionString { get; set; }
+
+            public ConnectedThing(string connectionString)
             {
-                Red = red;
-                Green = green;
+                ConnectionString = connectionString;
             }
-
-            // Watch out for potential conflicts between setters
-            // and ctor params. The easiest thing is to just make
-            // setters private
-            public IDatabase Green { get; private set; }
-            public IDatabase Red { get; private set; }
         }

Instead From 3c40c8d6c6fbce67650f61046dc8f9481e299c74 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Tue, 6 Oct 2015 09:49:02 -0500 Subject: [PATCH 08/55] Documentation Update --- documentation/index.html | 2 +- generics/index.html | 601 ++++++++++++++++++ interception-and-decorators/index.html | 6 +- object-lifecycle/custom-lifecycles/index.html | 6 +- .../on-missing-family-policies/index.html | 2 +- the-container/index.html | 2 +- the-container/nested-containers/index.html | 6 +- .../working-with-enumerable-types/index.html | 6 +- 8 files changed, 616 insertions(+), 15 deletions(-) create mode 100644 generics/index.html diff --git a/documentation/index.html b/documentation/index.html index a469967..505a47b 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/generics/index.html b/generics/index.html new file mode 100644 index 0000000..d289fe6 --- /dev/null +++ b/generics/index.html @@ -0,0 +1,601 @@ + + + + + + + + StructureMap - Generic Types + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 3.1.6

+
+ + + +

Interception and Decorators

Object Lifecycles

+ + +

Generic Types

+ +

StructureMap comes with some power abilities to exploit open generic types in .Net for extensibility +and flexible handling within your system.

Example 1: Visualizing an Activity Log

I worked years ago on a system that could be used to record and resolve customer support problems. Since it was very workflow heavy in its logic, +we tracked user and system activity as an event stream of small objects that reflected all the different actions or state changes +that could happen to an issue. To render and visualize the activity log to HTML, we used many of the open generic type capabilities shown in +this topic to find and apply the correct HTML rendering strategy for each type of log object in an activity stream.

Given a log object, we wanted to look up the right visualizer strategy to render that type of log object to html on the server side.

To start, we had an interface like this one that we were going to use to get the HTML for each log object:


+    public interface ILogVisualizer
+    {
+        // If we already know what the type of log we have
+        string ToHtml<TLog>(TLog log);
+
+        // If we only know that we have a log object
+        string ToHtml(object log);
+    }
+

So for an example, if we already knew that we had an IssueCreated object, we should be able to use StructureMap like this:


+            // Just setting up a Container and ILogVisualizer
+            var container = Container.For<VisualizationRegistry>();
+            var visualizer = container.GetInstance<ILogVisualizer>();
+
+            // If I have an IssueCreated lob object...
+            var created = new IssueCreated();
+
+            // I can get the html representation:
+            var html = visualizer.ToHtml(created);
+

If we had an array of log objects, but we do not already know the specific types, we can still use the more generic ToHtml(object) method like this:


+            var logs = new object[]
+            {
+                new IssueCreated(), 
+                new TaskAssigned(), 
+                new Comment(), 
+                new IssueResolved()
+            };
+
+            // SAMPLE: using-visualizer-knowning-the-type   
+            // Just setting up a Container and ILogVisualizer
+            var container = Container.For<VisualizationRegistry>();
+            var visualizer = container.GetInstance<ILogVisualizer>();
+
+            var items = logs.Select(visualizer.ToHtml);
+            var html = string.Join("<hr />", items);
+

The next step is to create a way to identify the visualization strategy for a single type of log object. We certainly could have done this +with a giant switch statement, but we wanted some extensibility for new types of activity log objects and even customer specific log types +that would never, ever be in the main codebase. We settled on an interface like the one shown below that would be responsible for +rendering a particular type of log object ("T" in the type):


+    public interface IVisualizer<TLog>
+    {
+        string ToHtml(TLog log);
+    }
+

Inside of the concrete implementation of ILogVisualizer we need to be able to pull out and use the correct IVisualizer<T> strategy for a log type. We of course +used a StructureMap Container to do the resolution and lookup, so now we also need to be able to register all the log visualization strategies in some easy way. +On top of that, many of the log types were simple and could just as easily be rendered with a simple html strategy like this class:


+    public class DefaultVisualizer<TLog> : IVisualizer<TLog>
+    {
+        public string ToHtml(TLog log)
+        {
+            return string.Format("<div>{0}</div>", log);
+        }
+    }
+

Inside of our StructureMap usage, if we don't have a specific visualizer for a given log type, we'd just like to fallback to the default visualizer and proceed.

Alright, now that we have a real world problem, let's proceed to the mechanics of the solution.

Registering Open Generic Types

Let's say to begin with all we want to do is to always use the DefaultVisualizer for each log type. We can do that with code like this below:


+        [Test]
+        public void register_open_generic_type()
+        {
+            var container = new Container(_ =>
+            {
+                _.For(typeof (IVisualizer<>)).Use(typeof (DefaultVisualizer<>));
+            });
+
+            
+            Debug.WriteLine(container.WhatDoIHave(@namespace:"StructureMap.Testing.Acceptance.Visualization"));
+            
+
+            container.GetInstance<IVisualizer<IssueCreated>>()
+                .ShouldBeOfType<DefaultVisualizer<IssueCreated>>();
+
+            Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));
+            
+
+
+            container.GetInstance<IVisualizer<IssueResolved>>()
+                .ShouldBeOfType<DefaultVisualizer<IssueResolved>>();
+        }
+

With the configuration above, there are no specific registrations for IVisualizer<IssueCreated>. At the first request for that +interface, StructureMap will run through its "missing family policies", one of which is +to try to find registrations for an open generic type that could be closed to make a valid registration for the requested type. In the case above, +StructureMap sees that it has registrations for the open generic type IVisualizer<T> that could be used to create registrations for the +closed type IVisualizer<IssueCreated>.

Using the WhatDoIHave() diagnostics, the original state of the container for the visualization namespace is:

+===========================================================================================================================
+PluginType            Namespace                                         Lifecycle     Description                 Name     
+---------------------------------------------------------------------------------------------------------------------------
+IVisualizer<TLog>     StructureMap.Testing.Acceptance.Visualization     Transient     DefaultVisualizer<TLog>     (Default)
+===========================================================================================================================
+

After making a request for IVisualizer<IssueCreated>, the new state is:

+====================================================================================================================================================================================
+PluginType                    Namespace                                         Lifecycle     Description                                                                  Name     
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+IVisualizer<IssueCreated>     StructureMap.Testing.Acceptance.Visualization     Transient     DefaultVisualizer<IssueCreated> ('548b4256-a7aa-46a3-8072-bd8ef0c5c430')     (Default)
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+IVisualizer<TLog>             StructureMap.Testing.Acceptance.Visualization     Transient     DefaultVisualizer<TLog>                                                      (Default)
+====================================================================================================================================================================================
+

Generic Registrations and Default Fallbacks

A powerful feature of generic type support in StructureMap is the ability to register specific handlers for some types, but allow +users to register a "fallback" registration otherwise. In the case of the visualization, some types of log objects may justify some +special HTML rendering while others can happily be rendered with the default visualization strategy. This behavior is demonstrated by +the following code sample:


+        [Test]
+        public void generic_defaults()
+        {
+            var container = new Container(_ =>
+            {
+                // The default visualizer just like we did above
+                _.For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));
+
+                // Register a specific visualizer for IssueCreated
+                _.For<IVisualizer<IssueCreated>>().Use<IssueCreatedVisualizer>();
+            });
+
+
+            // We have a specific visualizer for IssueCreated
+            container.GetInstance<IVisualizer<IssueCreated>>()
+                .ShouldBeOfType<IssueCreatedVisualizer>();
+
+            // We do not have any special visualizer for TaskAssigned,
+            // so fall back to the DefaultVisualizer<T>
+            container.GetInstance<IVisualizer<TaskAssigned>>()
+                .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>();
+        }
+

Connecting Generic Implementations with Type Scanning

It's generally harmful in software projects to have a single code file that has to be frequently edited to for unrelated changes, + and StructureMap Registry classes that explicitly configure services can easily fall into that category. Using type scanning registration can help + teams avoid that problem altogether by eliminating the need to make any explict registrations as new providers are added to the codebase.

For this example, I have two special visualizers for the IssueCreated and IssueResolved log types:


+    public class IssueCreatedVisualizer : IVisualizer<IssueCreated>
+    {
+        public string ToHtml(IssueCreated log)
+        {
+            return "special html for an issue being created";
+        }
+    }
+
+    public class IssueResolvedVisualizer : IVisualizer<IssueResolved>
+    {
+        public string ToHtml(IssueResolved log)
+        {
+            return "special html for issue resolved";
+        }
+    }
+

In the real project that inspired this example, we had many, many more types of log visualizer strategies and it +could have easily been very tedious to manually register all the different little IVisualizer<T> strategy types in a Registry class by hand. +Fortunately, part of StructureMap's type scanning support is the ConnectImplementationsToTypesClosing() +auto-registration mechanism via generic templates for exactly this kind of scenario.

In the sample below, I've set up a type scanning operation that will register any concrete type in the Assembly that contains the VisualizationRegistry +that closes IVisualizer<T> against the proper interface:


+    public class VisualizationRegistry : Registry
+    {
+        public VisualizationRegistry()
+        {
+            // The main ILogVisualizer service
+            For<ILogVisualizer>().Use<LogVisualizer>();
+
+            // A default, fallback visualizer
+            For(typeof(IVisualizer<>)).Use(typeof(DefaultVisualizer<>));
+
+            // Auto-register all concrete types that "close"
+            // IVisualizer<TLog>
+            Scan(x =>
+            {
+                x.TheCallingAssembly();
+                x.ConnectImplementationsToTypesClosing(typeof(IVisualizer<>));
+            });
+
+        }
+    }
+

If we create a Container based on the configuration above, we can see that the type scanning operation picks up the specific visualizers for +IssueCreated and IssueResolved as shown in the diagnostic view below:

+==================================================================================================================================================================================
+PluginType                     Namespace                                         Lifecycle     Description                                                               Name     
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+ILogVisualizer                 StructureMap.Testing.Acceptance.Visualization     Transient     StructureMap.Testing.Acceptance.Visualization.LogVisualizer               (Default)
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+IVisualizer<IssueResolved>     StructureMap.Testing.Acceptance.Visualization     Transient     StructureMap.Testing.Acceptance.Visualization.IssueResolvedVisualizer     (Default)
+                                                                                 Transient     DefaultVisualizer<IssueResolved>                                                   
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+IVisualizer<IssueCreated>      StructureMap.Testing.Acceptance.Visualization     Transient     StructureMap.Testing.Acceptance.Visualization.IssueCreatedVisualizer      (Default)
+                                                                                 Transient     DefaultVisualizer<IssueCreated>                                                    
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+IVisualizer<TLog>              StructureMap.Testing.Acceptance.Visualization     Transient     DefaultVisualizer<TLog>                                                   (Default)
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+IVisualizer<TLog>              StructureMap.Testing.Acceptance.Visualization     Transient     DefaultVisualizer<TLog>                                                   (Default)
+==================================================================================================================================================================================
+

The following sample shows the VisualizationRegistry in action to combine the type scanning registration plus the default fallback behavior for +log types that do not have any special visualization logic:


+        [Test]
+        public void visualization_registry()
+        {
+            var container = Container.For<VisualizationRegistry>();
+
+            Debug.WriteLine(container.WhatDoIHave(@namespace: "StructureMap.Testing.Acceptance.Visualization"));
+
+            container.GetInstance<IVisualizer<IssueCreated>>()
+                .ShouldBeOfType<IssueCreatedVisualizer>();
+
+            container.GetInstance<IVisualizer<IssueResolved>>()
+                .ShouldBeOfType<IssueResolvedVisualizer>();
+
+            // We have no special registration for TaskAssigned,
+            // so fallback to the default visualizer
+            container.GetInstance<IVisualizer<TaskAssigned>>()
+                .ShouldBeOfType<DefaultVisualizer<TaskAssigned>>();
+        }
+

Building Closed Types with ForGenericType() and ForObject()

Working with generic types and the common IHandler<T> pattern can be a little bit tricky if all you have is an object that is declared as an object. Fortunately, +StructureMap has a couple helper methods and mechanisms to help you bridge the gap between DoSomething(object something) and DoSomething<T>(T something).

If you remember the full ILogVisualizer interface from above:


+    public interface ILogVisualizer
+    {
+        // If we already know what the type of log we have
+        string ToHtml<TLog>(TLog log);
+
+        // If we only know that we have a log object
+        string ToHtml(object log);
+    }
+

The method ToHtml(object log) somehow needs to be able to find the right IVisualizer<T> and execute it to get the HTML representation for a log object. +The StructureMap IContainer provides two different methods called ForObject() and ForGenericType() for exactly this case, as shown below in a possible implementation +of ILogVisualizer:


+    public class LogVisualizer : ILogVisualizer
+    {
+        private readonly IContainer _container;
+
+        // Take in the IContainer directly so that
+        // yes, you can use it as a service locator
+        public LogVisualizer(IContainer container)
+        {
+            _container = container;
+        }
+
+        // It's easy if you already know what the log
+        // type is
+        public string ToHtml<TLog>(TLog log)
+        {
+            return _container.GetInstance<IVisualizer<TLog>>()
+                .ToHtml(log);
+        }
+
+        public string ToHtml(object log)
+        {
+            // The ForObject() method uses the 
+            // log.GetType() as the parameter to the open
+            // type Writer<T>, and then resolves that
+            // closed type from the container and
+            // casts it to IWriter for you
+            return _container.ForObject(log)
+                .GetClosedTypeOf(typeof (Writer<>))
+                .As<IWriter>()
+                .Write(log);
+        }
+
+        public string ToHtml2(object log)
+        {
+            // The ForGenericType() method is again creating
+            // a closed type of Writer<T> from the Container
+            // and casting it to IWriter
+            return _container.ForGenericType(typeof (Writer<>))
+                .WithParameters(log.GetType())
+                .GetInstanceAs<IWriter>()
+                .Write(log);
+        }
+
+        // The IWriter and Writer<T> class below are
+        // adapters to go from "object" to <T>() signatures
+        public interface IWriter
+        {
+            string Write(object log);
+        }
+
+        public class Writer<T> : IWriter
+        {
+            private readonly IVisualizer<T> _visualizer;
+
+            public Writer(IVisualizer<T> visualizer)
+            {
+                _visualizer = visualizer;
+            }
+
+            public string Write(object log)
+            {
+                return _visualizer.ToHtml((T) log);
+            }
+        }
+    }
+

The two methods are almost identical in result with some slight differences:

ForObject(object subject) can only work with open types that have only one generic type parameter, and it will pass the argument subject to the underlying Container as an explicit argument so that you can inject that subject object into the object graph being created.
ForGenericType(Type openType) is a little clumsier to use, but can handle any number of generic type parameters

Example #2: Generic Instance Builder

Say that you have some sort of persistence tooling that you primarily interact with through an interface like this one below, where TDocument and TQuery are classes in +your persistent domain:


+    public interface IRepository<TDocument, TQuery>
+    {
+
+    }
+

Great, StructureMap handles generic types just fine, so you can just register the various closed types and off you go. Except you can't because the way that your +persistence tooling works requires you to create the IRepository<,> objects with a static builder class like this one below:


+    public static class RepositoryBuilder
+    {
+        public static IRepository<TDocument, TQuery> Build<TDocument, TQuery>()
+        {
+            return new Repository<TDocument, TQuery>();
+        }
+    }
+

StructureMap has an admittedly non-obvious way to handle this situation by creating a new subclass of Instance that will "know" how to create the real Instance for a closed +type of IRepository<,>.

First off, let's create a new Instance type that knows how to build a specific type of IRepository<,> by subclassing the LambdaInstance type and providing a Func to +build our repository type with the static RepositoryBuilder class:


+    public class RepositoryInstance<TDocument, TQuery> : LambdaInstance<IRepository<TDocument, TQuery>>
+    {
+        public RepositoryInstance() : base(() => RepositoryBuilder.Build<TDocument, TQuery>())
+        {
+        }
+
+        // This is purely to make the diagnostic views prettier
+        public override string Description
+        {
+            get
+            {
+                return "RepositoryBuilder.Build<{0}, {1}>()"
+                    .ToFormat(typeof(TDocument).Name, typeof(TQuery).Name);
+            }
+        }
+    }
+


+            var container = new Container(_ =>
+            {
+                _.For<IRepository<string, int>>().UseInstance(new RepositoryInstance<string, int>());
+
+                // or skip the custom Instance with:
+
+                _.For<IRepository<string, int>>().Use(() => RepositoryBuilder.Build<string, int>());
+            });
+

To handle the problem in a more generic way, we can create a second custom subclass of Instance for the open type IRepository<,> that will help StructureMap understand how +to build the specific closed types of IRepository<,> at runtime:


+    public class RepositoryInstanceFactory : Instance
+    {
+        // This is the key part here. This method is called by
+        // StructureMap to "find" an Instance for a closed
+        // type of IRepository<,>
+        public override Instance CloseType(Type[] types)
+        {
+            // StructureMap will cache the object built out of this,
+            // so the expensive Reflection hit only happens
+            // once
+            var instanceType = typeof (RepositoryInstance<,>).MakeGenericType(types);
+            return Activator.CreateInstance(instanceType).As<Instance>();
+        }
+
+        // Don't worry about this one, never gets called
+        public override IDependencySource ToDependencySource(Type pluginType)
+        {
+            throw new NotSupportedException();
+        }
+
+        public override string Description
+        {
+            get { return "Build Repository<T, T1>() with RepositoryBuilder"; }
+        }
+
+        public override Type ReturnedType
+        {
+            get { return typeof (Repository<,>); }
+        }
+    }
+

Here's a unit test that exercises and demonstrates this functionality from end to end:


+        [Test]
+        public void show_the_workaround_for_generic_builders()
+        {
+            var container = new Container(_ =>
+            {
+                _.For(typeof (IRepository<,>)).Use(new RepositoryInstanceFactory());
+            });
+
+            container.GetInstance<IRepository<string, int>>()
+                .ShouldBeOfType<Repository<string, int>>();
+
+            Debug.WriteLine(container.WhatDoIHave(assembly:Assembly.GetExecutingAssembly()));
+        }
+

After requesting IRepository<string, int> for the first time, the container configuration from Container.WhatDoIHave() is:

+===================================================================================================================================================
+PluginType                         Namespace                           Lifecycle     Description                                          Name     
+---------------------------------------------------------------------------------------------------------------------------------------------------
+IRepository<String, Int32>         StructureMap.Testing.Acceptance     Transient     RepositoryBuilder.Build<String, Int32>()             (Default)
+---------------------------------------------------------------------------------------------------------------------------------------------------
+IRepository<TDocument, TQuery>     StructureMap.Testing.Acceptance     Transient     Build Repository<T, T1>() with RepositoryBuilder     (Default)
+===================================================================================================================================================
+

+ + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index 72d703b..ec7c687 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -46,7 +46,7 @@

@@ -104,7 +104,7 @@

Interception and Decorators

- Previous: Object Lifecycles + Previous: Generic Types diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html index 2cbdd24..81be808 100644 --- a/object-lifecycle/custom-lifecycles/index.html +++ b/object-lifecycle/custom-lifecycles/index.html @@ -47,7 +47,7 @@

diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html index 9c8dbc1..45c2519 100644 --- a/registration/on-missing-family-policies/index.html +++ b/registration/on-missing-family-policies/index.html @@ -185,7 +185,7 @@

Built In Policies

CloseGenericFamilyPolicy - uses the registration for an open type as a template to create the registrations for a closed type the first time StructureMap encounters -that closed type. See Working with Generic Types for more information.

Generic Types

FuncBuildByNamePolicy - Used internally to create registrations for Func<string, T> builders.
EnumerableFamilyPolicy - diff --git a/the-container/index.html b/the-container/index.html index f2764d3..28ca491 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -94,7 +94,7 @@
The Container
-
+
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 7b7905c..411ac1c 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -47,7 +47,7 @@
Previous
Next
Next

@@ -79,7 +79,7 @@

StructureMap 3.1.6

Working with Generic Types

Working with Enumerable Types

Profiles and Child Containers

@@ -414,7 +414,7 @@

Disposing Services

- Next: Working with Generic Types + Next: Working with Enumerable Types diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html index a06bbd2..1775853 100644 --- a/the-container/working-with-enumerable-types/index.html +++ b/the-container/working-with-enumerable-types/index.html @@ -46,7 +46,7 @@

@@ -103,7 +103,7 @@

Working with Enumerable Types

- Previous: Working with Generic Types + Previous: Nested Containers (Per Request/Transaction) From d264b255a4c5df2a408ff90ff8db17f1d54d975d Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Wed, 7 Oct 2015 11:13:18 -0500 Subject: [PATCH 09/55] Documentation Update --- documentation/index.html | 2 +- interception-and-decorators/index.html | 331 +++++++++++++++++- registration/index.html | 292 +-------------- .../requesting-a-concrete-type/index.html | 2 +- the-container/auto-wiring/index.html | 6 +- the-container/buildup/index.html | 156 +++++++++ .../index.html | 6 +- the-container/index.html | 2 +- the-container/lambdas/index.html | 155 ++++++++ .../index.html | 236 ++++++++++++- 10 files changed, 897 insertions(+), 291 deletions(-) create mode 100644 the-container/buildup/index.html create mode 100644 the-container/lambdas/index.html diff --git a/documentation/index.html b/documentation/index.html index 505a47b..0317b64 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index ec7c687..0fc32b1 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -94,8 +94,335 @@

Interception and Decorators

Until official documentation is completed, you can analyze the user acceptance tests for help with this topic.

TODO(Write some content!)

All of the samples from this topic are part of the user acceptance tests in the main codebase.

Interception in StructureMap really comes +in two basic flavors:

Activates - Do some action on or with an object just created or resolved by StructureMap
Decorates - Wrap (or optionally replace) an object just created with either a dynamic proxy or some sort of decorator

See the Glossary for a refresher on terms like Instance and PluginFamily.

Also see Working with the IContext at Build Time for more information about using the Container state within interception.

Activation Interceptors

For right now, all activation interceptors are either using or subclassing the ActivatorInterceptor<T> class.

This class has two constructor functions that interest us:

To create an activator interceptor that acts on an object that can be cast to type T:


+        public ActivatorInterceptor(Expression<Action<T>> action, string description = null)
+

To create an activator interceptor that acts on an object that can be cast to type T and +also uses the IContext service supplied by StructureMap itself.


+        public ActivatorInterceptor(Expression<Action<IContext, T>> action, string description = null)
+        {
+            _action = action;
+            _description = description;
+        }
+

Decorators


+    public class WidgetHolder : IWidget
+    {
+        private readonly IWidget _inner;
+
+        public WidgetHolder(IWidget inner)
+        {
+            _inner = inner;
+        }
+
+        public IWidget Inner
+        {
+            get { return _inner; }
+        }
+    }
+

Now, to see the decorator mechanism in action:


+        [Test]
+        public void decorator_example()
+        {
+            var container = new Container(_ =>
+            {
+                // This usage adds the WidgetHolder as a decorator
+                // on all IWidget registrations and makes AWidget
+                // the default
+                _.For<IWidget>().DecorateAllWith<WidgetHolder>();
+                _.For<IWidget>().Use<AWidget>();
+            });
+
+            container.GetInstance<IWidget>()
+                .ShouldBeOfType<WidgetHolder>()
+                .Inner.ShouldBeOfType<AWidget>();
+        }
+

In effect, doing a decorator this way has the same effect (and build plan) as:


+            var container = new Container(_ =>
+            {
+                _.For<IWidget>().Use<WidgetHolder>()
+                    .Ctor<IWidget>().Is<AWidget>();
+            });
+

Custom Decorator Interceptors

These objects can be created in two ways, by a user-supplied Expression<Func<T, T>> and optional description:


+        public FuncInterceptor(Expression<Func<T, T>> expression, string description = null)
+

and by a user-supplied Expression<Func<IContext, T, T>> and optional description.


+        public FuncInterceptor(Expression<Func<IContext, T, T>> expression, string description = null)
+

In both cases, the description field is only used for diagnostic purposes.

Interception Policies


+    /// <summary>
+    /// User defined policy to conventionally attach interceptors
+    /// to any pluginType/instance combination in a StructureMap
+    /// container
+    /// </summary>
+    public interface IInterceptorPolicy : IDescribed
+    {
+        /// <summary>
+        /// Determine what (if any) interceptors should be attached to the
+        /// given instance and pluginType
+        /// </summary>
+        /// <param name="pluginType">The Type that is being requested</param>
+        /// <param name="instance">The Instance being built</param>
+        /// <returns></returns>
+        IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance);
+    }
+

For a simple example, let's say that we want to decorate any IWidget object with the +WidgetHolder class from earlier. We could build a small custom interceptor policy +like this one:


+    public class CustomInterception : IInterceptorPolicy
+    {
+        public string Description
+        {
+            get { return "good interception policy"; }
+        }
+
+        public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance)
+        {
+            if (pluginType == typeof (IWidget))
+            {
+                // DecoratorInterceptor is the simple case of wrapping one type with another
+                // concrete type that takes the first as a dependency
+                yield return new DecoratorInterceptor(typeof (IWidget), typeof (WidgetHolder));
+            }
+        }
+    }
+

To use this custom interception policy, use the Policies.Interceptor() methods like this example:


+        [Test]
+        public void use_a_custom_interception_policy()
+        {
+            var container = new Container(x =>
+            {
+                x.Policies.Interceptors(new CustomInterception());
+
+                x.For<IWidget>().Use<AWidget>();
+            });
+
+            container.GetInstance<IWidget>()
+                .ShouldBeOfType<WidgetHolder>()
+                .Inner.ShouldBeOfType<AWidget>();
+        }
+

As a helper for creating your own interception policies, you can also use the InterceptorPolicy<T> base class +to conventionally apply some sort of IInterceptor to any number of Instance's:


+        public InterceptorPolicy(IInterceptor interceptor, Func<Instance, bool> filter = null)
+

Here's an example of InterceptorPolicy<T> in usage from the acceptance tests:


+        [Test]
+        public void apply_policy_selectively_with_a_func()
+        {
+            var activator1 = new ActivatorInterceptor<ITarget>(x => x.Activate());
+            var policy = new InterceptorPolicy<ITarget>(activator1, i => i.Name.StartsWith("A"));
+
+            var container = new Container(x =>
+            {
+                x.Policies.Interceptors(policy);
+                x.For<ITarget>().AddInstances(targets =>
+                {
+                    targets.Type<ATarget>().Named("A");
+                    targets.Type<ATarget>().Named("A1");
+                    targets.Type<ATarget>().Named("A2");
+                    targets.Type<ATarget>().Named("B");
+                    targets.Type<ATarget>().Named("C");
+                    targets.Type<ATarget>().Named("D");
+                });
+            });
+
+            container.GetInstance<ITarget>("A").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
+            container.GetInstance<ITarget>("A1").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
+            container.GetInstance<ITarget>("A2").ShouldBeOfType<ATarget>().WasActivated.ShouldBeTrue();
+            container.GetInstance<ITarget>("B").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
+            container.GetInstance<ITarget>("C").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
+            container.GetInstance<ITarget>("D").ShouldBeOfType<ATarget>().WasActivated.ShouldBeFalse();
+        }
+
+        public class ATarget : ITarget
+        {
+            public void Activate()
+            {
+                WasActivated = true;
+            }
+
+            public bool WasActivated { get; set; }
+
+            public void Debug()
+            {
+                throw new NotImplementedException();
+            }
+        }
+

Some quick things to note:

For decorator interceptors, InterceptorPolicy<T> will only apply if the pluginType matches T
For activation interceptors, InterceptorPolicy<T> will apply to any concrete type returned by an Instance that can be +cast to T

Apply Activation Interception by Type


+    public abstract class Activateable
+    {
+        public bool Activated { get; set; }
+
+        public void Activate()
+        {
+            Activated = true;
+        }
+    }
+

An implementation of Activateable from StructureMap's unit tests is shown below:


+    public class AWidget : Activateable, IWidget
+    {
+    }
+


+        [Test]
+        public void activate_by_action()
+        {
+            var container = new Container(x =>
+            {
+                x.For<IWidget>().Use<AWidget>();
+                x.For<Activateable>()
+                    .OnCreationForAll("Mark the object as activated", o => o.Activated = true);
+            });
+
+            container.GetInstance<IWidget>()
+                .ShouldBeOfType<AWidget>()
+                .Activated.ShouldBeTrue();
+        }
+

There are several overloads of OnCreationForAll() covering cases with and without IContext

Apply Decoration across a Plugin Type

As shown above, you can use the Registry.For<T>().DecorateAllWith<TDecorator>() to apply decorators to all Instance's +registered to a Plugin Type:


+        [Test]
+        public void decorate_with_type()
+        {
+            var container = new Container(x =>
+            {
+                x.For<IWidget>().DecorateAllWith<WidgetHolder>();
+                x.For<IWidget>().Use<AWidget>();
+            });
+
+            container.GetInstance<IWidget>()
+                .ShouldBeOfType<WidgetHolder>()
+                .Inner
+                .ShouldBeOfType<AWidget>();
+        }
+

Add Interception to a Single Instance


+            _container = new Container(r =>
+            {
+                r.For<ContextRecorder>().Use(recorder);
+
+
+                r.For<IService>().AddInstances(x =>
+                {
+                    x.Type<ColorService>()
+                        // Registers an activation action on this Instance
+                        .OnCreation("last service", s => _lastService = s)
+                        .Named("Intercepted")
+                        .Ctor<string>("color").Is("Red");
+
+                    x.Type<ColorService>()
+                        // Activation using IContext
+                        .OnCreation("last touched", (c, s) => c.GetInstance<ContextRecorder>().WasTouched = true)
+                        .Named("InterceptedWithContext")
+                        .Ctor<string>("color").Is("Red");
+
+                    x.Type<ColorService>()
+                        .Named("NotIntercepted")
+                        .Ctor<string>("color").Is("Blue");
+
+                    x.Object(new ColorService("Yellow"))
+                        .Named("Yellow")
+                        .OnCreation("set the last service", s => _lastService = s);
+
+                    x.ConstructedBy(() => new ColorService("Purple")).Named("Purple")
+                        // Applies a decorator to this instance. Not sure *why*
+                        // you'd want to do it this way
+                        .DecorateWith(s => new DecoratorService(s));
+
+                    x.ConstructedBy(() => new ColorService("Purple")).Named("DecoratedWithContext")
+                        // Fancier decorator
+                        .DecorateWith("decorated with context", (c, s) =>
+                        {
+                            c.GetInstance<ContextRecorder>().WasTouched = true;
+                            return new DecoratorService(s);
+                        });
+
+                    x.Type<ColorService>().Named("Decorated").DecorateWith(
+                        s => new DecoratorService(s))
+                        .Ctor<string>("color").Is("Orange");
+
+                    x.Object(new ColorService("Yellow")).Named("Bad")
+                        .OnCreation("throw exception", obj => { throw new ApplicationException("Bad!"); });
+                });
+

diff --git a/registration/index.html b/registration/index.html index d92cb9f..754c062 100644 --- a/registration/index.html +++ b/registration/index.html @@ -1,276 +1,16 @@ - - - - - - - - StructureMap - Registration - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

StructureMap 3.1.6

-
- - - -

Registry DSL

Setter Injection

- - -

Registration

- -

- - -

The static ObjectFactory wrapper for Container is still available in 3.0, but we strongly recommend against using it for new applications. It only exists for easier compatibility with older installations.

The first step in using StructureMap is configuring a Container object. The following examples are based on the usage of the Registry DSL.

Let's say that you have a simple set of services like this:


-    public interface IBar
-    {
-    }
-
-    public class Bar : IBar
-    {
-    }
-
-    public interface IFoo
-    {
-    }
-
-    public class Foo : IFoo
-    {
-        public IBar Bar { get; private set; }
-
-        public Foo(IBar bar)
-        {
-            Bar = bar;
-        }
-    }
-
-

A simple configuration of a StructureMap Container might then be:


-// Example #1 - Create an container instance and directly pass in the configuration.
-            var container1 = new Container(c =>
-            {
-                c.For<IFoo>().Use<Foo>();
-                c.For<IBar>().Use<Bar>();
-            });
-
-// Example #2 - Create an container instance but add configuration later.
-            var container2 = new Container();
-
-            container2.Configure(c =>
-            {
-                c.For<IFoo>().Use<Foo>();
-                c.For<IBar>().Use<Bar>();
-            });
-
-// Example #3 - Initialize the static ObjectFactory container.
-// NOTE: ObjectFactory has been deprecated and will be removed
-// in a future 4.0 release
-            ObjectFactory.Initialize(i =>
-            {
-                i.For<IFoo>().Use<Foo>();
-                i.For<IBar>().Use<Bar>();
-            });
-

Here's a sample Registry class used to configure the same types as in our previous example:


-    public class FooBarRegistry : Registry
-    {
-        public FooBarRegistry()
-        {
-            For<IFoo>().Use<Foo>();
-            For<IBar>().Use<Bar>();
-        }
-    }
-
-

When you set up a Container , you need to simply direct the Container to use the configuration in that Registry class.


-// Example #1
-            var container1 = new Container(new FooBarRegistry());
-
-// Example #2
-            var container2 = new Container(c => { c.AddRegistry<FooBarRegistry>(); });
-
-// Example #3 -- create a container for a single Registry
-            var container3 = Container.For<FooBarRegistry>();
-


-// Example #1
-            var container1 = new Container(c =>
-                c.Scan(scanner =>
-                {
-                    scanner.TheCallingAssembly();
-                    scanner.WithDefaultConventions();
-                }));
-
-// Example #2
-            var container2 = new Container();
-
-            container2.Configure(c =>
-                c.Scan(scanner =>
-                {
-                    scanner.TheCallingAssembly();
-                    scanner.WithDefaultConventions();
-                }));
-
-
-

We instruct the scanner to scan through the calling assembly with default conventions on. This wil find and registers the default instance for IFoo and IBar which are obviously the concrete types Foo and Bar. Now whenever you add an additional interface IMoreFoo and a class MoreFoo to your application's code base, it's automatically picked up by the scanner.

Sometimes classes need to be suplied with some primitive value in its constructor. For example the System.Data.SqlClient.SqlConnection needs to be supplied with the connection string in its constructor. No problem, just set up the value of the constructor argument in the bootstrapping:


-            var container = new Container(c =>
-            {
-                //just for demo purposes, normally you don't want to embed the connection string directly into code.
-                c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING");
-                //a better way would be providing a delegate that retrieves the value from your app config.    
-            });
-

So far you have seen an couple of ways to work with the <linkto:registration/registry-dsl]> and configure an Container object or ObjectFactory. We have seen examples of configuration that allows us to build objects that doesn't depend on anything like the Bar class, or do depend on other types like the Foo class needs an instance of IBar. In our last example we have seen configuration for objects that needs some primitive types like strings in its constructor function.

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +Error!

Error!

System.Collections.Generic.KeyNotFoundException: Key 'quickstart-configure-the-container-using-a-registry' could not be found
+   at FubuCore.Util.Cache`2.<.ctor>b__2(TKey key)
+   at FubuCore.Util.Cache`2.Fill(TKey key, Func`2 onMissing)
+   at ST.Docs.Samples.SampleCache.Find(String name)
+   at ST.Docs.DocProject.ST.Docs.Samples.ISampleCache.Find(String name)
+   at ST.Docs.Transformation.CodeSampleTransformHandler.Transform(Topic current, String data)
+   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
+   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
+   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
+   at ST.Docs.Transformation.Transformer.InnerTransformHandler.Transform(Topic current, String data)
+   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
+   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
+   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
+   at ST.Docs.Transformation.HtmlGenerator.generate(Topic topic)
+   at ST.Docs.Transformation.HtmlGenerator.Generate(Topic topic)

\ No newline at end of file diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html index 64d3058..bfec9b8 100644 --- a/resolving/requesting-a-concrete-type/index.html +++ b/resolving/requesting-a-concrete-type/index.html @@ -139,7 +139,7 @@

Auto Resolving Concrete Types

} -

Before we can resolve the concrete Weather type, we need an instance of an Container object or ObjectFactory. As mentioned earlier, these objects defines a generic GetInstance method which can build us an instance of the Weather type.

You can create a container yourself or use the statically accessed container.


             var container = new Container();
diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html
index e9973c2..9c440a2 100644
--- a/the-container/auto-wiring/index.html
+++ b/the-container/auto-wiring/index.html
@@ -47,7 +47,7 @@
 
 		        
 		      	Previous
-		      	Next
+		      	Next
 		      
       
         
@@ -79,7 +79,7 @@ StructureMap 3.1.6
 
 		        
 
-		        	Next
Working with the IContext at Build Time
+		        	Next
Building Objects with Lambdas
 		        	Previous
StructureMap Assumptions
 
 		        
@@ -108,7 +108,7 @@ Auto Wiring
 				        
 				        
 
-				        	Next: Working with the IContext at Build Time
+				        	Next: Building Objects with Lambdas


diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html
new file mode 100644
index 0000000..0ebf0f8
--- /dev/null
+++ b/the-container/buildup/index.html
@@ -0,0 +1,156 @@
+
+
+    
+         
+        
+        
+        
+		StructureMap - Fill Setter Dependencies of an Object Created Outside of StructureMap
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Fill Setter Dependencies of an Object Created Outside of StructureMap
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 3.1.6
+		      	

+
+				
+
+		        
+
+		        	Next
Object Lifecycles
+		        	Previous
Handling Missing Named Instances
+
+		        
+		      

+		      
+		      
+		      
+			      	Fill Setter Dependencies of an Object Created Outside of StructureMap
+			      
+			      	
+
+			      	
+			      		
+TODO -- Whine about how this is all a workaround bad legacy designs like just about anything in ASP.Net.
+
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Handling Missing Named Instances
+
+				        
+				        
+
+				        	Next: Object Lifecycles
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html
index 16f3b25..75a88ae 100644
--- a/the-container/handling-missing-named-instances/index.html
+++ b/the-container/handling-missing-named-instances/index.html
@@ -47,7 +47,7 @@
 
 		        
 		      	Previous
-		      	Next
+		      	Next


         
@@ -79,7 +79,7 @@ StructureMap 3.1.6
 
 		        
 
-		        	Next
Object Lifecycles
+		        	Next
Fill Setter Dependencies of an Object Created Outside of StructureMap
 		        	Previous
Working with Enumerable Types
 
 		        
@@ -280,7 +280,7 @@ Multi-Tenancy
 				        
 				        
 
-				        	Next: Object Lifecycles
+				        	Next: Fill Setter Dependencies of an Object Created Outside of StructureMap
 
 				        
 			      	
diff --git a/the-container/index.html b/the-container/index.html
index 28ca491..c1178f4 100644
--- a/the-container/index.html
+++ b/the-container/index.html
@@ -94,7 +94,7 @@ The Container
 			      	
 			      		
 
-StructureMap Assumptions
Auto Wiring
Working with the IContext at Build Time
Forwarding Requests for a Type to Another Type
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
+StructureMap Assumptions
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Forwarding Requests for a Type to Another Type
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Fill Setter Dependencies of an Object Created Outside of StructureMap
 
 
 			      	
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html
new file mode 100644
index 0000000..22cc6fe
--- /dev/null
+++ b/the-container/lambdas/index.html
@@ -0,0 +1,155 @@
+
+
+    
+         
+        
+        
+        
+		StructureMap - Building Objects with Lambdas
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Building Objects with Lambdas
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 3.1.6
+		      	

+
+				
+
+		        
+
+		        	Next
Working with the IContext at Build Time
+		        	Previous
Auto Wiring
+
+		        
+		      

+		      
+		      
+		      
+			      	Building Objects with Lambdas
+			      
+			      	
+
+			      	
+			      		
+
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Auto Wiring
+
+				        
+				        
+
+				        	Next: Working with the IContext at Build Time
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html
index 5bb6a5d..0661ba3 100644
--- a/the-container/working-with-the-icontext-at-build-time/index.html
+++ b/the-container/working-with-the-icontext-at-build-time/index.html
@@ -46,7 +46,7 @@
 		        
 
 		        
-		      	Previous
+		      	Previous
 		      	Next
 		      
       
@@ -80,7 +80,7 @@ StructureMap 3.1.6
 		        
 
 		        	Next
Forwarding Requests for a Type to Another Type
-		        	Previous
Auto Wiring
+		        	Previous
Building Objects with Lambdas
 
 		        
 		      

@@ -94,7 +94,235 @@ Working with the IContext at Build Time
 			      	
 			      		
 
-TODO(Write some content!)
+The IContext usage shown in this topic is certainly not going away in future versions of StructureMap, but if at all possible, the StructureMap team
+strongly recommends using Construction Policies to accomplish customized object building instead of relying
+on conditional logic using IContext at runtime.
+The IContext interface is what StructureMap uses to expose the current state of the internal "build session" for
+the current object creation operation for usage in user-supplied lambda builders or
+interceptors. IContext allows you to:
+
+Retrieve other services from the current Container to use in a Lambda
+"BuildUp" objects with setter dependencies
+Retrieve all the objects created inside the current build session that could be cast to a certain interface or base class
+If an object is being built as a dependency to another object, see the parent type
+See the root type of the top level object that StructureMap is building in this request
+
+The entire IContext interface is shown below:
+
+    /// <summary>
+    /// Access to the state and type resolution of the current "build session"
+    /// during a request to a StructureMap container
+    /// </summary>
+    public interface IContext
+    {
+        /// <summary>
+        /// The requested instance name of the object graph
+        /// </summary>
+        string RequestedName { get; }
+
+        /// <summary>
+        /// The "BuildUp" method takes in an already constructed object
+        /// and uses Setter Injection to push in configured dependencies
+        /// of that object
+        /// </summary>
+        /// <param name="target"></param>
+        void BuildUp(object target);
+
+        /// <summary>
+        /// Get the object of type T that is valid for this build session.
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <returns></returns>
+        T GetInstance<T>();
+
+        /// <summary>
+        /// Get the object of type T that is valid for this build session by name.
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <returns></returns>
+        T GetInstance<T>(string name);
+
+        /// <summary>
+        /// Get a service from the current build session by type
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <returns></returns>
+        object GetInstance(Type pluginType);
+
+        /// <summary>
+        /// Creates or finds the named instance of the pluginType
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <param name="instanceKey"></param>
+        /// <returns></returns>
+        object GetInstance(Type pluginType, string instanceKey);
+
+        /// <summary>
+        /// Same as GetInstance, but can gracefully return null if 
+        /// the Type does not already exist
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <returns></returns>
+        T TryGetInstance<T>() where T : class;
+
+        /// <summary>
+        /// Same as GetInstance(name), but can gracefully return null if 
+        /// the Type and name does not already exist
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <param name="name"></param>
+        /// <returns></returns>
+        T TryGetInstance<T>(string name) where T : class;
+
+        /// <summary>
+        /// Creates or finds the default instance of the pluginType. Returns null if the pluginType is not known to the container.
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <returns></returns>
+        object TryGetInstance(Type pluginType);
+
+        /// <summary>
+        /// Creates or finds the named instance of the pluginType. Returns null if the named instance is not known to the container.
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <param name="instanceKey"></param>
+        /// <returns></returns>
+        object TryGetInstance(Type pluginType, string instanceKey);
+
+        /// <summary>
+        /// Gets all objects in the current object graph that can be cast
+        /// to T that have already been created
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <returns></returns>
+        IEnumerable<T> All<T>() where T : class;
+
+
+        /// <summary>
+        /// Creates/Resolves every configured instance of PlutinType T
+        /// </summary>
+        /// <typeparam name="T"></typeparam>
+        /// <returns></returns>
+        IEnumerable<T> GetAllInstances<T>();
+
+        /// <summary>
+        /// Creates or resolves all registered instances of the pluginType
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <returns></returns>
+        IEnumerable<object> GetAllInstances(Type pluginType);
+
+        /// <summary>
+        /// The type of the parent object.  Useful for constructing
+        /// contextual logging dependencies
+        /// </summary>
+        Type ParentType { get; }
+
+        /// <summary>
+        /// The type of the requested object at the very top of the 
+        /// object graph
+        /// </summary>
+        Type RootType { get; }
+    }
+
+Example 1: Contextual Logging
+All of the sample code in this example is in Github.
+One of the canonical examples of using IContext is the integration of logging frameworks like NLog or Log4net
+that allow you to create logging policies by concrete type. With these tools, you generally have a static class (boo!)
+where you ask for the proper logging service for a type of object like this one:
+
+    public static class LoggerFactory
+    {
+        public static Logger LoggerFor(Type type)
+        {
+            return new Logger(type);
+        }
+    }
+
+Now, say you would want to have the proper Logger injected into every object that StructureMap creates that depends on Logger matching
+the concrete type of the object being created. That registration is shown below in a unit test from StructureMap's codebase:
+
+        [Test]
+        public void can_happily_use_the_parent_type()
+        {
+            var container = new Container(x =>
+            {
+                // AlwaysUnique() is important so that every object created will get
+                // their own Logger instead of sharing whichever one is created first
+                x.For<Logger>().Use(c => LoggerFactory.LoggerFor(c.ParentType)).AlwaysUnique();
+            });
+
+            var top = container.GetInstance<LoggedClass1>();
+            top.Logger.ParentType.ShouldBe(typeof (LoggedClass1));
+            top.Child.Logger.ParentType.ShouldBe(typeof (LoggedClass2));
+            top.Child.Child.Logger.ParentType.ShouldBe(typeof (LoggedClass3));
+        }
+
+Just for fun, here's the equivalent with the new construction policies from 4.0:
+
+        public class LoggerConvention : ConfiguredInstancePolicy
+        {
+            protected override void apply(Type pluginType, IConfiguredInstance instance)
+            {
+                instance.Constructor
+                    .GetParameters()
+                    .Where(param => param.ParameterType == typeof(Logger))
+                    .Each(param => instance.Dependencies.Add(LoggerFactory.LoggerFor(instance.PluggedType)));
+            }
+        }
+
+        [Test]
+        public void use_logger_convention()
+        {
+            var container = new Container(_ =>
+            {
+                _.Policies.Add<LoggerConvention>();
+            });
+
+            var top = container.GetInstance<LoggedClass1>();
+            top.Logger.ParentType.ShouldBe(typeof(LoggedClass1));
+            top.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass2));
+            top.Child.Child.Logger.ParentType.ShouldBe(typeof(LoggedClass3));
+        }
+
+The LoggerConvention way of accomplishing the logging integration is technically more code and possibly harder to understand,
+but it's significantly more efficient at runtime because the decision about which Logger to use is only done once upfront.
+The conventional approach should also be more evident in StructureMap diagnostics.
+Example 2: NHibernate Integration
+It's been several years since I used NHibernate, so I might not have the technical details exactly right here:)
+If you're developing a system with NHibernate managed by StructureMap, you will frequently need to inject
+NHibernate's ISession service into your concrete classes. There's a little catch though, to create an ISession object
+you have to use NHibernate's ISessionFactory service:
+
+    public interface ISession { }
+
+    public interface ISessionFactory
+    {
+        ISession Build();
+    }
+
+Sidestepping the issue of how to build an ISessionFactory, here's a possible way to enable a StructureMap
+Container to build and resolve dependencies of ISession with a lambda builder:
+
+    public class SessionFactoryRegistry : Registry
+    {
+        // Let's not worry about how ISessionFactory is built
+        // in this example
+        public SessionFactoryRegistry(ISessionFactory factory)
+        {
+            For<ISessionFactory>().Use(factory);
+
+
+            For<ISession>().Use("Build ISession from ISessionFactory", c =>
+            {
+                // To resolve ISession, I first pull out
+                // ISessionFactory from the IContext and use that
+                // to build a new ISession. 
+                return c.GetInstance<ISessionFactory>().Build();
+            });
+        }
+    }
+
 
 
 			      	
@@ -103,7 +331,7 @@ Working with the IContext at Build Time
 
 			      	
 				        
-				        	Previous: Auto Wiring
+				        	Previous: Building Objects with Lambdas
 
 				        
 				        

From d24ccbb657a2627071d24b18621f0017d8a746d9 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Wed, 7 Oct 2015 11:15:12 -0500
Subject: [PATCH 10/55] Documentation Update

---
 registration/index.html | 282 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 266 insertions(+), 16 deletions(-)

diff --git a/registration/index.html b/registration/index.html
index 754c062..dfaacae 100644
--- a/registration/index.html
+++ b/registration/index.html
@@ -1,16 +1,266 @@
-
-Error!Error!
System.Collections.Generic.KeyNotFoundException: Key 'quickstart-configure-the-container-using-a-registry' could not be found
-   at FubuCore.Util.Cache`2.<.ctor>b__2(TKey key)
-   at FubuCore.Util.Cache`2.Fill(TKey key, Func`2 onMissing)
-   at ST.Docs.Samples.SampleCache.Find(String name)
-   at ST.Docs.DocProject.ST.Docs.Samples.ISampleCache.Find(String name)
-   at ST.Docs.Transformation.CodeSampleTransformHandler.Transform(Topic current, String data)
-   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
-   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
-   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
-   at ST.Docs.Transformation.Transformer.InnerTransformHandler.Transform(Topic current, String data)
-   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
-   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
-   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
-   at ST.Docs.Transformation.HtmlGenerator.generate(Topic topic)
-   at ST.Docs.Transformation.HtmlGenerator.Generate(Topic topic)
\ No newline at end of file
+
+
+    
+         
+        
+        
+        
+		StructureMap - Registration
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 3.1.6
+		      	

+
+				
+
+		        
+
+		        	Next
Registry DSL
+		        	Previous
Setter Injection
+
+		        
+		      

+		      
+		      
+		      
+			      	Registration
+			      
+			      	
+
+			      	
+			      		
+
+As of the 3.0 release, StructureMap provides a streamlined fluent interface called the Registry DSL to configure a StructureMap
+Container with both explicit registrations and conventional auto-registrations. StructureMap no longer supports Xml configuration or MEF-style attribute configuration -- but there is some facility for rolling your own attribute-based configuration support.
+The first step in using StructureMap is configuring a Container object. The following examples are based on the usage of the Registry DSL.
+Let's say that you have a simple set of services like this:
+
+    public interface IBar
+    {
+    }
+
+    public class Bar : IBar
+    {
+    }
+
+    public interface IFoo
+    {
+    }
+
+    public class Foo : IFoo
+    {
+        public IBar Bar { get; private set; }
+
+        public Foo(IBar bar)
+        {
+            Bar = bar;
+        }
+    }
+
+
+A simple configuration of a StructureMap Container might then be:
+
+// Example #1 - Create an container instance and directly pass in the configuration.
+            var container1 = new Container(c =>
+            {
+                c.For<IFoo>().Use<Foo>();
+                c.For<IBar>().Use<Bar>();
+            });
+
+// Example #2 - Create an container instance but add configuration later.
+            var container2 = new Container();
+
+            container2.Configure(c =>
+            {
+                c.For<IFoo>().Use<Foo>();
+                c.For<IBar>().Use<Bar>();
+            });
+
+Initializing or configuring the container is usually done at application startup and is located as close as possible to the application's entry point.
+This place is sometimes referred to as the composition root of the application.
+In our example we are composing our application's object graph by connecting abstractions to concrete types.
+We are using the fluent API For<TInterface>().Use<TConcrete>() which registers a default instance for a given plugin type (the TInterface type in this case). In our example we want an new instance of Foo every time we request the abstraction IFoo.
+The recommended way of using the Registry DSL is by defining one or more Registry classes. Typically, you would subclass the Registry class,
+then use the Fluent API methods exposed by the Registry class to describe a Container configuration.
+Here's a sample Registry class used to configure the same types as in our previous example:
+
+    public class FooBarRegistry : Registry
+    {
+        public FooBarRegistry()
+        {
+            For<IFoo>().Use<Foo>();
+            For<IBar>().Use<Bar>();
+        }
+    }
+
+
+When you set up a Container , you need to simply direct the Container to use the configuration in that Registry class.
+
+// Example #1
+            var container1 = new Container(new FooBarRegistry());
+
+// Example #2
+            var container2 = new Container(c => { c.AddRegistry<FooBarRegistry>(); });
+
+// Example #3 -- create a container for a single Registry
+            var container3 = Container.For<FooBarRegistry>();
+
+The StructureMap team highly recommends using `Registry` classes for your real application configuration.  The syntax is shorter inside the Registry class constructor than from within the `Container` constructor method. In addition, Registry classes can be used to modularize the configuration of a bigger application into more manageable chunks.  Lastly, using `Registry` classes makes it easier to stand up additional `Container` objects in testing scenarios that reflect the real application composition.
+In real world applications you also have to deal with repetitive similar registrations. Such registrations are tedious, easy to forget and can be a weak spot in your application. StructureMap provides Auto-Registration and Conventions  which mitigates this pain and eases the maintenance burden. StructureMap exposes this feature through the Registry DSL by the Scan method.
+In our example there is an reoccuring pattern, we are connecting the plugin type ISomething to a concrete type Something, meaning IFoo to Foo and IBar to Bar. Wouldn't it be cool if we could write a convention for exactly doing that? Fortunatly StructureMap has already one build in. Let's see how we can create an container with the same configuration as in the above examples.
+
+// Example #1
+            var container1 = new Container(c =>
+                c.Scan(scanner =>
+                {
+                    scanner.TheCallingAssembly();
+                    scanner.WithDefaultConventions();
+                }));
+
+// Example #2
+            var container2 = new Container();
+
+            container2.Configure(c =>
+                c.Scan(scanner =>
+                {
+                    scanner.TheCallingAssembly();
+                    scanner.WithDefaultConventions();
+                }));
+
+
+
+We instruct the scanner to scan through the calling assembly with default conventions on. This wil find and registers the default instance for IFoo and IBar which are obviously the concrete types Foo and Bar. Now whenever you add an additional interface IMoreFoo and a class MoreFoo to your application's code base, it's automatically picked up by the scanner.
+Sometimes classes need to be suplied with some primitive value in its constructor. For example the System.Data.SqlClient.SqlConnection needs to be supplied with the connection string in its constructor. No problem, just set up the value of the constructor argument in the bootstrapping:
+
+            var container = new Container(c =>
+            {
+                //just for demo purposes, normally you don't want to embed the connection string directly into code.
+                c.For<IDbConnection>().Use<SqlConnection>().Ctor<string>().Is("YOUR_CONNECTION_STRING");
+                //a better way would be providing a delegate that retrieves the value from your app config.    
+            });
+
+So far you have seen an couple of ways to work with the <linkto:registration/registry-dsl]> and configure an Container object. We have seen examples of configuration that allows us to build objects that doesn't depend on anything like the Bar class, or do depend on other types like the Foo class needs an instance of IBar. In our last example we have seen configuration for objects that needs some primitive types like strings in its constructor function.
+
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Setter Injection
+
+				        
+				        
+
+				        	Next: Registry DSL
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+

From 0b9905075bfb1b59ac8fff36f5f21f250bc4abbd Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Wed, 7 Oct 2015 17:18:57 -0500
Subject: [PATCH 11/55] Documentation Update

---
 documentation/index.html                      |   2 +-
 features/index.html                           |   4 +-
 get-structuremap/index.html                   |  26 +--
 instances/index.html                          | 155 ++++++++++++++++++
 integrations/index.html                       |   6 +-
 registration/attributes/index.html            |   6 +-
 registration/clear-or-replace/index.html      | 155 ++++++++++++++++++
 registration/constructor-selection/index.html |   6 +-
 registration/fallback-services/index.html     |  95 ++++++++++-
 registration/registry-dsl/index.html          | 100 +++++++++++
 release-notes/index.html                      |   6 +-
 roadmap/index.html                            |  12 +-
 12 files changed, 524 insertions(+), 49 deletions(-)
 create mode 100644 instances/index.html
 create mode 100644 registration/clear-or-replace/index.html

diff --git a/documentation/index.html b/documentation/index.html
index 0317b64..d169bf5 100644
--- a/documentation/index.html
+++ b/documentation/index.html
@@ -93,7 +93,7 @@ Documentation
 
 			      	
 			      		The documentation may never be exhaustive, but here are the major sections so far:
-Documentation
Roadmap
A Gentle Quickstart
Glossary
Get StructureMap
Features
Software Design Concepts
Setter Injection
RegistrationRegistry DSL
Inline Dependencies
Auto-Registration and Conventions
Working with IConfiguredInstance
Construction Policies
Changing Configuration at Runtime
On Missing Family Policies
Constructor Selection
Configuring the Raw Model
Fallback Services
Using Attributes for Configuration
Resolving ServicesGet a Service by PluginType
Get a Service by Plugin Type and Name
Get all Services by Plugin Type
Try Getting an Optional Service by Plugin Type
Try Geting an Optional Service by Plugin Type and Name
Passing Arguments at Runtime
Auto Resolving Concrete Types
The ContainerStructureMap Assumptions
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Forwarding Requests for a Type to Another Type
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Fill Setter Dependencies of an Object Created Outside of StructureMap
Object LifecyclesSupported Lifecycles
Configuring Lifecycles
Custom Lifecycles
Generic Types
Interception and Decorators
Interpreting Exceptions
DiagnosticsWhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
Internals and Architecture
Best Practices
FAQ
History
Release Notes
Integrating StructureMap into Common .Net Frameworks
+Documentation
Roadmap
A Gentle Quickstart
Glossary
Get StructureMap
Features
Software Design Concepts
Setter Injection
RegistrationRegistry DSL
Inline Dependencies
Auto-Registration and Conventions
Working with IConfiguredInstance
Construction Policies
Changing Configuration at Runtime
On Missing Family Policies
Constructor Selection
Fallback Services
Replace or Clear Out Previous Registrations
Using Attributes for Configuration
Resolving ServicesGet a Service by PluginType
Get a Service by Plugin Type and Name
Get all Services by Plugin Type
Try Getting an Optional Service by Plugin Type
Try Geting an Optional Service by Plugin Type and Name
Passing Arguments at Runtime
Auto Resolving Concrete Types
The ContainerStructureMap Assumptions
Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Forwarding Requests for a Type to Another Type
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Fill Setter Dependencies of an Object Created Outside of StructureMap
Object LifecyclesSupported Lifecycles
Configuring Lifecycles
Custom Lifecycles
Generic Types
Interception and Decorators
Interpreting Exceptions
DiagnosticsWhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
Internals and Architecture
Best Practices
FAQ
History
Release Notes
Custom Instance Types
Integrating StructureMap into Common .Net Frameworks
 
 
 			      	
diff --git a/features/index.html b/features/index.html
index 23a6e8a..0f2a70a 100644
--- a/features/index.html
+++ b/features/index.html
@@ -123,12 +123,10 @@ Features
 Things StructureMap does not have
 The following things are features that are not uncommon in other IoC tools or were present in previous versions of StructureMap.
 
-Any kind of Aspect Oriented Programming hooks out of the box, but it's perfectly possible to utilize the interception capabilities to integrate the
-runtime AOP tool of your choice into StructureMap
 Xml configuration was removed for the 3.0 release.
 Comprehensive attribute based configuration was also removed for the 3.0 release, but there is some very rudimentary support for attibute based
 configuration
-Complex Auto Factory support (this feature is planned for StructureMap 4.0)
+Complex Auto Factory support (this feature may be part of the StructureMap 4.0 release)
 
 Note! The StructureMap team strongly feels that Xml configuration is both undesirable and unnecessary. Please feel free to use the Google user group to ask for advice on how to move away from Xml configuration in existing applications.
 
diff --git a/get-structuremap/index.html b/get-structuremap/index.html
index 95133b9..e39aac6 100644
--- a/get-structuremap/index.html
+++ b/get-structuremap/index.html
@@ -98,36 +98,14 @@ Current Release
 The current version of StructureMap will always be available on Nuget. See the Release Notes for more information.
 Supported Platforms
 The original StructureMap.dll has been broken up into a couple pieces. The main assembly will be targeting PCL compliance thanks to the diligent efforts of Frank Quednau, and that means that anything to do with ASP.Net or falls outside of the PCL core has been devolved into separate assemblies and eventually into different Nuget packages. This means that StructureMap 3.* will theoretically support WP8 and other versions of .Net for the very first time.
-At this point StructureMap 3.* has been used on .Net 4, 4.5, and WP8. Nobody in the core StructureMap team is currently working with Xamarin mobile runtimes, but we are interested in verifying StructureMap on new platforms if any volunteers are interested.
+At this point StructureMap 3.* has been used on .Net 4, 4.5, WP8, and WP8.1. Nobody in the core StructureMap team is currently working with Xamarin mobile runtimes, but we are interested in verifying StructureMap on new platforms if any volunteers are interested in helping us out.
 Binaries
 Binaries of StructureMap are available via NuGet:
 PM> Install-Package StructureMap
 
 Source
 StructureMap's source is hosted on GitHub. If you want to fix a bug or just want to tinker with an idea, we love receiving pull requests! Start by creating your own fork on Github.
-
-StructureMap needs FubuRake and Ripple for building the source. FubuRake is an OSS Ruby library to quickly stand up a fully functional, cross platform rake script for a .Net codebase based on Fubu project standards. Ripple is a package manager that simplifies managing Nuget dependencies in your solution. Both dependencies are currently distributed through Ruby Gems and are part of the Fubu family. Before you continue you need to make sure that you have got Ruby installed.
-
-Clone the repository: git clone git://github.com/structuremap/structuremap.git
-Now really make sure that you have got Ruby 1.9+ installed
-See the README in the source code for instructions on using gems to install rake and other gems
-In the root of the StructureMap Git repository, run rake.
-Open StructureMap.sln in VS2012 ('rake sln' from the root as well).
-Build.
-
-

-
-Installing Ruby, Rake and RubyGems
-
-
-Installing Ruby will give you RubyGems and Rake out of the box. You can find installation guidance at the official Ruby language website or you could install Ruby via Chocolatey:
-
-
-> cinst ruby
-
-
-After you have Ruby, Rake and RubyGems installed you are good to go. The rake build file rakefile.rb (located in the root) will install al the other needed dependencies like FubuRake and Ripple, which are defined in the Gemfile (also located in the root). This file is used by another gem called bundler. The rake build file will automatically install bundler, which does the same for all the dependencies listed in the Gemfile, but only if they weren't already installed on your machine.
-
+The StructureMap build tooling has recently changed. See the GitHub README for more information on how to build and work with the StructureMap codebase.
 
 
 			      	
diff --git a/instances/index.html b/instances/index.html
new file mode 100644
index 0000000..11a36aa
--- /dev/null
+++ b/instances/index.html
@@ -0,0 +1,155 @@
+
+
+    
+         
+        
+        
+        
+		StructureMap - Custom Instance Types
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Custom Instance Types
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 3.1.6
+		      	

+
+				
+
+		        
+
+		        	Next
Integrating StructureMap into Common .Net Frameworks
+		        	Previous
Release Notes
+
+		        
+		      

+		      
+		      
+		      
+			      	Custom Instance Types
+			      
+			      	
+
+			      	
+			      		
+
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Release Notes
+
+				        
+				        
+
+				        	Next: Integrating StructureMap into Common .Net Frameworks
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/integrations/index.html b/integrations/index.html
index a80d5be..af79688 100644
--- a/integrations/index.html
+++ b/integrations/index.html
@@ -46,7 +46,7 @@
 		        
 
 		        
-		      	Previous
+		      	Previous
 		      	
 		      
       
@@ -80,7 +80,7 @@ StructureMap 3.1.6
 		        
 
 		        	
-		        	Previous
Release Notes
+		        	Previous
Custom Instance Types
 
 		        
 		      

@@ -113,7 +113,7 @@ Integrating StructureMap into Common .Net Frameworks


 				        
-				        	Previous: Release Notes
+				        	Previous: Custom Instance Types
 
 				        
 				        
diff --git a/registration/attributes/index.html b/registration/attributes/index.html
index 597b31f..75ee8a2 100644
--- a/registration/attributes/index.html
+++ b/registration/attributes/index.html
@@ -46,7 +46,7 @@
 		        
 
 		        
-		      	Previous
+		      	Previous
 		      	Next
 		      
       
@@ -80,7 +80,7 @@ StructureMap 3.1.6
 		        
 
 		        	Next
Resolving Services
-		        	Previous
Fallback Services
+		        	Previous
Replace or Clear Out Previous Registrations
 
 		        
 		      

@@ -101,7 +101,7 @@ Using Attributes for Configuration
 
 			      	
 				        
-				        	Previous: Fallback Services
+				        	Previous: Replace or Clear Out Previous Registrations
 
 				        
 				        
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html
new file mode 100644
index 0000000..176b599
--- /dev/null
+++ b/registration/clear-or-replace/index.html
@@ -0,0 +1,155 @@
+
+
+    
+         
+        
+        
+        
+		StructureMap - Replace or Clear Out Previous Registrations
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Replace or Clear Out Previous Registrations
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 3.1.6
+		      	

+
+				
+
+		        
+
+		        	Next
Using Attributes for Configuration
+		        	Previous
Fallback Services
+
+		        
+		      

+		      
+		      
+		      
+			      	Replace or Clear Out Previous Registrations
+			      
+			      	
+
+			      	
+			      		
+
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Fallback Services
+
+				        
+				        
+
+				        	Next: Using Attributes for Configuration
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html
index 9d046c2..a1fd4b2 100644
--- a/registration/constructor-selection/index.html
+++ b/registration/constructor-selection/index.html
@@ -47,7 +47,7 @@
 
 		        
 		      	Previous
-		      	Next
+		      	Next
 		      
       
         
@@ -79,7 +79,7 @@ StructureMap 3.1.6
 
 		        
 
-		        	Next
Configuring the Raw Model
+		        	Next
Fallback Services
 		        	Previous
On Missing Family Policies
 
 		        
@@ -307,7 +307,7 @@ Custom Constructor Selection Rule
 				        
 				        
 
-				        	Next: Configuring the Raw Model
+				        	Next: Fallback Services
 
 				        
 			      	
diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html
index f187362..19d79a0 100644
--- a/registration/fallback-services/index.html
+++ b/registration/fallback-services/index.html
@@ -46,8 +46,8 @@
 		        
 
 		        
-		      	Previous
-		      	Next
+		      	Previous
+		      	Next


         
@@ -79,8 +79,8 @@ StructureMap 3.1.6
 
 		        
 
-		        	Next
Using Attributes for Configuration
-		        	Previous
Configuring the Raw Model
+		        	Next
Replace or Clear Out Previous Registrations
+		        	Previous
Constructor Selection
 
 		        
 		      

@@ -94,7 +94,88 @@ Fallback Services
 			      	
 			      		
 
-TODO(Write some content!)
+The following is a technique that was stolen from FubuMVC where we used
+the idea of default or "fallback" registrations to make it mechanically simple for the core framework to declare
+the default service registrations in the Container for what FubuMVC needed while allowing applications to happily
+override specific registrations without having to worry about the order in which the registrations were done.
+To see this in practice, say you have an application that will support client specific modularity that might allow
+business clients to override the base StructureMap registrations. This is a perfect use case for
+defining the application defaults with UseIfNone() as shown in this example below:
+
+        public class DefaultServices : Registry
+        {
+            public DefaultServices()
+            {
+                // If nobody else provides a default
+                // for IWidget, use AWidget
+                For<IWidget>().UseIfNone<AWidget>();
+            }
+        }
+
+        public class SpecificServices : Registry
+        {
+            public SpecificServices()
+            {
+                // Use BWidget for IWidget, period
+                For<IWidget>().Use<BWidget>();
+            }
+        }
+
+        [Test]
+        public void see_use_if_none_in_action()
+        {
+            var container1 = Container.For<DefaultServices>();
+
+            // No other registrations, so fallback
+            // to AWidget
+            container1.GetInstance<IWidget>()
+                .ShouldBeOfType<AWidget>();
+
+
+            var container2 = new Container(_ =>
+            {
+                // add both registries above
+                // NOTE: the order does not matter for IWidget
+
+                _.IncludeRegistry<SpecificServices>();
+                _.IncludeRegistry<DefaultServices>();
+            });
+
+            // The registration in SpecificServices
+            // should win out
+            container2.GetInstance<IWidget>()
+                .ShouldBeOfType<BWidget>();
+        }
+
+In application usage, you would add the default UseIfNone() registrations, and optionally pick
+up additional extension Registry objects from extension assemblies as shown in this example:
+
+        [AttributeUsage(AttributeTargets.Assembly)]
+        public class ProductModuleAttribute : Attribute { }
+
+        public class ApplicationRegistry : Registry
+        {
+            public ApplicationRegistry()
+            {
+                // Use the default services as fallbacks
+                IncludeRegistry<DefaultServices>();
+
+                // Dependending on what assemblies are present,
+                // this might find specific registrations that
+                // will take precedence over the UseIfNone() 
+                // registrations in DefaultServices
+                Scan(_ =>
+                {
+                    _.AssembliesFromApplicationBaseDirectory(assem =>
+                    {
+                        return assem.HasAttribute<ProductModuleAttribute>();
+                    });
+
+                    _.LookForRegistries();
+                });
+            }
+        }
+
 
 
 			      	
@@ -103,12 +184,12 @@ Fallback Services
 
 			      	
 				        
-				        	Previous: Configuring the Raw Model
+				        	Previous: Constructor Selection
 
 				        
 				        
 
-				        	Next: Using Attributes for Configuration
+				        	Next: Replace or Clear Out Previous Registrations
 
 				        
 			      	
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html
index 4762ad2..f2720a6 100644
--- a/registration/registry-dsl/index.html
+++ b/registration/registry-dsl/index.html
@@ -134,6 +134,106 @@ Including Registries
             container.GetAllInstances<IWidget>().Count().ShouldBe(5);
         }
 
+

Use versus Add

For().Use()

To register the default Instance of a type, the syntax is one of the Registry.For().Use() overloads shown below:


+    public class SettingDefaults : Registry
+    {
+        public SettingDefaults()
+        {
+            // If you know the plugin type and its a closed type
+            // you can use this syntax
+            For<IWidget>().Use<DefaultWidget>();
+
+            // By Lambda
+            For<IWidget>().Use(() => new DefaultWidget());
+
+            // Pre-existing object
+            For<IWidget>().Use(new AWidget());
+
+            // This is rare now, but still valid
+            For<IWidget>().Add<AWidget>().Named("A");
+            For<IWidget>().Add<BWidget>().Named("B");
+            For<IWidget>().Use("A"); // makes AWidget the default
+
+            // Also rare, but you can supply an Instance object
+            // yourself for special needs
+            For<IWidget>().UseInstance(new MySpecialInstance());
+            
+            // If you're registering an open generic type
+            // or you just have Type objects, use this syntax
+            For(typeof (IService<>)).Use(typeof (Service<>));
+
+            // This is occasionally useful for generic types
+            For(typeof (IService<>)).Use(new MySpecialInstance());
+        }
+    }
+

For().Add()

To register additional Instance's for a plugin type, use one of the overloads of For().Add():


+    public class AdditionalRegistrations : Registry
+    {
+        public AdditionalRegistrations()
+        {
+            // If you know the plugin type and its a closed type
+            // you can Add this syntax
+            For<IWidget>().Add<DefaultWidget>();
+
+            // By Lambda
+            For<IWidget>().Add(() => new DefaultWidget());
+
+            // Pre-existing object
+            For<IWidget>().Add(new AWidget());
+
+            // Also rare, but you can supply an Instance object
+            // yourself for special needs
+            For<IWidget>().AddInstance(new MySpecialInstance());
+
+            // If you're registering an open generic type
+            // or you just have Type objects, Add this syntax
+            For(typeof(IService<>)).Add(typeof(Service<>));
+
+            // This is occasionally Addful for generic types
+            For(typeof(IService<>)).Add(new MySpecialInstance());
+        }
+    }
+

Add Many Registrations with For().AddInstances()

If you need to add several Instance's to a single plugin type, the AddInstances() syntax +shown below may be quicker and easier to use:


+
+                // registry is a StructureMap Registry object
+                registry.For<IService>().AddInstances(x =>
+                {
+                    // Equivalent to For<IService>().Add<ColorService>().....
+                    x.Type<ColorService>().Named("Red").Ctor<string>("color").Is("Red");
+
+                    // Equivalent to For<IService>().Add(new ColorService("Yellow"))......
+                    x.Object(new ColorService("Yellow")).Named("Yellow");
+
+                    // Equivalent to For<IService>().Use(() => new ColorService("Purple"))....
+                    x.ConstructedBy(() => new ColorService("Purple")).Named("Purple");
+
+                    x.Type<ColorService>().Named("Decorated").Ctor<string>("color").Is("Orange");
+                });
+

Named Instances

When you have multiple implementations of an interface, it can often be useful to diff --git a/release-notes/index.html b/release-notes/index.html index fcaffbd..a639668 100644 --- a/release-notes/index.html +++ b/release-notes/index.html @@ -47,7 +47,7 @@

diff --git a/roadmap/index.html b/roadmap/index.html index 1a2c53b..1aad574 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -94,10 +94,18 @@

Roadmap

StructureMap 3.0 marked a huge change in the StructureMap internals and public API's. 4.0 is a much smaller release that primarily improves type scanning, +

StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's.

The ongoing work for version 4.0 is a much smaller release that primarily improves type scanning, diagnostics, and performance. The only breaking changes from 3 to 4 are in custom type scanning conventions.

Please log any suspected bugs or feature requests on StructureMap's GitHub page.

After 4.0 is released, the StructureMap team will finally focus on the new DNX platform and officially support a StructureMap adapter for DNX.

Ongoing and upcoming work

The 4.0 work can be browsed from the GitHub issue list.
A new package called StructureMap.DynamicInterception for adding support for AOP with Castle.Core dynamic proxies to StructureMap
The StructureMap.DNX package for DNX integration (an early version is already available on Nuget.org)
Sometime in 2016 StructureMap will support the CoreCLR

From 1182ccf986b7ab220438f8dc82518565a3a4349a Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Thu, 8 Oct 2015 09:59:20 -0500 Subject: [PATCH 12/55] Documentation Update --- documentation/index.html | 2 +- integrations/index.html | 37 ++- registration/configured-instance/index.html | 11 + the-container/auto-wiring/index.html | 68 ++++- the-container/buildup/index.html | 6 +- .../index.html | 65 ++++- the-container/index.html | 2 +- the-container/primitives/index.html | 260 ++++++++++++++++++ .../profiles-and-child-containers/index.html | 6 +- .../index.html | 6 +- 10 files changed, 434 insertions(+), 29 deletions(-) create mode 100644 the-container/primitives/index.html diff --git a/documentation/index.html b/documentation/index.html index d169bf5..826f878 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/integrations/index.html b/integrations/index.html index af79688..aee669e 100644 --- a/integrations/index.html +++ b/integrations/index.html @@ -93,18 +93,31 @@

Integrating StructureMap into Common .Net Frameworks

I'm thinking that this page needs to cover:

ASP.Net MVC <= 5
Web API
NHibernate - not sure how popular this is anymore, but I had a question about it in the past couple weeks
EF <-- maybe the highest priority
RavenDb
MVC6
NancyFx
NServiceBus
What else?

ASP.Net MVC 5

The StructureMap team recommends the StructureMap.MVC5 nuget for integrating +StructureMap into pre-DNX ASP.Net MVC. The design is necessarily odd to work around ASP.Net limitations, but you do get the all +important "nested container per HTTP request" pattern that we recommend.

Web API (pre-DNX)

The StructureMap team recommends the StructureMap.WebApi2 nuget package. +The IoC integration in Web API is somewhat better designed than ASP.Net MVC's bolt on mechanism and the StructureMap integration +is quite a bit cleaner.

DNX

See the StructureMap.DNX project and Nuget for an early version of integration with DNX.

NServiceBus

Use the NServiceBus StructureMap nuget for integrating StructureMap 3 into +NServiceBus.

NancyFx

NancyFx provides the Nancy.BootStrappers.StructureMap nuget package. The early +versions of the NancyFx integration with StructureMap were deeply flawed but improved in later versions, so do make sure that you are using the latest version of the bootstrapper.

MassTransit

Use the MassTransit.StructureMap nuget package. Unfortunately, this package +depends on the signed version of StructureMap, so prepare yourself for version conflicts, +binding redirects, and the fusion log viewer. See the MassTransit documentation on using StructureMap for more information.

Entity Framework

The best example is this blog post from Jimmy Bogard.

AutoMapper

See My AutoMapper setup for StructureMap from Martijn Burgers.

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index 91a6839..27da2d0 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -153,6 +153,17 @@

Working with IConfiguredInstance

/// Explicitly choose a constructor /// </summary> ConstructorInfo Constructor { get; set; } + + /// <summary> + /// Has a build plan already been created for this instance? + /// </summary> + /// <returns></returns> + bool HasBuildPlan(); + + /// <summary> + /// Clears out any cached IBuildPlan for this Instance. + /// </summary> + void ClearBuildPlan(); }

Changing the Instance Lifecycle

diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index 9c440a2..5413b6c 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -94,7 +94,73 @@

Auto Wiring

TODO(Write some content!)


+        // This is the wrong way to use an IoC container.  Do NOT invoke the container from
+        // the constructor function.  This tightly couples the ShippingScreenPresenter to
+        // the IoC container in a harmful way.  This class cannot be used in either
+        // production or testing without a valid IoC configuration.  Plus, you're writing more
+        // code
+        public ShippingScreenPresenter(IContainer container)
+        {
+            // It's even worse if you use a static facade to retrieve
+            // a service locator!
+            _service = container.GetInstance<IShippingService>();
+            _repository = container.GetInstance<IRepository>();
+        }
+


+        // This is the way to write a Constructor Function with an IoC tool
+        // Let the IoC container "inject" services from outside, and keep
+        // ShippingScreenPresenter ignorant of the IoC infrastructure
+        public ShippingScreenPresenter(IShippingService service, IRepository repository)
+        {
+            _service = service;
+            _repository = repository;
+        }
+

Looking at the build plan for ShippingScreenPresenter:


+        public void ShowBuildPlan()
+        {
+            var container = new Container(_ =>
+            {
+                _.For<IShippingService>().Use<InternalShippingService>();
+                _.For<IRepository>().Use<SimpleRepository>();
+            });
+
+            // Just proving that we can build ShippingScreenPresenter;)
+            container.GetInstance<ShippingScreenPresenter>().ShouldNotBeNull();
+
+            var buildPlan = container.Model.For<ShippingScreenPresenter>().Default.DescribeBuildPlan(1);
+
+            Debug.WriteLine(buildPlan);
+        }
+

give us:

+PluginType: StructureMap.Testing.DocumentationExamples.ShippingScreenPresenter
+Lifecycle: Transient
+new ShippingScreenPresenter(IShippingService, IRepository)
+  ┣ IShippingService = **Default**
+  ┃                     | PluginType: StructureMap.Testing.DocumentationExamples.IShippingService
+  ┃                     | Lifecycle: Transient
+  ┃                     | new InternalShippingService()
+  ┃                    
+  ┗ IRepository = **Default**
+               | PluginType: StructureMap.Testing.DocumentationExamples.IRepository
+               | Lifecycle: Transient
+               | new SimpleRepository()
+

See Working with Primitive Types for more information on how StructureMap deals with primitive types like numbers, strings, enums, and dates in auto-wiring.

diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html index 0ebf0f8..1cc6afd 100644 --- a/the-container/buildup/index.html +++ b/the-container/buildup/index.html @@ -47,7 +47,7 @@

@@ -79,7 +79,7 @@

StructureMap 3.1.6

Object Lifecycles

Working with Primitive Types

Handling Missing Named Instances

@@ -107,7 +107,7 @@

Fill Setter Dependencies of an Object Created Outside of StructureMap

- Next: Object Lifecycles + Next: Working with Primitive Types diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index 0ab2516..411ee7b 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -5,7 +5,7 @@ - StructureMap - Forwarding Requests for a Type to Another Type + StructureMap - Registering a Single Instance Against Multiple PluginType's @@ -62,7 +62,7 @@

@@ -87,14 +87,69 @@

Forwarding Requests for a Type to Another Type

Registering a Single Instance Against Multiple PluginType's

- + -

TODO(Write some content!)


+        public interface IWriter { }
+        public interface IReader { }
+
+        public class StatefulCache : IReader, IWriter
+        {
+            
+        }
+

What we need from StructureMap is a way to make all requests to either IReader and IWriter +resolve to the same singleton object instance of StatefulCache.

StructureMap provides the Forward<TFrom, TTo>() mechanism for exactly this purpose:


+        [Test]
+        public void stateful_cache_serves_multiple_interfaces()
+        {
+            var container = new Container(_ =>
+            {
+                // Let's make StatefulCache a singleton in the container
+                _.ForConcreteType<StatefulCache>().Configure.Singleton();
+
+                _.Forward<StatefulCache, IReader>();
+                _.Forward<StatefulCache, IWriter>();
+            });
+
+
+            container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
+            container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
+        }
+

And because the syntax has consistently been confusing to users (including me even though I wrote it), +here's how to effect the same registration with lambda registrations:


+        [Test]
+        public void equivalent()
+        {
+            var container = new Container(_ =>
+            {
+                // Let's make StatefulCache a singleton in the container
+                _.ForConcreteType<StatefulCache>().Configure.Singleton();
+
+                _.For<IReader>().Use(c => c.GetInstance<StatefulCache>());
+                _.For<IWriter>().Use(c => c.GetInstance<StatefulCache>());
+            });
+
+            container.GetInstance<IReader>().ShouldBeOfType<StatefulCache>();
+            container.GetInstance<IWriter>().ShouldBeOfType<StatefulCache>();
+        }
+

diff --git a/the-container/index.html b/the-container/index.html index c1178f4..f20f349 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -94,7 +94,7 @@

The Container

diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html new file mode 100644 index 0000000..69e21ea --- /dev/null +++ b/the-container/primitives/index.html @@ -0,0 +1,260 @@ + + + + + + + + StructureMap - Working with Primitive Types + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 3.1.6

+
+ + + +

Object Lifecycles

Fill Setter Dependencies of an Object Created Outside of StructureMap

+ + +

Working with Primitive Types

+ +

StructureMap treats simple types like strings, numbers of any kind, enumerations, and dates as primitive +types that are completely exempt from auto wiring -- meaning that any +constructor or setter dependencies on these types must be supplied as inline dependencies.

To make this concrete, if you ask StructureMap to build a concrete type that has dependencies on simple types without +like this example, StructureMap will throw an exception telling you that it cannot build the instance:


+        public class GuyWithNoDefaultName
+        {
+            // StructureMap will not use any kind of auto-wiring
+            // on name
+            public GuyWithNoDefaultName(string name)
+            {
+            }
+        }
+
+        [Test]
+        public void cannot_build_simple_arguments()
+        {
+            var container = new Container();
+
+            Exception<StructureMapBuildPlanException>.ShouldBeThrownBy(() =>
+            {
+                container.GetInstance<GuyWithNoDefaultName>();
+            });
+        }
+

Part of the exception message thrown in the unit test shown above is the erroneous build plan +showing you that the name parameter has to be defined:

+    new GuyWithNoDefaultName(String name)
+      ┗ String name = Required primitive dependency is not explicitly defined
+

We can build GuyWithNoDefaultName by supplying a value for name as I did in the following +sample:


+        [Test]
+        public void can_build_with_explicit_argument()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForConcreteType<GuyWithNoDefaultName>()
+                    .Configure.Ctor<string>("name").Is("Steve Winwood");
+            });
+
+            container.GetInstance<GuyWithNoDefaultName>()
+                .ShouldNotBeNull();
+        }
+

See Construction Policies for an example of using a constructor policy to set a dependency +on a "connectionString" argument in a conventional way.

Default Values

As a new feature in the 4.0 release, StructureMap can finally take advantage of default parameter arguments to +derive the values for a primitive argument (or setter value) while still allowing you to explicitly define +that parameter or setter value:


+        // I was listening to Jim Croce's "I've got a Name" song
+        // when I wrote this feature;)
+        public class GuyWithName
+        {
+            public GuyWithName(string name = "Jim Croce")
+            {
+                Name = name;
+            }
+
+            public string Name { get; set; }
+        }
+
+        [Test]
+        public void uses_the_default_value_if_one_exists()
+        {
+            var container = new Container();
+
+            // Should happily build with the default
+            // value of 'name'
+            container.GetInstance<GuyWithName>()
+                .Name.ShouldBe("Jim Croce");
+        }
+
+        [Test]
+        public void uses_the_default_value_if_one_exists_2()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForConcreteType<GuyWithName>();
+            });
+
+            // Should happily build with the default
+            // value of 'name'
+            container.GetInstance<GuyWithName>()
+                .Name.ShouldBe("Jim Croce");
+        }
+
+        [Test]
+        public void use_explicit_dependency_if_one_exists()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForConcreteType<GuyWithName>()
+                    .Configure.Ctor<string>("name").Is("Eric Clapton");
+            });
+
+            container.GetInstance<GuyWithName>()
+                .Name.ShouldBe("Eric Clapton");
+        }
+

+ + +

+ +

+ + + +

+ + + + + + + + + + + + + + + + + + diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index adcd681..25ba75b 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -46,7 +46,7 @@

@@ -103,7 +103,7 @@

Profiles and Child Containers

- Previous: Forwarding Requests for a Type to Another Type + Previous: Registering a Single Instance Against Multiple PluginType's diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index 0661ba3..80971a3 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -47,7 +47,7 @@

From c364a66de7c46b9b9e1cb87a8c123cccf2ec88f8 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Thu, 8 Oct 2015 10:56:53 -0500 Subject: [PATCH 13/55] Documentation Update --- generics/index.html | 69 +++++++++++++++++++ get-structuremap/index.html | 4 ++ interception-and-decorators/index.html | 3 +- the-container/lambdas/index.html | 44 ++++++++++++ .../index.html | 2 +- 5 files changed, 120 insertions(+), 2 deletions(-) diff --git a/generics/index.html b/generics/index.html index d289fe6..23f58c2 100644 --- a/generics/index.html +++ b/generics/index.html @@ -539,6 +539,75 @@

Example #2: Generic Instance Builder

IRepository<TDocument, TQuery> StructureMap.Testing.Acceptance Transient Build Repository<T, T1>() with RepositoryBuilder (Default) =================================================================================================================================================== +

Example 3: Interception Policy against Generic Types

Several years ago I described an approach for using an Event Aggregator in a WPF application that relied on StructureMap interception to register any object that +StructureMap built with the active EventAggregator for the system if that object was recognized as a listener to the event aggregator. I thought that approach worked out quite well, so let's talk about how you could implement +that same design with the improved interception model introduced by StructureMap 3.0 (the event aggregator and StructureMap interception worked out well, +but I'm very happy now that I ditched the old WPF client and replaced it with a web application using React.js instead).

First off, let's say that we're going to have this interface for our event aggregator:


+    public interface IEventAggregator
+    {
+        // Sending messages
+        void SendMessage<T>(T message);
+        void SendMessage<T>() where T : new();
+
+        // Explicit registration
+        void AddListener(object listener);
+        void RemoveListener(object listener);
+    }
+

To register a listener for a particular type of event notification, you would implement an interface called IListener<T> shown below +and directly add that object to the IEventAggregator:


+    public interface IListener<T>
+    {
+        void Handle(T message);
+    }
+

What we want to do though is have an interception policy that only applies to any concrete type that implements some interface that +closes IListener<T>:


+    public class EventListenerRegistration : IInterceptorPolicy
+    {
+        public string Description
+        {
+            get { return "Adds the constructed object to the EventAggregator"; }
+        }
+
+        public IEnumerable<IInterceptor> DetermineInterceptors(Type pluginType, Instance instance)
+        {
+            if (instance.ReturnedType.FindInterfacesThatClose(typeof (IListener<>)).Any())
+            {
+                Expression<Action<IContext, object>> register =
+                    (c, o) => c.GetInstance<IEventAggregator>().AddListener(o);
+                yield return new ActivatorInterceptor<object>(register);
+            }
+        }
+    }
+

To see our new interception policy in action, see this unit test from GitHub:


+        [Test]
+        public void use_the_event_listener_registration()
+        {
+            var container = new Container(x =>
+            {
+                x.Policies.Interceptors(new EventListenerRegistration());
+                x.For<IEventAggregator>().Use<EventAggregator>().Singleton();
+            });
+
+            var events = container.GetInstance<IEventAggregator>();
+            var listener = container.GetInstance<BooMessageListener>();
+
+            var message = new BooMessage();
+
+            events.SendMessage(message);
+
+            listener.Messages.Single().ShouldBeTheSameAs(message);
+        }
+

diff --git a/get-structuremap/index.html b/get-structuremap/index.html index e39aac6..28effaf 100644 --- a/get-structuremap/index.html +++ b/get-structuremap/index.html @@ -103,6 +103,10 @@

Binaries

Binaries of StructureMap are available via NuGet:

PM> Install-Package StructureMap

or if you need a strong named version of StructureMap:

PM> Install-Package structuremap-signed
+

The StructureMap team believes strong naming to be a blight upon the .Net land and we really wish folks would quit using it, but we understand that some circumstances absolutely require it.

Source

StructureMap's source is hosted on GitHub. If you want to fix a bug or just want to tinker with an idea, we love receiving pull requests! Start by creating your own fork on Github.

The StructureMap build tooling has recently changed. See the GitHub README for more information on how to build and work with the StructureMap codebase.

diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html index 0fc32b1..8e12639 100644 --- a/interception-and-decorators/index.html +++ b/interception-and-decorators/index.html @@ -94,7 +94,8 @@

Interception and Decorators

All of the samples from this topic are part of the user acceptance tests in the main codebase.

Improving the interception facilities and the means of applying decorators during object construction was one of the primary goals of the big 3.0 release and is significantly different than the older 2.5/2.6 model.

Interception in StructureMap really comes diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html index 22cc6fe..f417dc1 100644 --- a/the-container/lambdas/index.html +++ b/the-container/lambdas/index.html @@ -93,6 +93,50 @@

Building Objects with Lambdas

Instead of allowing StructureMap to build objects directly, you can give a StructureMap Container a Lambda function that can be called to create an object at resolution time.

Using NHibernate's ISession as an example +of an object that typically has to be built by using an ISessionFactory object:


+    public interface ISession { }
+
+    public interface ISessionFactory
+    {
+        ISession Build();
+    }
+

If we want to allow StructureMap to control the ISession lifecycle and creation, we have to register a Lambda function as the +means of creating ISession as shown in this example below:


+    public class SessionFactoryRegistry : Registry
+    {
+        // Let's not worry about how ISessionFactory is built
+        // in this example
+        public SessionFactoryRegistry(ISessionFactory factory)
+        {
+            For<ISessionFactory>().Use(factory);
+
+            // Build ISession with a lambda:
+            For<ISession>().Use("Build ISession from ISessionFactory", c =>
+            {
+                // To resolve ISession, I first pull out
+                // ISessionFactory from the IContext and use that
+                // to build a new ISession. 
+                return c.GetInstance<ISessionFactory>().Build();
+            });
+        }
+    }
+

Lambda registrations can be done with any of the following four signatures:

(Expression<Func<IContext, T>> builder) -- a simple, one line Lambda to build T using IContext
(Expression<Func<T>> func) -- a simple, one line Lambda to build T
(string description, Func<IContext, T> builder) -- use IContext in your builder Lambda with a user-supplied description for diagnostics
(string description, Func<T> builder) -- Supply a complex Func<T> with a user-supplied description for diagnostics

Be very wary of the difference between legal Expression's and more complicated Lambda's that will need to be Func's. It likely doesn't matter to +you the user, but it unfortunately does to StructureMap and .Net itself. If you need to use a more complex Func, you will have +to supply a diagnostic description.

See Working with the IContext at Build Time for more information.

diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html index 80971a3..fdb87e7 100644 --- a/the-container/working-with-the-icontext-at-build-time/index.html +++ b/the-container/working-with-the-icontext-at-build-time/index.html @@ -312,7 +312,7 @@

Example 2: NHibernate Integration

{ For<ISessionFactory>().Use(factory); - + // Build ISession with a lambda: For<ISession>().Use("Build ISession from ISessionFactory", c => { // To resolve ISession, I first pull out From 52cbe0db7b22fd8a5a88d8beea1881ea94621d42 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Fri, 9 Oct 2015 09:55:38 -0500 Subject: [PATCH 14/55] Documentation Update --- best-practices/index.html | 6 +- .../using-the-container-model/index.html | 8 +- documentation/index.html | 2 +- history/index.html | 6 +- .../configuring-lifecycles/index.html | 14 +- object-lifecycle/index.html | 244 +-------- .../supported-lifecycles/index.html | 518 +----------------- registration/attributes/index.html | 178 ++++++ registration/configured-instance/index.html | 2 +- registration/policies/index.html | 2 +- the-container/auto-wiring/index.html | 6 +- .../index.html | 4 +- the-container/index.html | 8 +- the-container/nested-containers/index.html | 6 +- 14 files changed, 248 insertions(+), 756 deletions(-) diff --git a/best-practices/index.html b/best-practices/index.html index e4fcaa1..0e4afad 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -47,7 +47,7 @@

@@ -79,7 +79,7 @@

StructureMap 3.1.6

FAQ

History

Internals and Architecture

@@ -108,7 +108,7 @@

Best Practices

- Next: FAQ + Next: History diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html index 5f01e1f..dd39001 100644 --- a/diagnostics/using-the-container-model/index.html +++ b/diagnostics/using-the-container-model/index.html @@ -134,7 +134,7 @@

Ejecting Services and/or Configuration

To remove and dispose previously built singleton scoped objects from a Container, use this code:


-            // ONLY ejects any built object for this Instance from the singleton
+            // ONLY ejects any built object for this Instance from the SingletonThing
             // cache
             container.Model.For<IDevice>().Default.EjectObject();

@@ -186,13 +186,13 @@

Working with Individual Instances

// the type specified to the Get() method instance.Get<IDevice>().ShouldBeOfType<DefaultDevice>(); - // if the instance is configured as a singleton, test - // if the singleton object has already been created + // if the instance is configured as a SingletonThing, test + // if the SingletonThing object has already been created var hasSingletonBeenCreated = instance.ObjectHasBeenCreated(); if (hasSingletonBeenCreated) { - // remove the singleton object from the cache so that + // remove the SingletonThing object from the cache so that // StructureMap will be forced to rebuild this object instance.EjectObject(); } diff --git a/documentation/index.html b/documentation/index.html index 826f878..a0863ca 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/history/index.html b/history/index.html index 3492fda..e8c93c6 100644 --- a/history/index.html +++ b/history/index.html @@ -46,7 +46,7 @@

@@ -112,7 +112,7 @@

History

- Previous: FAQ + Previous: Best Practices diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html index 93b18e5..8b54ac5 100644 --- a/object-lifecycle/configuring-lifecycles/index.html +++ b/object-lifecycle/configuring-lifecycles/index.html @@ -129,7 +129,7 @@

Configuring Lifecycles

container.Model.For<Rule>().Lifecycle.ShouldBeOfType<SingletonLifecycle>(); container.Model.For<Rule>().Find("C").Lifecycle.ShouldBeOfType<SingletonLifecycle>(); - // 'C' is the default lifecycle for Rule (Singleton) + // 'C' is the default lifecycle for Rule (SingletonThing) container.GetInstance<Rule>("C") .ShouldBeTheSameAs(container.GetInstance<Rule>("C")); @@ -146,6 +146,18 @@

Configuring Lifecycles

} +

Using Attributes

New in StructureMap 4.0 are some simple attributes to mark either a complete Plugin Type or a single Instance as either +a singleton or using the always unique lifecycle:

The usage is shown below:


+    [AlwaysUnique]
+    public interface IShouldBeUnique { }
+
+    [Singleton] // because the most wonderful thing about Tiggers is that I'm the only one....
+    public class Tigger { }
+

See Using Attributes for Configuration for information about adding your own custom attibutes for other lifecycles.

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index 7ed486a..473b021 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -1,228 +1,16 @@ - - - - - - - - StructureMap - Object Lifecycles - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

StructureMap 3.1.6

-
- - - -

Supported Lifecycles

The Container

- - -

Object Lifecycles

- -

- - -

One of the most valuable functions of using an IoC container tool is its ability to manage the object lifecycle (creating and disposing objects) and scoping (shared objects) -of your system's services so you can focus on the actual functionality instead of busy work.

Some services like data cache's and event aggregators in your system will need to be shared across requests, screens, and handlers. -Other services should be created new every time you ask the container for one. Another set of services need to be scoped to an HTTP request or a logical transaction such that -every request to the container for a service originating within the context of a single HTTP request gets the same object instance.

In all the cases above, StructureMap will assemble object graphs for you using the correct scoping of each dependency. Likewise, in some cases, StructureMap can help you -with object cleanup by calling IDisposable.Dispose() as appropriate when an object lifecyle is completed.

StructureMap isn't magic, you'll still need to be cognizant of the need for object cleanup. See the section on for more guidance.

Motivation for Container Managed Scope

In the bad old days, we used the infamous Singleton pattern -as shown below for objects that really needed to be scoped as one single instance for the entire system:


-    public class EvilSingleton
-    {
-        public static readonly EvilSingleton Instance = new EvilSingleton();
-
-        private EvilSingleton()
-        {
-        }
-
-        public void DoSomething()
-        {
-            // do something with the static data here
-        }
-    }
-
-
-    public class EvilSingletonUser
-    {
-        public void DoWork()
-        {
-            EvilSingleton.Instance.DoSomething();
-        }
-    }
-
-

Instead, let's just use StructureMap to handle the singleton scoping instead and rewrite the code sample above as:


-    public interface ISingletonDependency
-    {
-        void DoSomething();
-    }
-
-    public class Configuration : Registry
-    {
-        public Configuration()
-        {
-            // Tell StructureMap that all types
-            // of ISingletonDependency are
-            // to be scoped as "singletons"
-            For<ISingletonDependency>()
-                .Singleton();
-        }
-    }
-
-    // This version of the class just uses constructor 
-    // injection to get an object instance of
-    // ISingletonDependency. 
-    public class DependencyUser
-    {
-        private readonly ISingletonDependency _dependency;
-
-        public DependencyUser(ISingletonDependency dependency)
-        {
-            _dependency = dependency;
-        }
-    }
-
-

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +Error!

Error!

System.Collections.Generic.KeyNotFoundException: Key 'evil-singleton' could not be found
+   at FubuCore.Util.Cache`2.<.ctor>b__2(TKey key)
+   at FubuCore.Util.Cache`2.Fill(TKey key, Func`2 onMissing)
+   at ST.Docs.Samples.SampleCache.Find(String name)
+   at ST.Docs.DocProject.ST.Docs.Samples.ISampleCache.Find(String name)
+   at ST.Docs.Transformation.CodeSampleTransformHandler.Transform(Topic current, String data)
+   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
+   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
+   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
+   at ST.Docs.Transformation.Transformer.InnerTransformHandler.Transform(Topic current, String data)
+   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
+   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
+   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
+   at ST.Docs.Transformation.HtmlGenerator.generate(Topic topic)
+   at ST.Docs.Transformation.HtmlGenerator.Generate(Topic topic)

\ No newline at end of file diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index bf14302..0e05f35 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -1,502 +1,16 @@ - - - - - - - - StructureMap - Supported Lifecycles - - - - - - - - - - - - - - - - - - - -

- - - -

- -

- - -

StructureMap 3.1.6

-
- - - -

Configuring Lifecycles

Object Lifecycles

- - -

Supported Lifecycles

- -

- - -

Out of the box, the core StructureMap assembly supports these lifecycles:

Transient -- The default lifecycle. A new object is created for each logical request to resolve an object graph from the container.
Singleton -- Only one object instance will be created for the main Container
AlwaysUnique -- A new object instance is created every time, even within the same object graph
ThreadLocal -- Only one object instance will be created for the currently executing Thread

Transient

Transient lifecycle objects are only tracked and disposed if created by nested containers. If you resolve a transient object from the main application container, -it will not track the object created. While that behavior avoids the manual Release() method and potential memory leak found in other IoC containers like Windsor, it -puts the onus for disposing those objects on the user. The StructureMap team strongly recommends using nested containers for short -lived operations if disposing transient objects created by the Container is important.

The following unit test demonstrates how Transient lifecycles work in both root and nested containers.


-        [Test]
-        public void Transient()
-        {
-            var c = new Container(x => { x.For<IService>().Use<Service>().Transient(); });
-
-            // In a normal container, you get a new object
-            // instance of the Service class in subsequent
-            // requests
-            c.GetInstance<IService>()
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>())
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>());
-
-            // Within a nested container, 'Transient' now 
-            // means within the Nested Container.
-            // A nested container is effectively one request
-            using (var nested = c.GetNestedContainer())
-            {
-                nested.GetInstance<IService>()
-                    .ShouldBeTheSameAs(nested.GetInstance<IService>())
-                    .ShouldBeTheSameAs(nested.GetInstance<IService>());
-            }
-        }
-
-


-        public interface IUnitOfWork
-        {
-        }
-
-        public class DefaultUnitOfWork : IUnitOfWork
-        {
-        }
-
-        public class Worker1
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker1(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class Worker2
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker2(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class WorkerCoordinator
-        {
-            public IUnitOfWork Uow { get; set; }
-            public Worker1 Worker1 { get; set; }
-            public Worker2 Worker2 { get; set; }
-
-            public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
-            {
-                Uow = uow;
-                Worker1 = worker1;
-                Worker2 = worker2;
-            }
-        }
-
-        [Test]
-        public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
-        {
-            var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });
-
-            var cooridinator = container.GetInstance<WorkerCoordinator>();
-
-            // The IUnitOfWork object instance is the same for
-            // all the objects in the object graph that had
-            // a constructor dependency on IUnitOfWork
-            cooridinator.Uow
-                .ShouldBeTheSameAs(cooridinator.Worker1.Uow);
-
-            cooridinator.Uow
-                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
-
-            cooridinator.Worker1.Uow
-                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
-        }
-
-

AlwaysUnique


-        [Test]
-        public void Always_Unique()
-        {
-            var c = new Container(x => { x.For<IService>().Use<Service>().AlwaysUnique(); });
-
-            // In a normal container, you get a new object
-            // instance of the Service class in subsequent
-            // requests
-            c.GetInstance<IService>()
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>())
-                .ShouldNotBeTheSameAs(c.GetInstance<IService>());
-
-            // Within a nested container, 'Transient' now 
-            // means within the Nested Container.
-            // A nested container is effectively one request
-            using (var nested = c.GetNestedContainer())
-            {
-                nested.GetInstance<IService>()
-                    .ShouldNotBeTheSameAs(nested.GetInstance<IService>())
-                    .ShouldNotBeTheSameAs(nested.GetInstance<IService>());
-            }
-
-            // Even in a single request, 
-            var holder = c.GetInstance<ServiceUserHolder>();
-            holder.Service.ShouldNotBeTheSameAs(holder.User.Service);
-        }
-
-

Singleton

StructureMap 3.0 fixed the dreaded singletons with nested container's bug that was so problematic in 2.6.


-        [Test]
-        public void singletons()
-        {
-            var c = new Container(x => { x.For<IService>().Use<Service>().Singleton(); });
-
-            // It's always the same object instance
-            c.GetInstance<IService>()
-                .ShouldBeTheSameAs(c.GetInstance<IService>())
-                .ShouldBeTheSameAs(c.GetInstance<IService>())
-                .ShouldBeTheSameAs(c.GetInstance<IService>())
-                .ShouldBeTheSameAs(c.GetInstance<IService>())
-                .ShouldBeTheSameAs(c.GetInstance<IService>());
-        }
-
-

Do note that objects created as the singleton scope will be disposed when the Container is disposed if they -implement the IDisposable interface:


-        public interface IUnitOfWork
-        {
-        }
-
-        public class DefaultUnitOfWork : IUnitOfWork
-        {
-        }
-
-        public class Worker1
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker1(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class Worker2
-        {
-            public IUnitOfWork Uow { get; set; }
-
-            public Worker2(IUnitOfWork uow)
-            {
-                Uow = uow;
-            }
-        }
-
-        public class WorkerCoordinator
-        {
-            public IUnitOfWork Uow { get; set; }
-            public Worker1 Worker1 { get; set; }
-            public Worker2 Worker2 { get; set; }
-
-            public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
-            {
-                Uow = uow;
-                Worker1 = worker1;
-                Worker2 = worker2;
-            }
-        }
-
-        [Test]
-        public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
-        {
-            var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });
-
-            var cooridinator = container.GetInstance<WorkerCoordinator>();
-
-            // The IUnitOfWork object instance is the same for
-            // all the objects in the object graph that had
-            // a constructor dependency on IUnitOfWork
-            cooridinator.Uow
-                .ShouldBeTheSameAs(cooridinator.Worker1.Uow);
-
-            cooridinator.Uow
-                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
-
-            cooridinator.Worker1.Uow
-                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
-        }
-
-

ThreadLocal

The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test:


-    [TestFixture]
-    public class ThreadLocalStorageLifecycleTester
-    {
-        #region Setup/Teardown
-
-        [SetUp]
-        public void SetUp()
-        {
-            _lifecycle = new ThreadLocalStorageLifecycle();
-
-            container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red")));
-        }
-
-        #endregion
-
-        private ThreadLocalStorageLifecycle _lifecycle;
-        private ColorRule _rule1;
-        private ColorRule _rule2;
-        private ColorRule _rule3;
-        private Container container;
-
-
-        private void findRule1()
-        {
-            _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-
-            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule1.ShouldBeTheSameAs(rule);
-        }
-
-        private void findRule2()
-        {
-            _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-
-            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule2.ShouldBeTheSameAs(rule);
-        }
-
-        private void findRule3()
-        {
-            _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-
-            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-
-            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-
-            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-
-            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
-            _rule3.ShouldBeTheSameAs(rule);
-        }
-
-        [Test]
-        public void object_has_been_created()
-        {
-            container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse();
-            var r1 = container.GetInstance<Rule>();
-            container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue();
-        }
-
-        [Test]
-        public void FindUniqueInstancePerThread()
-        {
-            var t1 = new Thread(findRule1);
-            var t2 = new Thread(findRule2);
-            var t3 = new Thread(findRule3);
-
-            t1.Start();
-            t2.Start();
-            t3.Start();
-
-            t1.Join();
-            t2.Join();
-            t3.Join();
-
-            _rule1.ShouldNotBeTheSameAs(_rule2);
-            _rule1.ShouldNotBeTheSameAs(_rule3);
-            _rule2.ShouldNotBeTheSameAs(_rule3);
-            (_rule1.ID != _rule2.ID).ShouldBeTrue();
-            (_rule1.ID != _rule3.ID).ShouldBeTrue();
-            (_rule2.ID != _rule3.ID).ShouldBeTrue();
-        }
-    }
-
-

Legacy ASP.Net Lifecycles

In addition, the StructureMap.Web package adds the legacy ASP.Net related lifecycles for:

HttpContext
HttpSession (requires objects to be Serializable, not recommended but still present for legacy code
Hybrid -- uses ThreadLocalStorage in the absence of an active HttpContext
HybridSession


-    public class AspNetRegistry : Registry
-    {
-        public AspNetRegistry()
-        {
-            For<IWeirdThing>().LifecycleIs<HttpContextLifecycle>();
-            For<IGateway>().LifecycleIs<HybridLifecycle>();
-            For<IRule>().LifecycleIs<HttpSessionLifecycle>();
-            For<ICache>().LifecycleIs<HybridSessionLifecycle>();
-        }
-    }
-
-

If you do use any of the HttpContext lifecycles, make sure you also do:


-            HttpContextLifecycle.DisposeAndClearAll();
-

at the end of your HTTP request.

- - -

- -

- - - -

- - - - - - - - - - - - - - - - - - + +Error!

Error!

System.Collections.Generic.KeyNotFoundException: Key 'singleton-in-action' could not be found
+   at FubuCore.Util.Cache`2.<.ctor>b__2(TKey key)
+   at FubuCore.Util.Cache`2.Fill(TKey key, Func`2 onMissing)
+   at ST.Docs.Samples.SampleCache.Find(String name)
+   at ST.Docs.DocProject.ST.Docs.Samples.ISampleCache.Find(String name)
+   at ST.Docs.Transformation.CodeSampleTransformHandler.Transform(Topic current, String data)
+   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
+   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
+   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
+   at ST.Docs.Transformation.Transformer.InnerTransformHandler.Transform(Topic current, String data)
+   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
+   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
+   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
+   at ST.Docs.Transformation.HtmlGenerator.generate(Topic topic)
+   at ST.Docs.Transformation.HtmlGenerator.Generate(Topic topic)

\ No newline at end of file diff --git a/registration/attributes/index.html b/registration/attributes/index.html index 75ee8a2..79bf578 100644 --- a/registration/attributes/index.html +++ b/registration/attributes/index.html @@ -93,6 +93,184 @@

Using Attributes for Configuration

In the early days of StructureMap we had several attibutes for basic configuration that we'd just as soon +forget ever existed. Further more, the StructureMap strongly believes that the usage of StructureMap should +have as little impact on application code as possible -- and forcing users to spray .Net attributes all over +their own code is in clear violation of this philosophy. In other words, we don't want to be MEF.

That being said, there are plenty of times when simple attribute usage is effective for one-off deviations from +your normal registration conventions or cause less harm than having to constantly change a centralized Registry or +just seem more clear and understandable to users than a convention. For those usages, StructureMap 4.0 has introduced a +new base class that can be extended and used to explicitly customize your StructureMap configuration:


+    /// <summary>
+    /// Base class for custom configuration attributes
+    /// </summary>
+    public abstract class StructureMapAttribute : Attribute
+    {
+        /// <summary>
+        /// Override this method to apply a configuration change to an entire
+        /// PluginFamily (every Instance of a certain PluginType)
+        /// </summary>
+        /// <param name="family"></param>
+        public virtual void Alter(PluginFamily family)
+        {
+        }
+
+        /// <summary>
+        /// Make configuration alterations to a single IConfiguredInstance object
+        /// </summary>
+        /// <param name="instance"></param>
+        public virtual void Alter(IConfiguredInstance instance)
+        {
+        }
+
+        /// <summary>
+        /// Apply configuration customization to a single setter property
+        /// </summary>
+        /// <param name="instance"></param>
+        /// <param name="property"></param>
+        public virtual void Alter(IConfiguredInstance instance, PropertyInfo property)
+        {
+        }
+
+        /// <summary>
+        /// Apply configuration customization for a single constructor parameter
+        /// </summary>
+        /// <param name="instance"></param>
+        /// <param name="parameter"></param>
+        public virtual void Alter(IConfiguredInstance instance, ParameterInfo parameter)
+        {
+        }
+    }
+

There's a couple thing to note, here about this new attibute:

StructureMap internals are looking for any attribute of the base class. Attributes that affect types are read and applied early, +while attributes decorating properties or constructor parameters are only read and applied during the creation of Build Plans.
Unlike many other frameworks, the attributes in StructureMap are not executed at build time. Instead, StructureMap uses attributes one time +to determine the build plan.

Attribute Targeting Plugin Type or Concrete Type

Take the new [Singleton] attribute shown below:


+    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface)]
+    public class SingletonAttribute : StructureMapAttribute
+    {
+        // This method will affect the configuration for the
+        // entire plugin type
+        public override void Alter(PluginFamily family)
+        {
+            family.SetLifecycleTo<SingletonLifecycle>();
+        }
+
+        // This method will affect single registrations
+        public override void Alter(IConfiguredInstance instance)
+        {
+            instance.SetLifecycleTo<SingletonLifecycle>();
+        }
+    }
+

This new attribute can be used on either the plugin type (typically an interface) or on a concrete type +to make an individual type registration be a singleton. You can see the usage on some types below:


+        [Singleton] // ALL Instance's of ITeamCache will be singletons by default
+        public interface ITeamCache { }
+
+        public class TeamCache : ITeamCache { }
+        public class OtherTeamCache : ITeamCache { }
+
+        public interface ITeam { }
+
+        public class Chargers : ITeam { }
+
+        [Singleton] // This specific type will be a singleton
+        public class Chiefs : ITeam { }
+

Attribute Targeting Constructor Parameters or Setter Properties

As an example, let's say that you want a new attribute type that can decorate either properties or constructor parameters +to say "use the value from the old .Net AppSettings collection as the value for this property/parameter." To build that new +custom attribute, you would create a new attribute that subclasses StructureMapAttribute and override the two methods shown below:


+        public class AppSettingAttribute : StructureMapAttribute
+        {
+            private readonly string _key;
+
+            public AppSettingAttribute(string key)
+            {
+                _key = key;
+            }
+
+            public override void Alter(IConfiguredInstance instance, PropertyInfo property)
+            {
+                var value = System.Configuration.ConfigurationManager.AppSettings[_key];
+
+                instance.Dependencies.AddForProperty(property, value);
+            }
+
+            public override void Alter(IConfiguredInstance instance, ParameterInfo parameter)
+            {
+                var value = System.Configuration.ConfigurationManager.AppSettings[_key];
+
+                instance.Dependencies.AddForConstructorParameter(parameter, value);
+            }
+        }
+

To test out the new attribute above, say we have a concrete type like this one that we +decorate with the new [AppSetting] attribute:


+        public class AppSettingTarget
+        {
+            public string Name { get; set; }
+
+            [AppSetting("homestate")]
+            public string HomeState { get; set; }
+
+            public AppSettingTarget([AppSetting("name")]string name)
+            {
+                Name = name;
+            }
+        }
+

The following unit test demonstrates our new custom [AppSetting] attribute in action:


+        [Test]
+        public void using_parameter_and_property_attibutes()
+        {
+            System.Configuration.ConfigurationManager.AppSettings["name"] = "Jeremy";
+            System.Configuration.ConfigurationManager.AppSettings["homestate"] = "Missouri";
+
+            System.Configuration.ConfigurationManager.AppSettings["name"].ShouldBe("Jeremy");
+
+            var container = new Container();
+
+            var target = container.GetInstance<AppSettingTarget>();
+
+            target.Name.ShouldBe("Jeremy");
+            target.HomeState.ShouldBe("Missouri");
+
+            Debug.WriteLine(container.Model.For<AppSettingTarget>().Default.DescribeBuildPlan());
+        }
+

The build plan for AppSettingTarget is determined by the active StructureMap +container to be this:

+PluginType: StructureMap.Testing.Acceptance.attribute_usage+AppSettingTarget
+Lifecycle: Transient
+new AppSettingTarget(String name)
+  ┗ String name = Value: Jeremy
+Set String HomeState = Value: Missouri
+

Note that the values retrieved from AppSettings are essentially hard coded into the underlying builder function that StructureMap compiled for +AppSettingTarget. You could instead add a "lambda builder" dependency so that StructureMap had to +use the live value for AppSettings as it constructs objects.

Built In Attributes

StructureMap supplies a handful of built in attributes for customizing configuration:

[ValidationMethod] - Allows you to expose Environment Tests in your StructureMap registrations
[SetterProperty] - See Setter Injection
[DefaultConstructor] - Declare which constructor function should be used by StructureMap. See Constructor Selection for more information
[AlwaysUnique] and [Singleton] - These attributes, new for StructureMap 4.0, just add another mechanism for lifecycle configuration

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html index 27da2d0..6fdef5b 100644 --- a/registration/configured-instance/index.html +++ b/registration/configured-instance/index.html @@ -173,7 +173,7 @@

Changing the Instance Lifecycle

IConfiguredInstance instance = new ConfiguredInstance(typeof(WidgetHolder)); - // Use the singleton lifecycle + // Use the SingletonThing lifecycle instance.Singleton(); // or supply an ILifecycle type diff --git a/registration/policies/index.html b/registration/policies/index.html index d0e8907..a923d42 100644 --- a/registration/policies/index.html +++ b/registration/policies/index.html @@ -383,7 +383,7 @@

Example 3: Make objects singletons based on type name

.ShouldBeTheSameAs(container.GetInstance<IWidgets>()); // Now that the policy has executed, we - // can verify that WidgetCache is a singleton + // can verify that WidgetCache is a SingletonThing container.Model.For<IWidgets>().Default .Lifecycle.ShouldBeOfType<SingletonLifecycle>(); } diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html index 5413b6c..e67c69e 100644 --- a/the-container/auto-wiring/index.html +++ b/the-container/auto-wiring/index.html @@ -46,7 +46,7 @@

@@ -169,7 +169,7 @@

Auto Wiring

- Previous: StructureMap Assumptions + Previous: The Container diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html index 411ee7b..b2b5ea1 100644 --- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html +++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html @@ -119,7 +119,7 @@

Registering a Single Instance Against Multiple PluginType's

{ var container = new Container(_ => { - // Let's make StatefulCache a singleton in the container + // Let's make StatefulCache a SingletonThing in the container _.ForConcreteType<StatefulCache>().Configure.Singleton(); _.For<IReader>().Use(c => c.GetInstance<StatefulCache>()); diff --git a/the-container/index.html b/the-container/index.html index f20f349..c5427d5 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -47,7 +47,7 @@

diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html index 411ac1c..570e36c 100644 --- a/the-container/nested-containers/index.html +++ b/the-container/nested-containers/index.html @@ -196,7 +196,7 @@

Lifecycle Rules

var singleton = container.GetInstance<IColorCache>(); - // Singleton's are resolved from the parent container + // SingletonThing's are resolved from the parent container using (var nested = container.GetNestedContainer()) { nested.GetInstance<IColorCache>() @@ -320,7 +320,7 @@

Disposing Services

{ var container = new Container(_ => { - // A singleton scoped service + // A SingletonThing scoped service _.ForSingletonOf<IColorCache>().Use<ColorCache>(); // A transient scoped service @@ -333,7 +333,7 @@

Disposing Services

using (var nested = container.GetNestedContainer()) { - // Singleton's are really built by the parent + // SingletonThing's are really built by the parent singleton = nested.GetInstance<IColorCache>() .ShouldBeOfType<ColorCache>(); From ce8e5e52e68a252b0a7c5511d3f53b05dd4d7aac Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Fri, 9 Oct 2015 09:56:23 -0500 Subject: [PATCH 15/55] Doc refresh for attributes --- diagnostics/type-scanning/index.html | 0 generics/index.html | 0 index.html | 0 instances/index.html | 0 registration/attributes/index.html | 0 registration/clear-or-replace/index.html | 0 registration/configured-instance/index.html | 0 registration/policies/index.html | 0 setter-injection/index.html | 0 the-container/buildup/index.html | 0 the-container/lambdas/index.html | 0 the-container/primitives/index.html | 0 12 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 diagnostics/type-scanning/index.html mode change 100644 => 100755 generics/index.html mode change 100644 => 100755 index.html mode change 100644 => 100755 instances/index.html mode change 100644 => 100755 registration/attributes/index.html mode change 100644 => 100755 registration/clear-or-replace/index.html mode change 100644 => 100755 registration/configured-instance/index.html mode change 100644 => 100755 registration/policies/index.html mode change 100644 => 100755 setter-injection/index.html mode change 100644 => 100755 the-container/buildup/index.html mode change 100644 => 100755 the-container/lambdas/index.html mode change 100644 => 100755 the-container/primitives/index.html diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100644 new mode 100755 diff --git a/generics/index.html b/generics/index.html old mode 100644 new mode 100755 diff --git a/index.html b/index.html old mode 100644 new mode 100755 diff --git a/instances/index.html b/instances/index.html old mode 100644 new mode 100755 diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100644 new mode 100755 diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100644 new mode 100755 diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100644 new mode 100755 diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100644 new mode 100755 diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100644 new mode 100755 diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html old mode 100644 new mode 100755 diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100644 new mode 100755 diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100644 new mode 100755 From dd87ab90baf0b8e61506e011bf9b415f9061077c Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Fri, 9 Oct 2015 10:35:57 -0500 Subject: [PATCH 16/55] Documentation Update --- diagnostics/type-scanning/index.html | 0 generics/index.html | 0 index.html | 0 instances/index.html | 0 registration/attributes/index.html | 0 registration/clear-or-replace/index.html | 55 +++++++++++++++++++++ registration/configured-instance/index.html | 0 registration/policies/index.html | 0 setter-injection/index.html | 0 the-container/buildup/index.html | 0 the-container/lambdas/index.html | 0 the-container/primitives/index.html | 0 12 files changed, 55 insertions(+) mode change 100755 => 100644 diagnostics/type-scanning/index.html mode change 100755 => 100644 generics/index.html mode change 100755 => 100644 index.html mode change 100755 => 100644 instances/index.html mode change 100755 => 100644 registration/attributes/index.html mode change 100755 => 100644 registration/clear-or-replace/index.html mode change 100755 => 100644 registration/configured-instance/index.html mode change 100755 => 100644 registration/policies/index.html mode change 100755 => 100644 setter-injection/index.html mode change 100755 => 100644 the-container/buildup/index.html mode change 100755 => 100644 the-container/lambdas/index.html mode change 100755 => 100644 the-container/primitives/index.html diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100755 new mode 100644 diff --git a/generics/index.html b/generics/index.html old mode 100755 new mode 100644 diff --git a/index.html b/index.html old mode 100755 new mode 100644 diff --git a/instances/index.html b/instances/index.html old mode 100755 new mode 100644 diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100755 new mode 100644 diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100755 new mode 100644 index 176b599..a34d9bf --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -93,6 +93,61 @@

Replace or Clear Out Previous Registrations

Several members of the StructureMap team were also very active in a now semi-defunct web framework called FubuMVC +that was built with quite a bit of extensibility in mind. One of the extensibility mechanisms that was successful in FubuMVC was the ability for applications or addon libraries to swap out the default services in the main StructureMap application container.

The approach we took for this extensibility was what I flippantly call the "Mongolian BBQ" architecture. The framework should take the application specific registrations, the framework defaults, and all the discovered addons and figure out how to order the registrations to enforce the following levels of registration precedence:

The application specific registrations should always win out
Package or extension specific overrides
Default framework service registrations

To make this kind of modular and adaptive registration work, FubuMVC introduced a couple concepts that we've now pulled back into StructureMap:

The Fallback Services introduced in the previous topic where you can make a registration that effectively tells StructureMap to "use this registration if nobody else tells you something differently".
The new Registry.For().ClearAll() mechanism shown in this topic that tells StructureMap to "disregard what everyone else said to use".

Typically in FubuMVC, we would use fallback service registrations for most of the framework defaults and occasionally use the ClearAll() type mechanics down the line as an analogue to the CSS !important keyword to make a particular registration take precedence in the face of multiple registrations.

In usage, let's say that our application needs some type of IWidget service to run. For an important client, they want to deploy our system with +a special version, so we will create a new StructureMap Registry to apply their specific registrations using the ClearAll() mechanism to +insure that the important client gets their way:


+        public class ImportantClientWidget : IWidget { }
+
+        public class ImportantClientServices : Registry
+        {
+            public ImportantClientServices()
+            {
+                For<IWidget>().ClearAll().Use<ImportantClientWidget>();
+            }
+        }
+

In usage, the ClearAll() stomps all over the default registration before adding their own:


+        [Test]
+        public void clear_all_in_action()
+        {
+            var container = new Container(_ =>
+            {
+                _.For<IWidget>().Use<AWidget>();
+
+                
+                _.IncludeRegistry<ImportantClientServices>();
+            });
+
+            container.GetInstance<IWidget>()
+                .ShouldBeOfType<ImportantClientWidget>();
+
+            Debug.WriteLine(container.WhatDoIHave(pluginType:typeof(IWidget)));
+        }
+

If you were to check the WhatDoIHave() view for IWidget, you would see only the ImportantClientWidget:

+==============================================================================================================================================
+PluginType     Namespace                           Lifecycle     Description                                                         Name     
+----------------------------------------------------------------------------------------------------------------------------------------------
+IWidget        StructureMap.Testing.Acceptance     Transient     StructureMap.Testing.Acceptance.clear_all+ImportantClientWidget     (Default)
+==============================================================================================================================================
+

diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100755 new mode 100644 diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100755 new mode 100644 diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100755 new mode 100644 diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html old mode 100755 new mode 100644 diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100755 new mode 100644 diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100755 new mode 100644 From d81186a46715908880dc11ec6bdccecb20259744 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Fri, 9 Oct 2015 11:29:38 -0500 Subject: [PATCH 17/55] Documentation Update --- architecture/index.html | 2 +- best-practices/index.html | 2 +- diagnostics/build-plans/index.html | 2 +- diagnostics/environment-tests/index.html | 2 +- diagnostics/index.html | 2 +- diagnostics/type-scanning/index.html | 2 +- .../using-the-container-model/index.html | 2 +- .../index.html | 2 +- diagnostics/whatdoihave/index.html | 2 +- documentation/index.html | 4 +- features/index.html | 2 +- generics/index.html | 2 +- get-structuremap/index.html | 2 +- glossary/index.html | 2 +- history/index.html | 2 +- instances/index.html | 2 +- integrations/index.html | 2 +- interception-and-decorators/index.html | 2 +- interpreting-exceptions/index.html | 2 +- .../configuring-lifecycles/index.html | 2 +- object-lifecycle/custom-lifecycles/index.html | 2 +- quickstart/index.html | 2 +- registration/attributes/index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- registration/clear-or-replace/index.html | 2 +- registration/configured-instance/index.html | 2 +- registration/constructor-selection/index.html | 2 +- registration/fallback-services/index.html | 2 +- registration/index.html | 2 +- registration/inline-dependencies/index.html | 2 +- .../on-missing-family-policies/index.html | 2 +- registration/policies/index.html | 2 +- registration/registry-dsl/index.html | 2 +- release-notes/index.html | 2 +- .../index.html | 2 +- .../get-a-service-by-plugintype/index.html | 2 +- .../index.html | 2 +- resolving/index.html | 2 +- .../passing-arguments-at-runtime/index.html | 2 +- .../requesting-a-concrete-type/index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- roadmap/index.html | 2 +- setter-injection/index.html | 2 +- software-design-concepts/index.html | 2 +- the-container/auto-wiring/index.html | 2 +- .../index.html | 2 +- .../index.html | 8 +- the-container/index.html | 4 +- the-container/lambdas/index.html | 2 +- the-container/nested-containers/index.html | 2 +- the-container/primitives/index.html | 8 +- .../profiles-and-child-containers/index.html | 2 +- .../working-with-enumerable-types/index.html | 105 +++++++++++++++++- .../index.html | 2 +- 56 files changed, 166 insertions(+), 65 deletions(-) diff --git a/architecture/index.html b/architecture/index.html index 750a125..758b204 100644 --- a/architecture/index.html +++ b/architecture/index.html @@ -72,7 +72,7 @@

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

@@ -280,7 +280,7 @@

Multi-Tenancy

- Next: Fill Setter Dependencies of an Object Created Outside of StructureMap + Next: Working with Primitive Types diff --git a/the-container/index.html b/the-container/index.html index c5427d5..807861f 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -72,7 +72,7 @@

StructureMap 3.1.6

StructureMap 4.0.0

The Container

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

Default Values

- Previous: Fill Setter Dependencies of an Object Created Outside of StructureMap + Previous: Handling Missing Named Instances diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index 25ba75b..10cc31b 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -72,7 +72,7 @@

StructureMap 3.1.6

StructureMap 4.0.0

StructureMap 3.1.6

StructureMap 4.0.0

Working with Enumerable Types

TODO(Write some content!)

While you can certainly use any IEnumerable type as a plugin type with your own explicit configuration, +StructureMap has some built in support for these specific enumerable types:

IEnumerable<T>
IList<T>
List<T>
ICollection<T>
T[]

Note, if there are not any registrations for whatever T is, you'll get an empty enumeration.

Here's an acceptance test from the StructureMap codebase that demonstrates this:


+        [Test]
+        public void collection_types_are_all_possible_by_default()
+        {
+            // NOTE that we do NOT make any explicit registration of 
+            // IList<IWidget>, IEnumerable<IWidget>, ICollection<IWidget>, or IWidget[]
+            var container = new Container(_ =>
+            {
+                _.For<IWidget>().Add<AWidget>();
+                _.For<IWidget>().Add<BWidget>();
+                _.For<IWidget>().Add<CWidget>();
+            });
+
+            // IList<T>
+            container.GetInstance<IList<IWidget>>()
+                .Select(x => x.GetType())
+                .ShouldHaveTheSameElementsAs(typeof (AWidget), typeof (BWidget), typeof (CWidget));
+
+            // ICollection<T>
+            container.GetInstance<ICollection<IWidget>>()
+                .Select(x => x.GetType())
+                .ShouldHaveTheSameElementsAs(typeof (AWidget), typeof (BWidget), typeof (CWidget));
+
+            // Array of T
+            container.GetInstance<IWidget[]>()
+                .Select(x => x.GetType())
+                .ShouldHaveTheSameElementsAs(typeof (AWidget), typeof (BWidget), typeof (CWidget));
+        }
+
+

And another showing how you can override this behavior with explicit configuration:


+        [Test]
+        public void override_enumeration_behavior()
+        {
+            var container = new Container(_ =>
+            {
+                _.For<IWidget>().Add<AWidget>();
+                _.For<IWidget>().Add<BWidget>();
+                _.For<IWidget>().Add<CWidget>();
+
+                // Explicit registration should have precedence over the default
+                // behavior
+                _.For<IWidget[]>().Use(new IWidget[] {new DefaultWidget()});
+            });
+
+            container.GetInstance<IWidget[]>()
+                .Single().ShouldBeOfType<DefaultWidget>();
+        }
+

Sample Usage: Validation Rules


+        public interface IWidgetValidator
+        {
+            IEnumerable<string> Validate(IWidget widget);
+        }
+
+        public class WidgetProcessor
+        {
+            private readonly IEnumerable<IWidgetValidator> _validators;
+
+            public WidgetProcessor(IEnumerable<IWidgetValidator> validators)
+            {
+                _validators = validators;
+            }
+
+            public void Process(IWidget widget)
+            {
+                var validationMessages = _validators.SelectMany(x => x.Validate(widget))
+                    .ToArray();
+
+
+                if (validationMessages.Any())
+                {
+                    // don't process the widget
+                }
+            }
+        }
+

By relying on StructureMap's IEnumerable behavior, we're able to split our IWidgetValidatior registration across multiple Registry classes and that's not infrequently useful to do.

StructureMap 3.1.6

StructureMap 4.0.0

Date: Fri, 9 Oct 2015 11:29:49 -0500 Subject: [PATCH 18/55] enumerable docs --- diagnostics/type-scanning/index.html | 0 generics/index.html | 0 index.html | 0 instances/index.html | 0 registration/attributes/index.html | 0 registration/clear-or-replace/index.html | 0 registration/configured-instance/index.html | 0 registration/policies/index.html | 0 setter-injection/index.html | 0 the-container/buildup/index.html | 0 the-container/lambdas/index.html | 0 the-container/primitives/index.html | 0 12 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 diagnostics/type-scanning/index.html mode change 100644 => 100755 generics/index.html mode change 100644 => 100755 index.html mode change 100644 => 100755 instances/index.html mode change 100644 => 100755 registration/attributes/index.html mode change 100644 => 100755 registration/clear-or-replace/index.html mode change 100644 => 100755 registration/configured-instance/index.html mode change 100644 => 100755 registration/policies/index.html mode change 100644 => 100755 setter-injection/index.html mode change 100644 => 100755 the-container/buildup/index.html mode change 100644 => 100755 the-container/lambdas/index.html mode change 100644 => 100755 the-container/primitives/index.html diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100644 new mode 100755 diff --git a/generics/index.html b/generics/index.html old mode 100644 new mode 100755 diff --git a/index.html b/index.html old mode 100644 new mode 100755 diff --git a/instances/index.html b/instances/index.html old mode 100644 new mode 100755 diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100644 new mode 100755 diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100644 new mode 100755 diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100644 new mode 100755 diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100644 new mode 100755 diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100644 new mode 100755 diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html old mode 100644 new mode 100755 diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100644 new mode 100755 diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100644 new mode 100755 From d909761f5726122e5bb4a829cb63ea8518fbf0fe Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Fri, 9 Oct 2015 11:43:24 -0500 Subject: [PATCH 19/55] Documentation Update --- diagnostics/type-scanning/index.html | 0 documentation/index.html | 2 +- generics/index.html | 0 index.html | 0 instances/index.html | 0 registration/attributes/index.html | 0 registration/clear-or-replace/index.html | 6 +- registration/configured-instance/index.html | 0 registration/existing-objects/index.html | 171 ++++++++++++++++++++ registration/fallback-services/index.html | 6 +- registration/policies/index.html | 0 setter-injection/index.html | 0 the-container/buildup/index.html | 0 the-container/lambdas/index.html | 0 the-container/primitives/index.html | 0 15 files changed, 178 insertions(+), 7 deletions(-) mode change 100755 => 100644 diagnostics/type-scanning/index.html mode change 100755 => 100644 generics/index.html mode change 100755 => 100644 index.html mode change 100755 => 100644 instances/index.html mode change 100755 => 100644 registration/attributes/index.html mode change 100755 => 100644 registration/clear-or-replace/index.html mode change 100755 => 100644 registration/configured-instance/index.html create mode 100644 registration/existing-objects/index.html mode change 100755 => 100644 registration/policies/index.html mode change 100755 => 100644 setter-injection/index.html mode change 100755 => 100644 the-container/buildup/index.html mode change 100755 => 100644 the-container/lambdas/index.html mode change 100755 => 100644 the-container/primitives/index.html diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100755 new mode 100644 diff --git a/documentation/index.html b/documentation/index.html index 83c5aec..c7121ef 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/generics/index.html b/generics/index.html old mode 100755 new mode 100644 diff --git a/index.html b/index.html old mode 100755 new mode 100644 diff --git a/instances/index.html b/instances/index.html old mode 100755 new mode 100644 diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100755 new mode 100644 diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100755 new mode 100644 index 1f5651a..ce0ca04 --- a/registration/clear-or-replace/index.html +++ b/registration/clear-or-replace/index.html @@ -46,7 +46,7 @@

Using Attributes for Configuration

Fallback Services

Registering Existing Objects

@@ -156,7 +156,7 @@

Replace or Clear Out Previous Registrations

- Previous: Fallback Services + Previous: Registering Existing Objects diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100755 new mode 100644 diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html new file mode 100644 index 0000000..6672581 --- /dev/null +++ b/registration/existing-objects/index.html @@ -0,0 +1,171 @@ + + + + + + + + StructureMap - Registering Existing Objects + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 4.0.0

+
+ + + +

Replace or Clear Out Previous Registrations

Fallback Services

+ +

+ + +

Registering Existing Objects

+ +

It's frequently common to register existing objects with a StructureMap Container and there are +overloads of the Registry.For().Use(object) and Registry.For().Add(object) methods to do just that:


+        [Test]
+        public void should_be_able_to_resolve_from_the_generic_family_expression()
+        {
+            var widget = new AWidget();
+            var container = new Container(x => x.For(typeof (IWidget)).Use(widget).Named("mine"));
+
+            container.GetInstance<IWidget>("mine").ShouldBeTheSameAs(widget);
+        }
+

Injecting an existing object into the Container makes it a de facto singleton, but the Container treats it with a +special scope called ObjectLifecycle if you happen to look into the WhatDoIHave() diagnostics.

StructureMap will attempt to call the IDisposable.Dispose() on any objects that are directly injected into a Container +that implement IDisposable when the Container itself is disposed.

+ + +

+ +

+ + + +

+ + + + + + + + + +

Replace or Clear Out Previous Registrations

Registering Existing Objects

Constructor Selection

@@ -189,7 +189,7 @@

Fallback Services

- Next: Replace or Clear Out Previous Registrations + Next: Registering Existing Objects diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100755 new mode 100644 diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100755 new mode 100644 diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html old mode 100755 new mode 100644 diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100755 new mode 100644 diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100755 new mode 100644 From 5a3111ae0c8c7b7c0a7f00201e47ee85688d029c Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Fri, 9 Oct 2015 11:43:42 -0500 Subject: [PATCH 20/55] docs for injecting objects --- diagnostics/type-scanning/index.html | 0 generics/index.html | 0 index.html | 0 instances/index.html | 0 registration/attributes/index.html | 0 registration/clear-or-replace/index.html | 0 registration/configured-instance/index.html | 0 registration/existing-objects/index.html | 0 registration/policies/index.html | 0 setter-injection/index.html | 0 the-container/buildup/index.html | 0 the-container/lambdas/index.html | 0 the-container/primitives/index.html | 0 13 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 diagnostics/type-scanning/index.html mode change 100644 => 100755 generics/index.html mode change 100644 => 100755 index.html mode change 100644 => 100755 instances/index.html mode change 100644 => 100755 registration/attributes/index.html mode change 100644 => 100755 registration/clear-or-replace/index.html mode change 100644 => 100755 registration/configured-instance/index.html mode change 100644 => 100755 registration/existing-objects/index.html mode change 100644 => 100755 registration/policies/index.html mode change 100644 => 100755 setter-injection/index.html mode change 100644 => 100755 the-container/buildup/index.html mode change 100644 => 100755 the-container/lambdas/index.html mode change 100644 => 100755 the-container/primitives/index.html diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100644 new mode 100755 diff --git a/generics/index.html b/generics/index.html old mode 100644 new mode 100755 diff --git a/index.html b/index.html old mode 100644 new mode 100755 diff --git a/instances/index.html b/instances/index.html old mode 100644 new mode 100755 diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100644 new mode 100755 diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100644 new mode 100755 diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100644 new mode 100755 diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html old mode 100644 new mode 100755 diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100644 new mode 100755 diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100644 new mode 100755 diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html old mode 100644 new mode 100755 diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100644 new mode 100755 diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100644 new mode 100755 From dba527ad32232744a82f567d306b5737820c3299 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Fri, 9 Oct 2015 14:48:02 -0500 Subject: [PATCH 21/55] Documentation Update --- diagnostics/type-scanning/index.html | 0 generics/index.html | 0 index.html | 0 instances/index.html | 0 registration/attributes/index.html | 0 .../index.html | 154 +++++++++++++++++- registration/clear-or-replace/index.html | 0 registration/configured-instance/index.html | 0 registration/existing-objects/index.html | 0 registration/policies/index.html | 0 setter-injection/index.html | 0 the-container/buildup/index.html | 0 the-container/lambdas/index.html | 0 the-container/primitives/index.html | 0 14 files changed, 151 insertions(+), 3 deletions(-) mode change 100755 => 100644 diagnostics/type-scanning/index.html mode change 100755 => 100644 generics/index.html mode change 100755 => 100644 index.html mode change 100755 => 100644 instances/index.html mode change 100755 => 100644 registration/attributes/index.html mode change 100755 => 100644 registration/clear-or-replace/index.html mode change 100755 => 100644 registration/configured-instance/index.html mode change 100755 => 100644 registration/existing-objects/index.html mode change 100755 => 100644 registration/policies/index.html mode change 100755 => 100644 setter-injection/index.html mode change 100755 => 100644 the-container/buildup/index.html mode change 100755 => 100644 the-container/lambdas/index.html mode change 100755 => 100644 the-container/primitives/index.html diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html old mode 100755 new mode 100644 diff --git a/generics/index.html b/generics/index.html old mode 100755 new mode 100644 diff --git a/index.html b/index.html old mode 100755 new mode 100644 diff --git a/instances/index.html b/instances/index.html old mode 100755 new mode 100644 diff --git a/registration/attributes/index.html b/registration/attributes/index.html old mode 100755 new mode 100644 diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html index e11eb85..67c5b9f 100644 --- a/registration/auto-registration-and-conventions/index.html +++ b/registration/auto-registration-and-conventions/index.html @@ -94,10 +94,44 @@

Auto-Registration and Conventions

StructureMap has rich support for registering types by scanning assemblies. +

StructureMap has rich support for registering types by scanning assemblies and applying conventional registrations. Between scanning and default conventions, configurations are often just a few lines.

Also see Type Scanning Diagnostics for help in understanding the assembly scanning behavior in your system.

Registry.Scan()

Assembly scanning operations are defined by the Registry.Scan() method demonstrated below:


+    public class BasicScanning : Registry
+    {
+        public BasicScanning()
+        {
+            Scan(_ =>
+            {
+                // Declare which assemblies to scan
+                _.Assembly("StructureMap.Testing");
+                _.AssemblyContainingType<IWidget>();
+
+                // Filter types
+                _.Exclude(type => type.Name.Contains("Bad"));
+
+                // A custom registration convention
+                _.Convention<MySpecialRegistrationConvention>();
+
+                // Built in registration conventions
+                _.AddAllTypesOf<IWidget>().NameBy(x => x.Name.Replace("Widget", ""));
+                _.WithDefaultConventions();
+            });
+        }
+    }
+

Please note (because I've been asked this several times over the years) that each call to Registry.Scan() is an entirely atomic operation that has no impact on previous or subsequent calls.

Any given call to Registry.Scan() consists of three different things:

One or more assemblies to scan for types
One or more registration conventions
Optionally, set filters to only include certain types or exclude other types from being processed by the scanning operation

Scan the Calling Assembly

One of the easiest ways to register types is by scanning the assembly your registry is placed in.

@@ -113,6 +147,8 @@

Scan the Calling Assembly

} +

Note that this method is an extension method in the StructureMap.Net4 assembly and cannot be used +if you target PCL compliance.

Scan for Registries

StructureMap can automatically include other registries with theLookForRegistries method.

@@ -130,8 +166,9 @@

Scan for Registries

} -

Scan the File System

StructureMap provides facilities for registering types by path.

As of 4.0, this operation is now recursive and StructureMap has always been idempotent about adding Registry types

Search for Assemblies on the File System

StructureMap provides facilities for registering types by finding assemblies in the application bin path:


         [Test]
         public void scan_all_assemblies_in_a_folder()
@@ -150,6 +187,16 @@ Scan the File System
         }

Make sure you have some kind of filter on the assemblies scanned for performance and predictability reasons. Either a naming convention or filter +by an assembly attribute to narrow where StructureMap looks
Get familiar with the new type scanning diagnostics introduced in 4.0;-)

Excluding Types

StructureMap also makes it easy to exclude types, either individually or by namespace. The following examples also show how StructureMap can register an assembly by providing @@ -266,6 +313,107 @@

Custom Registration Conventions

container.GetInstance<IBaz>().ShouldBeOfType<BusyGuy>(); } + +

The Default ISomething/Something Convention

The "default" convention simply tries to connect concrete classes to interfaces using +the I[Something]/[Something] naming convention as shown in this sample:


+        public interface ISpaceship { }
+        public class Spaceship : ISpaceship { }
+
+        public interface IRocket { }
+        public class Rocket : IRocket { }
+
+        [Test]
+        public void default_scanning_in_action()
+        {
+            var container = new Container(_ =>
+            {
+                _.Scan(x =>
+                {
+                    x.Assembly("StructureMap.Testing");
+                    x.WithDefaultConventions();
+                });
+            });
+
+            container.GetInstance<ISpaceship>().ShouldBeOfType<Spaceship>();
+            container.GetInstance<IRocket>().ShouldBeOfType<Rocket>();
+        }
+

The StructureMap team contains some VB6 veterans who hate Hungarian Notation, but can't shake the "I" nomenclature.

Registering the Single Implementation of an Interface

To tell StructureMap to automatically register any interface that only has one concrete implementation, use this method:


+        public interface ISong { }
+        public class TheOnlySong : ISong { }
+
+        [Test]
+        public void only_implementation()
+        {
+            var container = new Container(_ =>
+            {
+                _.Scan(x =>
+                {
+                    x.TheCallingAssembly();
+                    x.SingleImplementationsOfInterface();
+                });
+            });
+
+            container.GetInstance<ISong>()
+                .ShouldBeOfType<TheOnlySong>();
+        }
+

Register all Concrete Types of an Interface

To add all concrete types that can be cast to a named plugin type, use this syntax:


+        public interface IFantasySeries { }
+        public class WheelOfTime : IFantasySeries { }
+        public class GameOfThrones : IFantasySeries { }
+        public class BlackCompany : IFantasySeries { }
+
+
+        [Test]
+        public void register_all_types_of_an_interface()
+        {
+            var container = new Container(_ =>
+            {
+                _.Scan(x =>
+                {
+                    x.TheCallingAssembly();
+
+                    x.AddAllTypesOf<IFantasySeries>();
+
+                    // or
+
+                    x.AddAllTypesOf(typeof (IFantasySeries))
+                        .NameBy(type => type.Name.ToLower());
+                });
+            });
+
+            container.Model.For<IFantasySeries>()
+                .Instances.Select(x => x.ReturnedType)
+                .OrderBy(x => x.Name)
+                .ShouldHaveTheSameElementsAs(typeof(BlackCompany), typeof(GameOfThrones), typeof(WheelOfTime));
+        }
+

Note, "T" does not have to be an interface, it's all based on the ability to cast a concrete type to the "T"

Generic Types

See Generic Types for an example of using the ConnectImplementationsToTypesClosing +mechanism for generic types.

Register Concrete Types against the First Interface

The last built in registration convention is a mechanism to register all concrete types +that implement at least one interface against the first interface that they implement.


+            container = new Container(x =>
+            {
+                x.Scan(o =>
+                {
+                    o.TheCallingAssembly();
+                    o.RegisterConcreteTypesAgainstTheFirstInterface();
+
+                    o.Exclude(t => t.CanBeCastTo(typeof (IGateway)));
+                });
+            });

diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html old mode 100755 new mode 100644 diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html old mode 100755 new mode 100644 diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html old mode 100755 new mode 100644 diff --git a/registration/policies/index.html b/registration/policies/index.html old mode 100755 new mode 100644 diff --git a/setter-injection/index.html b/setter-injection/index.html old mode 100755 new mode 100644 diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html old mode 100755 new mode 100644 diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html old mode 100755 new mode 100644 diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html old mode 100755 new mode 100644 From 89cd3223acfc8261ccfe0c2170481f064f179368 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Fri, 9 Oct 2015 15:35:59 -0500 Subject: [PATCH 22/55] Documentation Update --- best-practices/index.html | 6 +- diagnostics/type-scanning/index.html | 6 +- documentation/index.html | 2 +- instances/index.html | 22 ++ .../index.html | 6 +- the-container/index.html | 2 +- the-container/lazy-resolution/index.html | 282 ++++++++++++++++++ the-container/primitives/index.html | 6 +- 8 files changed, 318 insertions(+), 14 deletions(-) create mode 100644 the-container/lazy-resolution/index.html diff --git a/best-practices/index.html b/best-practices/index.html index 802a0bb..edf62ae 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -46,7 +46,7 @@

History

Internals and Architecture

Diagnostics

Best Practices

Internals and Architecture

Best Practices

Using the Container Model

@@ -186,7 +186,7 @@

What did StructureMap scan?

- Next: Internals and Architecture + Next: Best Practices diff --git a/documentation/index.html b/documentation/index.html index c7121ef..f7b21a5 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/instances/index.html b/instances/index.html index 624e232..695cd66 100644 --- a/instances/index.html +++ b/instances/index.html @@ -93,6 +93,28 @@

Custom Instance Types

Most users will never need to implement a custom Instance type, but it does come up here and there. The easiest way is probably to +subclass LambdaInstance as shown below:


+    public class FuncInstance<T> : LambdaInstance<Func<T>>
+    {
+        // Pass a Func<IContext, T> into the base constructor
+        // Use a static method for cleaner syntax to avoid the 
+        // nasty Lambda syntax formatting as needed
+        public FuncInstance() : base(s => s.GetInstance<IContainer>().GetInstance<T>)
+        {
+        }
+
+        public override string Description
+        {
+            get { return "Constructor for Func<{0}>".ToFormat(typeof (T).Name); }
+        }
+    }
+

The other common customization is as a generic builder template

If neither of these approaches will easily work for your custom Instance, you may want to contact the StructureMap team +via the gitter link above and we can help walk you through a custom subclass of Instance -- or more likely, talk you out +of it somehow.

diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html index e120d05..de53ce7 100644 --- a/the-container/handling-missing-named-instances/index.html +++ b/the-container/handling-missing-named-instances/index.html @@ -47,7 +47,7 @@

Working with Primitive Types

Lazy Resolution

Working with Enumerable Types

@@ -280,7 +280,7 @@

Multi-Tenancy

- Next: Working with Primitive Types + Next: Lazy Resolution diff --git a/the-container/index.html b/the-container/index.html index 807861f..bf1e88b 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -94,7 +94,7 @@

The Container

diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html new file mode 100644 index 0000000..5f57719 --- /dev/null +++ b/the-container/lazy-resolution/index.html @@ -0,0 +1,282 @@ + + + + + + + + StructureMap - Lazy Resolution + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 4.0.0

+
+ + + +

Working with Primitive Types

Handling Missing Named Instances

+ +

Lazy Resolution

+ +

StructureMap has some built in functionality for "lazy" resolved dependencies, so that instead of your +application service taking a direct dependency on IExpensiveToBuildService that might not be necessary, +you could instead have StructureMap fulfil a dependency on Lazy<IExpensiveToBuildService> or Func<IExpensiveToBuildService> +that could be used to retrieve that expensive service only when it is needed from whatever Container originally created +the parent object.

Do note that the Lazy<T> and Func<T> approaches respect the lifecycle of the underlying registration rather than +automatically building a unique object instance.

Also note that Lazy<T> or Func<T> is your best (only) viable approach if you wish to have StructureMap inject bi-directional +relationships.

Lazy<T>

Assuming that StructureMap either has an existing configuration for T or can +derive a way to build T, you can just declare a dependency on Lazy<T> like this sample:


+        public class WidgetLazyUser
+        {
+            private readonly Lazy<IWidget> _widget;
+
+            public WidgetLazyUser(Lazy<IWidget> widget)
+            {
+                _widget = widget;
+            }
+
+            public IWidget Widget
+            {
+                get { return _widget.Value; }
+            }
+        }
+
+        [Test]
+        public void lazy_resolution_in_action()
+        {
+            var container = new Container(_ =>
+            {
+                _.For<IWidget>().Use<AWidget>();
+            });
+
+            container.GetInstance<WidgetLazyUser>()
+                .Widget.ShouldBeOfType<AWidget>();
+        }
+

Func<T>

Likewise, you can also declare a dependency on Func<T> with very similar mechanics:


+        [Test]
+        public void build_a_func_that_returns_a_singleton()
+        {
+            var container = new Container(x =>
+            {
+                x.ForSingletonOf<IWidget>().Use<ColorWidget>().Ctor<string>("color").Is("green");
+            });
+
+            var func = container.GetInstance<Func<IWidget>>();
+            var w1 = func();
+            var w2 = func();
+            var w3 = func();
+
+            w1.ShouldBeOfType<ColorWidget>().Color.ShouldBe("green");
+
+            w1.ShouldBeTheSameAs(w2);
+            w1.ShouldBeTheSameAs(w3);
+            w2.ShouldBeTheSameAs(w3);
+        }
+

This functionality predates the introduction of the Lazy type to .Net

Func<string, T>

Finally, you can also declare a dependency on Func<string, T> that will allow you to lazily +resolve a dependency of T by name:


+        [Test]
+        public void build_a_func_by_string()
+        {
+            var container = new Container(x =>
+            {
+                x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("green").Named("green");
+                x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("blue").Named("blue");
+                x.For<IWidget>().Add<ColorWidget>().Ctor<string>("color").Is("red").Named("red");
+            });
+
+            var func = container.GetInstance<Func<string, IWidget>>();
+            func("green").ShouldBeOfType<ColorWidget>().Color.ShouldBe("green");
+        }
+

Bi-relational Dependency Workaround

StructureMap does not directly support bi-directional dependency relationships -- but will happily tell you in an exception when +you accidentally manage to create one without cratering your AppDomain with a StackOverflowException.

Either Func<T> or Lazy<T> can be used as a workaround for purposeful bi-directional dependencies between types. The +following is an example of using this strategy:


+
+        [Singleton]
+        public class Thing1 
+        {
+            private readonly Lazy<Thing2> _thing2;
+
+            public Thing1(Lazy<Thing2> thing2)
+            {
+                _thing2 = thing2;
+            }
+
+            public Thing2 Thing2
+            {
+                get { return _thing2.Value; }
+            }
+        }
+
+        [Singleton]
+        public class Thing2 
+        {
+            public Thing1 Thing1 { get; set; }
+
+            public Thing2(Thing1 thing1)
+            {
+                Thing1 = thing1;
+            }
+        }
+
+        [Test]
+        public void use_lazy_as_workaround_for_bi_directional_dependency()
+        {
+            var container = new Container();
+            var thing1 = container.GetInstance<Thing1>();
+            var thing2 = container.GetInstance<Thing2>();
+
+            thing1.Thing2.ShouldBeSameAs(thing2);
+            thing2.Thing1.ShouldBeSameAs(thing1);
+        }
+

+ + +

+ +

+ + + +

+ + + + + + + + + +

Object Lifecycles

Handling Missing Named Instances

Lazy Resolution

Default Values

- Previous: Handling Missing Named Instances + Previous: Lazy Resolution From df9136cb281968ee7ecd147a0266853b4513006b Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Sun, 11 Oct 2015 14:03:05 -0500 Subject: [PATCH 23/55] Documentation Update --- documentation/index.html | 2 +- object-lifecycle/index.html | 230 +++++++++++++++++++++-- the-container/disposing/index.html | 156 +++++++++++++++ the-container/index.html | 2 +- the-container/lazy-resolution/index.html | 6 +- the-container/primitives/index.html | 6 +- 6 files changed, 378 insertions(+), 24 deletions(-) create mode 100644 the-container/disposing/index.html diff --git a/documentation/index.html b/documentation/index.html index f7b21a5..046b28a 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -93,7 +93,7 @@

Documentation

The documentation may never be exhaustive, but here are the major sections so far:

diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html index 473b021..15a9ef8 100644 --- a/object-lifecycle/index.html +++ b/object-lifecycle/index.html @@ -1,16 +1,214 @@ - -Error!

Error!

System.Collections.Generic.KeyNotFoundException: Key 'evil-singleton' could not be found
-   at FubuCore.Util.Cache`2.<.ctor>b__2(TKey key)
-   at FubuCore.Util.Cache`2.Fill(TKey key, Func`2 onMissing)
-   at ST.Docs.Samples.SampleCache.Find(String name)
-   at ST.Docs.DocProject.ST.Docs.Samples.ISampleCache.Find(String name)
-   at ST.Docs.Transformation.CodeSampleTransformHandler.Transform(Topic current, String data)
-   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
-   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
-   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
-   at ST.Docs.Transformation.Transformer.InnerTransformHandler.Transform(Topic current, String data)
-   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
-   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
-   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
-   at ST.Docs.Transformation.HtmlGenerator.generate(Topic topic)
-   at ST.Docs.Transformation.HtmlGenerator.Generate(Topic topic)

\ No newline at end of file + + + + + + + + StructureMap - Object Lifecycles + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 4.0.0

+
+ + + +

Supported Lifecycles

The Container

+ +

Object Lifecycles

+ +

+ + +

StructureMap isn't magic, you'll still need to be cognizant of the need for object cleanup. See the section on for more guidance.

Motivation for Container Managed Scope

In the bad old days, we used the infamous Singleton pattern +as shown below for objects that really needed to be scoped as one single instance for the entire system:


+    public class EvilSingleton
+    {
+        public static readonly EvilSingleton Instance = new EvilSingleton();
+
+        private EvilSingleton()
+        {
+        }
+
+        public void DoSomething()
+        {
+            // do something with the static data here
+        }
+    }
+
+
+    public class EvilSingletonUser
+    {
+        public void DoWork()
+        {
+            EvilSingleton.Instance.DoSomething();
+        }
+    }
+
+

Instead, let's just use StructureMap to handle the singleton scoping instead and rewrite the code sample above as:


+    public class SingletonService { }
+
+    public class SingletonUser
+    {
+        public SingletonUser(SingletonService singleton)
+        {
+        }
+    }
+
+    public class SingletonScopeRegistry : Registry
+    {
+        public SingletonScopeRegistry()
+        {
+            For<SingletonService>().Singleton();
+        }
+    }
+

+ + +

+ +

+ + + +

+ + + + + + + + + +

StructureMap - StructureMap and IDisposable

+ +

+ + +

StructureMap 4.0.0

+
+ + + +

Working with Primitive Types

Lazy Resolution

+ +

StructureMap and IDisposable

+ +

STUFF HERE.

+ + +

+ +

+ + + +

+ + + + + + + + + +

The Container

Working with Primitive Types

StructureMap and IDisposable

Handling Missing Named Instances

@@ -233,7 +233,7 @@

Bi-relational Dependency Workaround

- Next: Working with Primitive Types + Next: StructureMap and IDisposable diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html index 8380c8f..b4a0dea 100644 --- a/the-container/primitives/index.html +++ b/the-container/primitives/index.html @@ -46,7 +46,7 @@

Object Lifecycles

Lazy Resolution

StructureMap and IDisposable

Default Values

- Previous: Lazy Resolution + Previous: StructureMap and IDisposable From 631e28641173b244ff07c8f2db44532fc5e6d0d2 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Mon, 12 Oct 2015 08:16:45 -0500 Subject: [PATCH 24/55] Documentation Update --- .../supported-lifecycles/index.html | 528 +++++++++++++++++- registration/policies/index.html | 13 +- 2 files changed, 523 insertions(+), 18 deletions(-) diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 0e05f35..757747b 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -1,16 +1,512 @@ - -Error!

Error!

System.Collections.Generic.KeyNotFoundException: Key 'singleton-in-action' could not be found
-   at FubuCore.Util.Cache`2.<.ctor>b__2(TKey key)
-   at FubuCore.Util.Cache`2.Fill(TKey key, Func`2 onMissing)
-   at ST.Docs.Samples.SampleCache.Find(String name)
-   at ST.Docs.DocProject.ST.Docs.Samples.ISampleCache.Find(String name)
-   at ST.Docs.Transformation.CodeSampleTransformHandler.Transform(Topic current, String data)
-   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
-   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
-   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
-   at ST.Docs.Transformation.Transformer.InnerTransformHandler.Transform(Topic current, String data)
-   at ST.Docs.Transformation.Transformer.<>c__DisplayClass5.<Transform>b__4(Token token)
-   at System.Collections.Generic.GenericEnumerableExtensions.Each[T](IEnumerable`1 values, Action`1 eachAction)
-   at ST.Docs.Transformation.Transformer.Transform(Topic current, String before)
-   at ST.Docs.Transformation.HtmlGenerator.generate(Topic topic)
-   at ST.Docs.Transformation.HtmlGenerator.Generate(Topic topic)

\ No newline at end of file + + + + + + + + StructureMap - Supported Lifecycles + + + + + + + + + + + + + + + + + + + +

+ + + +

+ +

+ + +

StructureMap 4.0.0

+
+ + + +

Configuring Lifecycles

Object Lifecycles

+ +

Supported Lifecycles

+ +

+ + +

Out of the box, the core StructureMap assembly supports these lifecycles:

Transient -- The default lifecycle. A new object is created for each logical request to resolve an object graph from the container.
Singleton -- Only one object instance will be created for the main Container
AlwaysUnique -- A new object instance is created every time, even within the same object graph
ThreadLocal -- Only one object instance will be created for the currently executing Thread

Transient

Transient lifecycle objects are only tracked and disposed if created by nested containers. If you resolve a transient object from the main application container, +it will not track the object created. While that behavior avoids the manual Release() method and potential memory leak found in other IoC containers like Windsor, it +puts the onus for disposing those objects on the user. The StructureMap team strongly recommends using nested containers for short +lived operations if disposing transient objects created by the Container is important.

The following unit test demonstrates how Transient lifecycles work in both root and nested containers.


+        [Test]
+        public void Transient()
+        {
+            var c = new Container(x => { x.For<IService>().Use<Service>().Transient(); });
+
+            // In a normal container, you get a new object
+            // instance of the Service class in subsequent
+            // requests
+            c.GetInstance<IService>()
+                .ShouldNotBeTheSameAs(c.GetInstance<IService>())
+                .ShouldNotBeTheSameAs(c.GetInstance<IService>());
+
+            // Within a nested container, 'Transient' now 
+            // means within the Nested Container.
+            // A nested container is effectively one request
+            using (var nested = c.GetNestedContainer())
+            {
+                nested.GetInstance<IService>()
+                    .ShouldBeTheSameAs(nested.GetInstance<IService>())
+                    .ShouldBeTheSameAs(nested.GetInstance<IService>());
+            }
+        }
+
+


+        public interface IUnitOfWork
+        {
+        }
+
+        public class DefaultUnitOfWork : IUnitOfWork
+        {
+        }
+
+        public class Worker1
+        {
+            public IUnitOfWork Uow { get; set; }
+
+            public Worker1(IUnitOfWork uow)
+            {
+                Uow = uow;
+            }
+        }
+
+        public class Worker2
+        {
+            public IUnitOfWork Uow { get; set; }
+
+            public Worker2(IUnitOfWork uow)
+            {
+                Uow = uow;
+            }
+        }
+
+        public class WorkerCoordinator
+        {
+            public IUnitOfWork Uow { get; set; }
+            public Worker1 Worker1 { get; set; }
+            public Worker2 Worker2 { get; set; }
+
+            public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
+            {
+                Uow = uow;
+                Worker1 = worker1;
+                Worker2 = worker2;
+            }
+        }
+
+        [Test]
+        public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
+        {
+            var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });
+
+            var cooridinator = container.GetInstance<WorkerCoordinator>();
+
+            // The IUnitOfWork object instance is the same for
+            // all the objects in the object graph that had
+            // a constructor dependency on IUnitOfWork
+            cooridinator.Uow
+                .ShouldBeTheSameAs(cooridinator.Worker1.Uow);
+
+            cooridinator.Uow
+                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
+
+            cooridinator.Worker1.Uow
+                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
+        }
+
+

AlwaysUnique


+        [Test]
+        public void Always_Unique()
+        {
+            var c = new Container(x => { x.For<IService>().Use<Service>().AlwaysUnique(); });
+
+            // In a normal container, you get a new object
+            // instance of the Service class in subsequent
+            // requests
+            c.GetInstance<IService>()
+                .ShouldNotBeTheSameAs(c.GetInstance<IService>())
+                .ShouldNotBeTheSameAs(c.GetInstance<IService>());
+
+            // Within a nested container, 'Transient' now 
+            // means within the Nested Container.
+            // A nested container is effectively one request
+            using (var nested = c.GetNestedContainer())
+            {
+                nested.GetInstance<IService>()
+                    .ShouldNotBeTheSameAs(nested.GetInstance<IService>())
+                    .ShouldNotBeTheSameAs(nested.GetInstance<IService>());
+            }
+
+            // Even in a single request, 
+            var holder = c.GetInstance<ServiceUserHolder>();
+            holder.Service.ShouldNotBeTheSameAs(holder.User.Service);
+        }
+
+

Singleton

StructureMap 3.0 fixed the dreaded singletons with nested container's bug that was so problematic in 2.6.


+        [Test]
+        public void singletons_are_disposed_when_the_container_is_disposed()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForSingletonOf<DisposableSingleton>();
+            });
+
+            // As a singleton-scoped object, every request for DisposableSingleton
+            // will return the same object
+            var singleton = container.GetInstance<DisposableSingleton>();
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+
+            singleton.WasDisposed.ShouldBeFalse();
+
+            // now, dispose the Container
+            container.Dispose();
+
+            // the SingletonThing scoped object should be disposed
+            singleton.WasDisposed.ShouldBeTrue();
+        }
+

Do note that objects created as the singleton scope will be disposed when the Container is disposed if they +implement the IDisposable interface:


+        public interface IUnitOfWork
+        {
+        }
+
+        public class DefaultUnitOfWork : IUnitOfWork
+        {
+        }
+
+        public class Worker1
+        {
+            public IUnitOfWork Uow { get; set; }
+
+            public Worker1(IUnitOfWork uow)
+            {
+                Uow = uow;
+            }
+        }
+
+        public class Worker2
+        {
+            public IUnitOfWork Uow { get; set; }
+
+            public Worker2(IUnitOfWork uow)
+            {
+                Uow = uow;
+            }
+        }
+
+        public class WorkerCoordinator
+        {
+            public IUnitOfWork Uow { get; set; }
+            public Worker1 Worker1 { get; set; }
+            public Worker2 Worker2 { get; set; }
+
+            public WorkerCoordinator(IUnitOfWork uow, Worker1 worker1, Worker2 worker2)
+            {
+                Uow = uow;
+                Worker1 = worker1;
+                Worker2 = worker2;
+            }
+        }
+
+        [Test]
+        public void transient_scoped_Instance_is_built_once_per_resolution_to_the_Container()
+        {
+            var container = new Container(_ => { _.For<IUnitOfWork>().Use<DefaultUnitOfWork>(); });
+
+            var cooridinator = container.GetInstance<WorkerCoordinator>();
+
+            // The IUnitOfWork object instance is the same for
+            // all the objects in the object graph that had
+            // a constructor dependency on IUnitOfWork
+            cooridinator.Uow
+                .ShouldBeTheSameAs(cooridinator.Worker1.Uow);
+
+            cooridinator.Uow
+                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
+
+            cooridinator.Worker1.Uow
+                .ShouldBeTheSameAs(cooridinator.Worker2.Uow);
+        }
+
+

ThreadLocal

The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test:


+    [TestFixture]
+    public class ThreadLocalStorageLifecycleTester
+    {
+        #region Setup/Teardown
+
+        [SetUp]
+        public void SetUp()
+        {
+            _lifecycle = new ThreadLocalStorageLifecycle();
+
+            container = new Container(x => x.For<Rule>(Lifecycles.ThreadLocal).Use(() => new ColorRule("Red")));
+        }
+
+        #endregion
+
+        private ThreadLocalStorageLifecycle _lifecycle;
+        private ColorRule _rule1;
+        private ColorRule _rule2;
+        private ColorRule _rule3;
+        private Container container;
+
+
+        private void findRule1()
+        {
+            _rule1 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+
+            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+            _rule1.ShouldBeTheSameAs(rule);
+        }
+
+        private void findRule2()
+        {
+            _rule2 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+
+            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+            _rule2.ShouldBeTheSameAs(rule);
+        }
+
+        private void findRule3()
+        {
+            _rule3 = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+
+            var rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+            _rule3.ShouldBeTheSameAs(rule);
+
+            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+            _rule3.ShouldBeTheSameAs(rule);
+
+            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+            _rule3.ShouldBeTheSameAs(rule);
+
+            rule = container.GetInstance<Rule>().ShouldBeOfType<ColorRule>();
+            _rule3.ShouldBeTheSameAs(rule);
+        }
+
+        [Test]
+        public void object_has_been_created()
+        {
+            container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeFalse();
+            var r1 = container.GetInstance<Rule>();
+            container.Model.For<Rule>().Default.ObjectHasBeenCreated().ShouldBeTrue();
+        }
+
+        [Test]
+        public void FindUniqueInstancePerThread()
+        {
+            var t1 = new Thread(findRule1);
+            var t2 = new Thread(findRule2);
+            var t3 = new Thread(findRule3);
+
+            t1.Start();
+            t2.Start();
+            t3.Start();
+
+            t1.Join();
+            t2.Join();
+            t3.Join();
+
+            _rule1.ShouldNotBeTheSameAs(_rule2);
+            _rule1.ShouldNotBeTheSameAs(_rule3);
+            _rule2.ShouldNotBeTheSameAs(_rule3);
+            (_rule1.ID != _rule2.ID).ShouldBeTrue();
+            (_rule1.ID != _rule3.ID).ShouldBeTrue();
+            (_rule2.ID != _rule3.ID).ShouldBeTrue();
+        }
+    }
+
+

Legacy ASP.Net Lifecycles

In addition, the StructureMap.Web package adds the legacy ASP.Net related lifecycles for:

HttpContext
HttpSession (requires objects to be Serializable, not recommended but still present for legacy code
Hybrid -- uses ThreadLocalStorage in the absence of an active HttpContext
HybridSession


+    public class AspNetRegistry : Registry
+    {
+        public AspNetRegistry()
+        {
+            For<IWeirdThing>().LifecycleIs<HttpContextLifecycle>();
+            For<IGateway>().LifecycleIs<HybridLifecycle>();
+            For<IRule>().LifecycleIs<HttpSessionLifecycle>();
+            For<ICache>().LifecycleIs<HybridSessionLifecycle>();
+        }
+    }
+
+

If you do use any of the HttpContext lifecycles, make sure you also do:


+            HttpContextLifecycle.DisposeAndClearAll();
+

at the end of your HTTP request.

+ + +

+ +

+ + + +

+ + + + + + + + + +

Construction Policies


     public abstract class ConfiguredInstancePolicy : IInstancePolicy
     {
+        /// <summary>
+        /// Applies explicit configuration to an IConfiguredInstance
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <param name="instance"></param>
         public void Apply(Type pluginType, Instance instance)
         {
             var configured = instance as IConfiguredInstance;
@@ -147,8 +152,12 @@ Construction Policies
             }
         }
 
-        // This method is called against any Instance that implements 
-        // the IConfiguredInstance interface
+        /// <summary>
+        /// This method is called against any Instance that implements the
+        /// IConfiguredInstance interface
+        /// </summary>
+        /// <param name="pluginType"></param>
+        /// <param name="instance"></param>
         protected abstract void apply(Type pluginType, IConfiguredInstance instance);
     }

Date: Mon, 12 Oct 2015 09:49:28 -0500 Subject: [PATCH 25/55] Documentation Update --- .../profiles-and-child-containers/index.html | 169 +++++++++++++++++- 1 file changed, 168 insertions(+), 1 deletion(-) diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html index 10cc31b..8faeb75 100644 --- a/the-container/profiles-and-child-containers/index.html +++ b/the-container/profiles-and-child-containers/index.html @@ -94,7 +94,174 @@

Profiles and Child Containers

TODO(Write some content!)

Child Containers are not interchangeable with Nested Containers. See for more information on nested containers.

The single best source for information about the particulars of child container behavior is to look through the acceptance tests for child containers and +profiles. +from the code in GitHub.

Child Containers

The easiest way to explain a child container is to just show it in action:


+        [Test]
+        public void show_a_child_container_in_action()
+        {
+            var parent = new Container(_ =>
+            {
+                _.For<IWidget>().Use<AWidget>();
+                _.For<IService>().Use<AService>();
+            });
+
+            // Create a child container and override the
+            // IService registration
+            var child = parent.CreateChildContainer();
+            child.Configure(_ =>
+            {
+                _.For<IService>().Use<ChildSpecialService>();
+            });
+
+            // The child container has a specific registration
+            // for IService, so use that one
+            child.GetInstance<IService>()
+                .ShouldBeOfType<ChildSpecialService>();
+
+            // The child container does not have any
+            // override of IWidget, so it uses its parent's
+            // configuration to resolve IWidget
+            child.GetInstance<IWidget>()
+                .ShouldBeOfType<AWidget>();
+        }
+

Child Container's are a mechanism to make a completely new Container that can override some of the parent Container's registrations but still +fall back to the parent Container to fulfil any request that is not explicitly configured to the child container. The behavior of a child container +in how it resolves services and allows you to override the parent container is very similar to a nested container, but the crucial difference is in how the two concepts handle lifecycles and calling IDisposable.Dispose().

A couple salient facts about child containers that should (knock on wood) dispel the confusion about when and why to use them versus a nested container:

Child Containers do not change how the default transient lifecycle behaves.
Child Containers (and Profiles) were intended to be used to establish different service resolutions for different subsystems of the running system or +to isolate registration overrides for specific types of users or customers (multi-tenancy).

Profiles

Profiles were completely redesigned as part of the big 3.0 release.

Profiles are just named child containers that may be configured upfront through Registry configurations. +Profiles are one of the oldest features that date back to the very beginning of StructureMap. Originally profile's were conceived of as +a way to vary StructureMap registrations by development environment as the code moved from running locally on a developer's box to testing +servers to production. While that usage is still valid, it is probably more common to use profiles to define overrides for how StructureMap +should resolve services in different modes of the application (connected vs offline) or different types of system users.


+        [Test]
+        public void Add_default_instance_with_concrete_type()
+        {
+            IContainer container = new Container(registry =>
+            {
+                registry.Profile("something", p =>
+                {
+                    p.For<IWidget>().Use<AWidget>();
+                    p.For<Rule>().Use<DefaultRule>();
+                });
+            });
+
+            var profile = container.GetProfile("something");
+
+            profile.GetInstance<IWidget>().ShouldBeOfType<AWidget>();
+            profile.GetInstance<Rule>().ShouldBeOfType<DefaultRule>();
+        }
+

Child Containers and Singletons

If you register a new Instance directly to a child container, that registration is really scoped as a +singleton within the usage of that particular child container:


+        [Test]
+        public void singletons_to_child_container_are_isolated()
+        {
+            var parentContainer = new Container(_ =>
+            {
+                _.For<IDependency>().Use<Dependency>();
+            });
+
+            var child1 = parentContainer.CreateChildContainer();
+            child1.Configure(x =>
+            {
+                x.ForSingletonOf<IRoot>().Use<Root>();
+            });
+
+            var child2 = parentContainer.CreateChildContainer();
+            child2.Configure(x =>
+            {
+                x.ForSingletonOf<IRoot>().Use<Root>();
+            });
+
+            // IRoot is a "singleton" within child1 usage
+            child1.GetInstance<IRoot>().ShouldBeSameAs(child1.GetInstance<IRoot>());
+
+            // IRoot is a "singleton" within child2 usage
+            child2.GetInstance<IRoot>().ShouldBeSameAs(child2.GetInstance<IRoot>());
+
+            // but, child1 and child2 both have a different IRoot
+            child1.GetInstance<IRoot>()
+                .ShouldNotBeTheSameAs(child2);
+        }
+

Creating a Nested Container from a Child Container

It is perfectly valid to create a nested container from a child container for short-lived requests or transactions:


+        [Test]
+        public void nested_container_from_child()
+        {
+            var parent = new Container(_ =>
+            {
+                _.For<IWidget>().Use<AWidget>();
+                _.For<IService>().Use<AService>();
+            });
+
+            // Create a child container and override the
+            // IService registration
+            var child = parent.CreateChildContainer();
+            child.Configure(_ =>
+            {
+                _.For<IService>().Use<ChildSpecialService>();
+            });
+
+            using (var nested = child.GetNestedContainer())
+            {
+                nested.GetInstance<IService>()
+                    .ShouldBeOfType<ChildSpecialService>();
+            }
+        }
+

Example: Child Containers in Automated Testing

In action, that usage looks something like this:


+        public class TheRealService : IService { }
+
+        public class StubbedService : IService { }
+
+        [Test]
+        public void in_testing()
+        {
+            var container = new Container(_ =>
+            {
+                _.For<IService>().Use<TheRealService>();
+            });
+
+            // Create a new child container for only this test
+            var testContainer = container.CreateChildContainer();
+
+            // Override a service with a stub that's easier to control
+            var stub = new StubbedService();
+            testContainer.Inject<IService>(stub);
+
+            // Now, continue with the test resolving application
+            // services through the new child container....
+        }
+

From 5326c62430f2c71483d1f251343c0276ed2335f9 Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Mon, 12 Oct 2015 10:19:53 -0500 Subject: [PATCH 26/55] Documentation Update --- .../supported-lifecycles/index.html | 5 +- the-container/disposing/index.html | 131 +++++++++++++++++- .../profiles-and-child-containers/index.html | 2 +- 3 files changed, 132 insertions(+), 6 deletions(-) diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 757747b..32d23c2 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -106,10 +106,7 @@

Transient

causes some confusion with ASP.Net HTTP scoping. The easiest way to think of Transient is that a single object instance will be created for each top level call to Container.GetInstance() (or any other object resolution method on the IContainer interface). Transient objects resolved from a nested container, Transient's are scoped to the lifecycle of the nested container itself. See Nested Containers (Per Request/Transaction) for more information.

StructureMap's behavior for transient objects that implement IDisposable changed in 4.0 to introduce an "opt-in" tracking mode. Please see StructureMap and IDisposable for the details.

The following unit test demonstrates how Transient lifecycles work in both root and nested containers.


         [Test]
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html
index f1dc3fc..9f40665 100644
--- a/the-container/disposing/index.html
+++ b/the-container/disposing/index.html
@@ -93,7 +93,136 @@ StructureMap and IDisposable
 
 			      	
 			      		
-STUFF HERE.
+Singletons
+This one is easy, any object marked as the Singleton lifecycle that implements IDisposable is disposed when the root container is
+disposed:
+
+        [Test]
+        public void singletons_are_disposed_when_the_container_is_disposed()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForSingletonOf<DisposableSingleton>();
+            });
+
+            // As a singleton-scoped object, every request for DisposableSingleton
+            // will return the same object
+            var singleton = container.GetInstance<DisposableSingleton>();
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+            singleton.ShouldBeSameAs(container.GetInstance<DisposableSingleton>());
+
+            singleton.WasDisposed.ShouldBeFalse();
+
+            // now, dispose the Container
+            container.Dispose();
+
+            // the SingletonThing scoped object should be disposed
+            singleton.WasDisposed.ShouldBeTrue();
+        }
+
+Ejecting a singleton-scoped object will also force it to be disposed. See Using the Container Model for more information on how to eject singletons
+from a running Container.
+Nested Containers
+As discussed in Nested Containers (Per Request/Transaction), any transient or container-scoped object that implements IDisposable and is created
+by a nested container will be disposed as the nested container is disposed:
+
+        [Test]
+        public void nested_container_disposal()
+        {
+            var container = new Container(_ =>
+            {
+                // A SingletonThing scoped service
+                _.ForSingletonOf<IColorCache>().Use<ColorCache>();
+
+                // A transient scoped service
+                _.For<IColor>().Use<Green>();
+            });
+
+            ColorCache singleton = null;
+            Green nestedGreen = null;
+            Blue nestedBlue = null;
+
+            using (var nested = container.GetNestedContainer())
+            {
+                // SingletonThing's are really built by the parent
+                singleton = nested.GetInstance<IColorCache>()
+                    .ShouldBeOfType<ColorCache>();
+
+                nestedGreen = nested.GetInstance<IColor>()
+                    .ShouldBeOfType<Green>();
+
+
+                nestedBlue = nested.GetInstance<Blue>();
+            }
+
+            // Transients created by the Nested Container
+            // are disposed, but no other lifecycle is
+            // disposed
+            nestedGreen.WasDisposed.ShouldBeTrue();
+            nestedBlue.WasDisposed.ShouldBeTrue();
+
+            // NOT disposed because it's owned by
+            // the parent container
+            singleton.WasDisposed.ShouldBeFalse();
+        }
+
+
+Transients
+Regardless of the new tracking/release mode, the StructureMap team still strongly recommends using a nested container per HTTP request or service
+bus message handling session or logical transaction to deal with disposing transient objects.
+By default, StructureMap will not hang on to any transient-scoped objects created by the root or child containers. Dealing with
+IDisposable is completely up to the user in this case. The StructureMap team has long believed that trying to track transient disposables with
+an explicit Release(object) mode as other IoC containers behave would do more harm than good (memory leaks from forgetting to call Release(), more work on the user).
+That all being said, in order to comply with the new ASP.Net vNext compliance behavior, StructureMap 4.0 introduces a new opt-in transient tracking mode with the prerequisite Release(object) method:
+
+        [Test]
+        public void release_transient_created_by_root_container()
+        {
+            var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode);
+
+            container.TransientTracking.ShouldBeOfType<TrackingTransientCache>();
+
+            var transient1 = container.GetInstance<DisposableGuy>();
+            var transient2 = container.GetInstance<DisposableGuy>();
+
+            transient1.WasDisposed.ShouldBeFalse();
+            transient2.WasDisposed.ShouldBeFalse();
+        
+            // release ONLY transient2
+            container.Release(transient2);
+
+
+            transient1.WasDisposed.ShouldBeFalse();
+            transient2.WasDisposed.ShouldBeTrue();
+
+            // transient2 should no longer be 
+            // tracked by the container
+            container.TransientTracking.Tracked
+                .Single()
+                .ShouldBeTheSameAs(transient1);
+        }
+
+        [Test]
+        public void disposing_the_container_disposes_tracked_transients()
+        {
+            var container = new Container(_ => _.TransientTracking = TransientTracking.ExplicitReleaseMode);
+
+            var transient1 = container.GetInstance<DisposableGuy>();
+            var transient2 = container.GetInstance<DisposableGuy>();
+
+            transient1.WasDisposed.ShouldBeFalse();
+            transient2.WasDisposed.ShouldBeFalse();
+
+            container.Dispose();
+
+            transient1.WasDisposed.ShouldBeTrue();
+            transient2.WasDisposed.ShouldBeTrue();
+        }
+
+As of right now, StructureMap will only track the top level object requested from a Container and not all the other IDisposable objects that may
+have been created as part of the main object graph.
 
 
 			      	
diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html
index 8faeb75..4f186ea 100644
--- a/the-container/profiles-and-child-containers/index.html
+++ b/the-container/profiles-and-child-containers/index.html
@@ -131,7 +131,7 @@ Child Containers
         }

Child Container's are a mechanism to make a completely new Container that can override some of the parent Container's registrations but still -fall back to the parent Container to fulfil any request that is not explicitly configured to the child container. The behavior of a child container +fall back to the parent Container to fulfill any request that is not explicitly configured to the child container. The behavior of a child container in how it resolves services and allows you to override the parent container is very similar to a nested container, but the crucial difference is in how the two concepts handle lifecycles and calling IDisposable.Dispose().

A couple salient facts about child containers that should (knock on wood) dispel the confusion about when and why to use them versus a nested container:

Date: Mon, 12 Oct 2015 10:37:48 -0500 Subject: [PATCH 27/55] Documentation Update --- interpreting-exceptions/index.html | 16 +++++++++++++++- .../index.html | 15 ++++++++++++++- the-container/index.html | 2 ++ 3 files changed, 31 insertions(+), 2 deletions(-) diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html index 45da811..370fb31 100644 --- a/interpreting-exceptions/index.html +++ b/interpreting-exceptions/index.html @@ -94,7 +94,21 @@

Interpreting Exceptions

TODO(Write some content!)

Improving the exception messages was one of the primary goals of the big StructureMap 3.0 release. StructureMap exceptions should +show a "StructureMap-specific stacktrace" describing where in the object graph StructureMap was when an exception occurred, while +trying hard not to obscure the actual problems. In some cases, StructureMap will append diagnostic views +to the exception output. If you are still using StructureMap 2.5-2.6, the better exception messages alone are a justification for upgrading.

StructureMap throws a couple custom exceptions, all of which implement a base StructureMapException type:

StructureMapBuildException -- a failure was detected during an attempt to build or resolve a requested object or dependency, but outside of +StructureMap code. This exception wraps the actual exception and adds StructureMap-specific contextual information. Always check the inner +exception when this exception is thrown.
StructureMapInterceptorException -- a configured interceptor failed during object construction. See the inner exception.
StructureMapBuildPlanException -- StructureMap is missing some kind of configuration or needs more explicit registrations in order to +build an Instance. In a few cases, this exception will be thrown if StructureMap cannot create and compile a Func internally for the +Instance.
StructureMapConfigurationException -- thrown by the container validation mechanism

diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html index aac3ad4..7fa1a13 100644 --- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html +++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html @@ -94,7 +94,20 @@

Try Geting an Optional Service by Plugin Type and Name

TODO(Write some content!)

Just use the IContainer.TryGetInstance<T>(name) or IContainer.TryGetInstance(Type pluginType, string name) method as shown below:


+        [Test]
+        public void TryGetInstanceViaNameAndGeneric_ReturnsInstance_WhenTypeFound()
+        {
+            addColorInstance("Red");
+            addColorInstance("Orange");
+            addColorInstance("Blue");
+
+            // "Orange" exists, so an object should be returned
+            var instance = _container.TryGetInstance<Rule>("Orange");
+            instance.ShouldBeOfType(typeof (ColorRule));
+        }
+

diff --git a/the-container/index.html b/the-container/index.html index ff33836..80d4dcc 100644 --- a/the-container/index.html +++ b/the-container/index.html @@ -94,6 +94,8 @@

The Container

The primary way to interact with StructureMap is through the IContainer interface and Container class. The following topics +discuss some of the features and internal workings of the Container.

From c6244380dcc3e09bde539796a7110788cc89c14b Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Mon, 12 Oct 2015 11:08:37 -0500 Subject: [PATCH 28/55] Documentation Update --- best-practices/index.html | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/best-practices/index.html b/best-practices/index.html index edf62ae..2b6142a 100644 --- a/best-practices/index.html +++ b/best-practices/index.html @@ -94,7 +94,42 @@

Best Practices

TODO(Write some content!)

All of these recommendations are the opinions and sole responsiblity of one Jeremy D. Miller. The single best advice I can give you +about using StructureMap is to avoid being too clever with your usage.

Use Nested Containers for Per Transaction/Request/Message Scoping

In idiomatic StructureMap usage, I strongly recommend using a nested container for short lived operations like:

An HTTP request
Handling a single service bus message
Short lived transactions

Avoid the Legacy ASP.Net Lifecycles

To repeat the section above, I strongly recommend using nested containers instead of the legacy ASP.Net lifecycles to scope +services per HTTP request.

Avoid Container.Configure() on the Root Container

Unfortunately, the Container.Configure() method is potentially an expensive operation +and can result in some container-wide locks if you change any kind of interception or construction policy. Avoid this mechanism at runtime. If you need +to inject services at runtime, try to do those overrides in an isolated nested container for that +particular request or transaction to avoid hitting any kind of shared lock.

Avoid `Container.TryGetInstance()`

Use the container to resolve your dependency relationships or don't. In my opinion, using TryGetInstance() results in unnecessary complexity in your application. My recommendation is to use nullo objects as stand-ins or to use "modular registration" strategies instead (See Fallback Services and Replace or Clear Out Previous Registrations for more information). The ASP.Net team requires this usage for all of their IoC container integrations and you can't fight city hall, so StructureMap 4.0 includes some performance optimizations specifically for the heavy TryGetInstance() usage that I never anticipated.

Favor Constructor Injection over Setter Injection

I believe that constructor injection is less error prone than setter injection and is more easily traceable later. Setter injection is occasionally easier +to use (in inheritance relationships for an example), but is mostly available in StructureMap as a workaround for code that was not built with dependency +injection in mind (or popular frameworks that were built around Spring.Net usage cough NServiceBus cough).

Use Child Containers for Test Isolation

See Profiles and Child Containers for more information.

Use Registry Classes

While you can completely set up a Container object through its constructor function and repeated calls to Container.Configure(), we suggest that you +express any configurations in Registry objects for repeatable configuration later in tests and for a cleaner expression +of the configuration.

Do consider breaking your configuration across separate Registry objects for different subsystems if the StructureMap configuration gets complicated.

Onion Architecture Assembly Coupling

If your choice is between making a direct dependency from one assembly to another strictly to make the StructureMap configuration easy and less error prone or using dynamic assembly loading and configuration strategies with type scanning to comply with the Onion Architecture, I very strongly recommend you favor the less error prone, direct assembly dependencies.

Favor Build Policies over Fancy Runtime Decision Making

While there are many powerful things you can do with StructureMap at runtime for conditional object resolution with lambdas and IContext, +I recommend trying to "bake in" building decisions upfront with build policies for more efficient object resolution and so that +the container behavior is surfaced through diagnostics like the build plan visualization.

From b618e04fd2c39eed82cad4191d7a805a9b107ceb Mon Sep 17 00:00:00 2001 From: jeremydmiller Date: Tue, 13 Oct 2015 08:22:10 -0500 Subject: [PATCH 29/55] Documentation Update --- .../supported-lifecycles/index.html | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html index 32d23c2..997fc39 100644 --- a/object-lifecycle/supported-lifecycles/index.html +++ b/object-lifecycle/supported-lifecycles/index.html @@ -328,6 +328,68 @@

Singleton

} +

ContainerScoped

The acceptance test for ContainerScoped is shown below:


+        [Test]
+        public void container_scoping_with_root_child_and_nested_container()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForConcreteType<Disposable>().Configure.ContainerScoped();
+            });
+
+            var child = container.CreateChildContainer();
+
+            var nested = container.GetNestedContainer();
+
+            // Always the same object when requested from the root container
+            var mainDisposable = container.GetInstance<Disposable>();
+            mainDisposable
+                .ShouldBeTheSameAs(container.GetInstance<Disposable>());
+
+            // Always the same object when requested from a child container
+            var childDisposable = child.GetInstance<Disposable>();
+            childDisposable
+                .ShouldBeTheSameAs(child.GetInstance<Disposable>());
+
+            // Always the same object when requested from a nested container
+            var nestedDisposable = nested.GetInstance<Disposable>();
+            nestedDisposable
+                .ShouldBeTheSameAs(nested.GetInstance<Disposable>());
+
+            // It should be a different object instance for
+            // all three containers
+            mainDisposable
+                .ShouldNotBeTheSameAs(childDisposable);
+
+            mainDisposable
+                .ShouldNotBeTheSameAs(nestedDisposable);
+
+            childDisposable
+                .ShouldNotBeTheSameAs(nestedDisposable);
+
+            // When the nested container is disposed,
+            // it should dispose all the container scoped objects,
+            // but not impact the other containers
+            nested.Dispose();
+            nestedDisposable.WasDisposed.ShouldBeTrue();
+            childDisposable.WasDisposed.ShouldBeFalse();
+            mainDisposable.WasDisposed.ShouldBeFalse();
+
+            // Same for the child container
+            child.Dispose();
+            childDisposable.WasDisposed.ShouldBeTrue();
+            mainDisposable.WasDisposed.ShouldBeFalse();
+
+            // Same for the main container
+            container.Dispose();
+            mainDisposable.WasDisposed.ShouldBeTrue();
+        }
+

ThreadLocal

The ThreadLocalStorage based lifecycle is seldom used, but the easiest example of using it and explanation is the integration test:



From 4fda5c603da68007164f67a1ad67d6b1591ccbc2 Mon Sep 17 00:00:00 2001
From: "Jeremy D. Miller" 
Date: Tue, 13 Oct 2015 08:22:34 -0500
Subject: [PATCH 30/55] Doc refresh for ContainerScoped()

---
 diagnostics/type-scanning/index.html        | 0
 generics/index.html                         | 0
 index.html                                  | 0
 instances/index.html                        | 0
 registration/attributes/index.html          | 0
 registration/clear-or-replace/index.html    | 0
 registration/configured-instance/index.html | 0
 registration/existing-objects/index.html    | 0
 registration/policies/index.html            | 0
 setter-injection/index.html                 | 0
 the-container/buildup/index.html            | 0
 the-container/disposing/index.html          | 0
 the-container/lambdas/index.html            | 0
 the-container/lazy-resolution/index.html    | 0
 the-container/primitives/index.html         | 0
 15 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 diagnostics/type-scanning/index.html
 mode change 100644 => 100755 generics/index.html
 mode change 100644 => 100755 index.html
 mode change 100644 => 100755 instances/index.html
 mode change 100644 => 100755 registration/attributes/index.html
 mode change 100644 => 100755 registration/clear-or-replace/index.html
 mode change 100644 => 100755 registration/configured-instance/index.html
 mode change 100644 => 100755 registration/existing-objects/index.html
 mode change 100644 => 100755 registration/policies/index.html
 mode change 100644 => 100755 setter-injection/index.html
 mode change 100644 => 100755 the-container/buildup/index.html
 mode change 100644 => 100755 the-container/disposing/index.html
 mode change 100644 => 100755 the-container/lambdas/index.html
 mode change 100644 => 100755 the-container/lazy-resolution/index.html
 mode change 100644 => 100755 the-container/primitives/index.html

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html
old mode 100644
new mode 100755
diff --git a/generics/index.html b/generics/index.html
old mode 100644
new mode 100755
diff --git a/index.html b/index.html
old mode 100644
new mode 100755
diff --git a/instances/index.html b/instances/index.html
old mode 100644
new mode 100755
diff --git a/registration/attributes/index.html b/registration/attributes/index.html
old mode 100644
new mode 100755
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html
old mode 100644
new mode 100755
diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html
old mode 100644
new mode 100755
diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html
old mode 100644
new mode 100755
diff --git a/registration/policies/index.html b/registration/policies/index.html
old mode 100644
new mode 100755
diff --git a/setter-injection/index.html b/setter-injection/index.html
old mode 100644
new mode 100755
diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html
old mode 100644
new mode 100755
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html
old mode 100644
new mode 100755
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html
old mode 100644
new mode 100755
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html
old mode 100644
new mode 100755
diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html
old mode 100644
new mode 100755

From b946ed43e4790bb482bf7d579124e459960b1799 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Tue, 13 Oct 2015 08:25:33 -0500
Subject: [PATCH 31/55] Documentation Update

---
 diagnostics/type-scanning/index.html             | 0
 generics/index.html                              | 0
 index.html                                       | 0
 instances/index.html                             | 0
 object-lifecycle/supported-lifecycles/index.html | 3 ++-
 registration/attributes/index.html               | 0
 registration/clear-or-replace/index.html         | 0
 registration/configured-instance/index.html      | 0
 registration/existing-objects/index.html         | 0
 registration/policies/index.html                 | 0
 setter-injection/index.html                      | 0
 the-container/buildup/index.html                 | 0
 the-container/disposing/index.html               | 0
 the-container/lambdas/index.html                 | 0
 the-container/lazy-resolution/index.html         | 0
 the-container/primitives/index.html              | 0
 16 files changed, 2 insertions(+), 1 deletion(-)
 mode change 100755 => 100644 diagnostics/type-scanning/index.html
 mode change 100755 => 100644 generics/index.html
 mode change 100755 => 100644 index.html
 mode change 100755 => 100644 instances/index.html
 mode change 100755 => 100644 registration/attributes/index.html
 mode change 100755 => 100644 registration/clear-or-replace/index.html
 mode change 100755 => 100644 registration/configured-instance/index.html
 mode change 100755 => 100644 registration/existing-objects/index.html
 mode change 100755 => 100644 registration/policies/index.html
 mode change 100755 => 100644 setter-injection/index.html
 mode change 100755 => 100644 the-container/buildup/index.html
 mode change 100755 => 100644 the-container/disposing/index.html
 mode change 100755 => 100644 the-container/lambdas/index.html
 mode change 100755 => 100644 the-container/lazy-resolution/index.html
 mode change 100755 => 100644 the-container/primitives/index.html

diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html
old mode 100755
new mode 100644
diff --git a/generics/index.html b/generics/index.html
old mode 100755
new mode 100644
diff --git a/index.html b/index.html
old mode 100755
new mode 100644
diff --git a/instances/index.html b/instances/index.html
old mode 100755
new mode 100644
diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html
index 997fc39..411c27c 100644
--- a/object-lifecycle/supported-lifecycles/index.html
+++ b/object-lifecycle/supported-lifecycles/index.html
@@ -97,7 +97,8 @@ Supported Lifecycles
 Out of the box, the core StructureMap assembly supports these lifecycles:
 
 Transient -- The default lifecycle.  A new object is created for each logical request to resolve an object graph from the container.
-Singleton -- Only one object instance will be created for the main Container
+Singleton -- Only one object instance will be created for the container and any children or nested containers created by that container
+ContainerScoped -- Only one object instance will be created for unique root, child, or nested container
 AlwaysUnique -- A new object instance is created every time, even within the same object graph
 ThreadLocal -- Only one object instance will be created for the currently executing Thread
 
diff --git a/registration/attributes/index.html b/registration/attributes/index.html
old mode 100755
new mode 100644
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html
old mode 100755
new mode 100644
diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html
old mode 100755
new mode 100644
diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html
old mode 100755
new mode 100644
diff --git a/registration/policies/index.html b/registration/policies/index.html
old mode 100755
new mode 100644
diff --git a/setter-injection/index.html b/setter-injection/index.html
old mode 100755
new mode 100644
diff --git a/the-container/buildup/index.html b/the-container/buildup/index.html
old mode 100755
new mode 100644
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html
old mode 100755
new mode 100644
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html
old mode 100755
new mode 100644
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html
old mode 100755
new mode 100644
diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html
old mode 100755
new mode 100644

From 32a7e316f7693e6acfb9e3be491fdd45b7b21afa Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Fri, 16 Oct 2015 08:04:08 -0500
Subject: [PATCH 32/55] Documentation Update

---
 the-container/disposing/index.html         | 16 +++++++++++++---
 the-container/nested-containers/index.html | 20 ++++++++++++++++----
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html
index 9f40665..3c06800 100644
--- a/the-container/disposing/index.html
+++ b/the-container/disposing/index.html
@@ -125,7 +125,7 @@ Singletons
 Ejecting a singleton-scoped object will also force it to be disposed. See Using the Container Model for more information on how to eject singletons
 from a running Container.
 Nested Containers
-As discussed in Nested Containers (Per Request/Transaction), any transient or container-scoped object that implements IDisposable and is created
+
As discussed in Nested Containers (Per Request/Transaction), any transient, AlwaysUnique (as of 4.0), or container-scoped object that implements IDisposable and is created
 by a nested container will be disposed as the nested container is disposed:
 
         [Test]
@@ -138,11 +138,15 @@ Nested Containers
 
                 // A transient scoped service
                 _.For<IColor>().Use<Green>();
+
+                // An AlwaysUnique scoped service
+                _.For<Purple>().AlwaysUnique();
             });
 
             ColorCache singleton = null;
             Green nestedGreen = null;
             Blue nestedBlue = null;
+            Purple nestedPurple = null;
 
             using (var nested = container.GetNestedContainer())
             {
@@ -155,14 +159,20 @@ Nested Containers
 
 
                 nestedBlue = nested.GetInstance<Blue>();
+
+                nestedPurple = nested.GetInstance<Purple>();
             }
 
             // Transients created by the Nested Container
-            // are disposed, but no other lifecycle is
-            // disposed
+            // are disposed
             nestedGreen.WasDisposed.ShouldBeTrue();
             nestedBlue.WasDisposed.ShouldBeTrue();
 
+            // Unique's created by the Nested Container
+            // are disposed
+            nestedPurple.WasDisposed.ShouldBeTrue();
+
+
             // NOT disposed because it's owned by
             // the parent container
             singleton.WasDisposed.ShouldBeFalse();
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html
index 6672358..29fa557 100644
--- a/the-container/nested-containers/index.html
+++ b/the-container/nested-containers/index.html
@@ -187,7 +187,7 @@ Lifecycle Rules
         }
 
 
-Instance's scoped to anything but Transient are resolved as normal, but through the parent container:
+Instance's scoped to anything but Transient or AlwaysUnique are resolved as normal, but through the parent container:
 
         [Test]
         public void nested_container_usage_of_singletons()
@@ -208,7 +208,7 @@ Lifecycle Rules
 See <linkto:object-lifecycle]> for more information on supported object lifecycles.
 Overriding Services from the Parent
 A nested container is a new Container object that still retains access to the parent container that created it so that it can
-efficiently share registrations, policies, and cached build plan's. You can, however, register register services into the nested container that override the parent container.
+efficiently share registrations, policies, and cached build plan's. You can, however, register services into the nested container that override the parent container.
 There is no need to recreate registrations from the parent container
 into the nested container and doing so makes StructureMap work less efficiently.
 The FubuMVC web framework uses a nested container per HTTP request. During an HTTP request, FubuMVC injects services
@@ -325,11 +325,15 @@ 
Disposing Services
 
                 // A transient scoped service
                 _.For<IColor>().Use<Green>();
+
+                // An AlwaysUnique scoped service
+                _.For<Purple>().AlwaysUnique();
             });
 
             ColorCache singleton = null;
             Green nestedGreen = null;
             Blue nestedBlue = null;
+            Purple nestedPurple = null;
 
             using (var nested = container.GetNestedContainer())
             {
@@ -342,14 +346,20 @@ Disposing Services
 
 
                 nestedBlue = nested.GetInstance<Blue>();
+
+                nestedPurple = nested.GetInstance<Purple>();
             }
 
             // Transients created by the Nested Container
-            // are disposed, but no other lifecycle is
-            // disposed
+            // are disposed
             nestedGreen.WasDisposed.ShouldBeTrue();
             nestedBlue.WasDisposed.ShouldBeTrue();
 
+            // Unique's created by the Nested Container
+            // are disposed
+            nestedPurple.WasDisposed.ShouldBeTrue();
+
+
             // NOT disposed because it's owned by
             // the parent container
             singleton.WasDisposed.ShouldBeFalse();
@@ -366,6 +376,8 @@ Disposing Services
     {
     }
 
+    public class Purple : Blue  {  }
+
     public class Blue : IColor, IDisposable
     {
         public bool WasDisposed;

From 2be97a00cacebdf82381409681b440b7d5aac825 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Mon, 16 Nov 2015 15:41:01 -0600
Subject: [PATCH 33/55] Documentation Update

---
 best-practices/index.html                     | 306 ++++++++--------
 diagnostics/build-plans/index.html            | 306 ++++++++--------
 diagnostics/environment-tests/index.html      | 306 ++++++++--------
 diagnostics/index.html                        | 306 ++++++++--------
 .../using-the-container-model/index.html      | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 diagnostics/whatdoihave/index.html            | 306 ++++++++--------
 features/index.html                           | 306 ++++++++--------
 get-structuremap/index.html                   | 306 ++++++++--------
 glossary/index.html                           | 306 ++++++++--------
 history/index.html                            | 306 ++++++++--------
 integrations/index.html                       | 306 ++++++++--------
 interception-and-decorators/index.html        | 306 ++++++++--------
 interpreting-exceptions/index.html            | 306 ++++++++--------
 .../configuring-lifecycles/index.html         | 306 ++++++++--------
 object-lifecycle/custom-lifecycles/index.html | 306 ++++++++--------
 object-lifecycle/index.html                   | 306 ++++++++--------
 .../supported-lifecycles/index.html           | 306 ++++++++--------
 quickstart/index.html                         | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 registration/constructor-selection/index.html | 306 ++++++++--------
 registration/fallback-services/index.html     | 306 ++++++++--------
 registration/index.html                       | 306 ++++++++--------
 registration/inline-dependencies/index.html   | 306 ++++++++--------
 .../on-missing-family-policies/index.html     | 306 ++++++++--------
 registration/registry-dsl/index.html          | 306 ++++++++--------
 release-notes/index.html                      | 327 ++++++++++--------
 .../index.html                                | 306 ++++++++--------
 .../get-a-service-by-plugintype/index.html    | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 resolving/index.html                          | 306 ++++++++--------
 .../passing-arguments-at-runtime/index.html   | 306 ++++++++--------
 .../requesting-a-concrete-type/index.html     | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 roadmap/index.html                            | 314 ++++++++---------
 software-design-concepts/index.html           | 306 ++++++++--------
 the-container/auto-wiring/index.html          | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 the-container/index.html                      | 306 ++++++++--------
 the-container/nested-containers/index.html    | 306 ++++++++--------
 .../profiles-and-child-containers/index.html  | 306 ++++++++--------
 .../working-with-enumerable-types/index.html  | 306 ++++++++--------
 .../index.html                                | 306 ++++++++--------
 46 files changed, 7063 insertions(+), 7042 deletions(-)

diff --git a/best-practices/index.html b/best-practices/index.html
index 2b6142a..93b606d 100644
--- a/best-practices/index.html
+++ b/best-practices/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Best Practices
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Best Practices
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
History
-		        	Previous
Diagnostics
-
-


-		      
-		      
-		      
-			      	Best Practices
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Best Practices
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Best Practices
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
History
+		        	Previous
Diagnostics
+
+


+		      
+		      
+		      
+			      	Best Practices
+			      
+			      	
+
+			      	
 			      		
 
 All of these recommendations are the opinions and sole responsiblity of one Jeremy D. Miller. The single best advice I can give you
@@ -131,62 +131,62 @@ 
Favor Build Policies over Fancy Runtime Decision Making
 I recommend trying to "bake in" building decisions upfront with build policies for more efficient object resolution and so that
 the container behavior is surfaced through diagnostics like the build plan visualization.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Diagnostics
-
-				        
-				        
-
-				        	Next: History
-
-				        
-			      	
-
-		      

-


-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+


+
+			      	
+
+			      	
+				        
+				        	Previous: Diagnostics
+
+				        
+				        
+
+				        	Next: History
+
+				        
+			      	
+
+


+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html
index 45f759c..de0d84b 100644
--- a/diagnostics/build-plans/index.html
+++ b/diagnostics/build-plans/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Build Plans
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Build Plans
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Using the Container Model
-		        	Previous
Environment Tests
-
-


-		      
-		      
-		      
-			      	Build Plans
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Build Plans
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Diagnostics
Build Plans
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Using the Container Model
+		        	Previous
Environment Tests
+
+


+		      
+		      
+		      
+			      	Build Plans
+			      
+			      	
+
+			      	
 			      		
 
 StructureMap 3.0 introduced the concept of the "Build Plan." The build plan is a textual representation of exactly how StructureMap will build a given Instance, including:
@@ -134,62 +134,62 @@ Build Plans
 See Using the Container Model for more information on using Container.Model.
 You can find many more examples of finding the build plan description from Container.Model from the unit tests in the StructureMap codebase.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Environment Tests
-
-				        
-				        
-
-				        	Next: Using the Container Model
-
-				        
-			      	
-
-		      

-


-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+


+
+			      	
+
+			      	
+				        
+				        	Previous: Environment Tests
+
+				        
+				        
+
+				        	Next: Using the Container Model
+
+				        
+			      	
+
+


+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html
index ccfe8e0..208c4df 100644
--- a/diagnostics/environment-tests/index.html
+++ b/diagnostics/environment-tests/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Environment Tests
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Environment Tests
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Build Plans
-		        	Previous
Validating Container Configuration
-
-		        
-		      

-		      
-		      
-		      
-			      	Environment Tests
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Environment Tests
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Diagnostics
Environment Tests
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Build Plans
+		        	Previous
Validating Container Configuration
+
+		        
+		      

+		      
+		      
+		      
+			      	Environment Tests
+			      
+			      	
+
+			      	
 			      		
 
 Years ago I worked with a legacy system that was particularly fragile in its deployment. While my team at the time and I made some serious improvements in the reliability of the automated deployment, the best thing we did was to add a set of environment tests to the deployment that verified that basic elements of the system were working like:
@@ -118,62 +118,62 @@ Environment Tests
 
 Used in conjunction with StructureMap's ability to validate a container, you can use this technique to quickly support environment tests embedded into your system code.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Validating Container Configuration
-
-				        
-				        
-
-				        	Next: Build Plans
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Validating Container Configuration
+
+				        
+				        
+
+				        	Next: Build Plans
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/diagnostics/index.html b/diagnostics/index.html
index 8aa3df9..be38dc8 100644
--- a/diagnostics/index.html
+++ b/diagnostics/index.html
@@ -1,158 +1,158 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Diagnostics
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
WhatDoIHave()
-		        	Previous
Interpreting Exceptions
-
-		        
-		      

-		      
-		      
-		      
-			      	Diagnostics
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Diagnostics
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Diagnostics
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
WhatDoIHave()
+		        	Previous
Interpreting Exceptions
+
+		        
+		      

+		      
+		      
+		      
+			      	Diagnostics
+			      
+			      	
+
+			      	
 			      		
 Improving StructureMap's ability to diagnose and explain both configuration and runtime problems was a very big goal
 for the big 3.0 release and improved with additional type scanning diagnostics for 4.0.
 WhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Interpreting Exceptions
-
-				        
-				        
-
-				        	Next: WhatDoIHave()
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Interpreting Exceptions
+
+				        
+				        
+
+				        	Next: WhatDoIHave()
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html
index f059e88..ff4d0b3 100644
--- a/diagnostics/using-the-container-model/index.html
+++ b/diagnostics/using-the-container-model/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Using the Container Model
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Using the Container Model
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Type Scanning Diagnostics
-		        	Previous
Build Plans
-
-		        
-		      

-		      
-		      
-		      
-			      	Using the Container Model
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Using the Container Model
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Diagnostics
Using the Container Model
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Type Scanning Diagnostics
+		        	Previous
Build Plans
+
+		        
+		      

+		      
+		      
+		      
+			      	Using the Container Model
+			      
+			      	
+
+			      	
 			      		
 
 The queryable Container.Model is a power facility to look into your StructureMap Container and even to eject previously built services from the Container. The Container.Model represents a static view of what a Container already has, and does not account for policies that may allow StructureMap to validly discover types that it may encounter later at runtime.
@@ -209,62 +209,62 @@ Working with Individual Instances
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Build Plans
-
-				        
-				        
-
-				        	Next: Type Scanning Diagnostics
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Build Plans
+
+				        
+				        
+
+				        	Next: Type Scanning Diagnostics
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html
index a0d6333..c51fa91 100644
--- a/diagnostics/validating-container-configuration/index.html
+++ b/diagnostics/validating-container-configuration/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Validating Container Configuration
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Validating Container Configuration
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Environment Tests
-		        	Previous
WhatDoIHave()
-
-		        
-		      

-		      
-		      
-		      
-			      	Validating Container Configuration
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Validating Container Configuration
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Diagnostics
Validating Container Configuration
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Environment Tests
+		        	Previous
WhatDoIHave()
+
+		        
+		      

+		      
+		      
+		      
+			      	Validating Container Configuration
+			      
+			      	
+
+			      	
 			      		
 
 To find any potential holes in your StructureMap configuration like missing dependencies, unclear defaults of plugin types, validation errors, or just plain build errors, you can use this method below:
@@ -123,62 +123,62 @@ Validating Container Configuration
 Standin Dependencies for Runtime Dependencies
 If you take advantage of StructureMap's ability to supply arguments at runtime, you may need to add fake or stubbed stand in services to StructureMap just to satisfy dependencies while calling Container.AssertConfigurationIsValid(). For example, in FubuMVC we supply several services representing an HTTP request as explicit arguments. In order to use the container validation, we have to register stand in services in the main container.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: WhatDoIHave()
-
-				        
-				        
-
-				        	Next: Environment Tests
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: WhatDoIHave()
+
+				        
+				        
+
+				        	Next: Environment Tests
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html
index 06481aa..81ac269 100644
--- a/diagnostics/whatdoihave/index.html
+++ b/diagnostics/whatdoihave/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - WhatDoIHave()
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
WhatDoIHave()
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Validating Container Configuration
-		        	Previous
Diagnostics
-
-		        
-		      

-		      
-		      
-		      
-			      	WhatDoIHave()
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - WhatDoIHave()
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Diagnostics
WhatDoIHave()
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Validating Container Configuration
+		        	Previous
Diagnostics
+
+		        
+		      

+		      
+		      
+		      
+			      	WhatDoIHave()
+			      
+			      	
+
+			      	
 			      		
 
 The IContainer.WhatDoIHave() method can give you a quick textual report of the current configuration of a running Container:
@@ -148,62 +148,62 @@ Filtering WhatDoIHave()
             var byType = container.WhatDoIHave(typeName: "Widget");
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Diagnostics
-
-				        
-				        
-
-				        	Next: Validating Container Configuration
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Diagnostics
+
+				        
+				        
+
+				        	Next: Validating Container Configuration
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/features/index.html b/features/index.html
index 8b9369d..be743de 100644
--- a/features/index.html
+++ b/features/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Features
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Features
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Software Design Concepts
-		        	Previous
Get StructureMap
-
-		        
-		      

-		      
-		      
-		      
-			      	Features
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Features
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Features
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Software Design Concepts
+		        	Previous
Get StructureMap
+
+		        
+		      

+		      
+		      
+		      
+			      	Features
+			      
+			      	
+
+			      	
 			      		
 
 Note! The StructureMap team will accept pull requests if there's something missing from this list that you'd like to add.
@@ -131,62 +131,62 @@ Things StructureMap does not have
 Note! The StructureMap team strongly feels that Xml configuration is both undesirable and unnecessary. Please feel free to use the Google user group to ask for advice on how to move away from Xml configuration in existing applications.
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Get StructureMap
-
-				        
-				        
-
-				        	Next: Software Design Concepts
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Get StructureMap
+
+				        
+				        
+
+				        	Next: Software Design Concepts
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/get-structuremap/index.html b/get-structuremap/index.html
index 9fa8eb2..3683043 100644
--- a/get-structuremap/index.html
+++ b/get-structuremap/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Get StructureMap
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Get StructureMap
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Features
-		        	Previous
Glossary
-
-		        
-		      

-		      
-		      
-		      
-			      	Get StructureMap
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Get StructureMap
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Get StructureMap
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Features
+		        	Previous
Glossary
+
+		        
+		      

+		      
+		      
+		      
+			      	Get StructureMap
+			      
+			      	
+
+			      	
 			      		
 
 Current Release
@@ -111,62 +111,62 @@ Source
 StructureMap's source is hosted on GitHub. If you want to fix a bug or just want to tinker with an idea, we love receiving pull requests! Start by creating your own fork on Github.
 The StructureMap build tooling has recently changed. See the GitHub README for more information on how to build and work with the StructureMap codebase.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Glossary
-
-				        
-				        
-
-				        	Next: Features
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Glossary
+
+				        
+				        
+
+				        	Next: Features
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/glossary/index.html b/glossary/index.html
index 63bca3b..28bac17 100644
--- a/glossary/index.html
+++ b/glossary/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Glossary
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Glossary
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Get StructureMap
-		        	Previous
A Gentle Quickstart
-
-		        
-		      

-		      
-		      
-		      
-			      	Glossary
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Glossary
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Glossary
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Get StructureMap
+		        	Previous
A Gentle Quickstart
+
+		        
+		      

+		      
+		      
+		      
+			      	Glossary
+			      
+			      	
+
+			      	
 			      		
 There are some terms that reoccur throughout the documentation and show up in the StructureMap API. Understanding these terms and how they relate to StructureMap isn't a prerequisite to using StructureMap, but it helps.
 Container
@@ -283,62 +283,62 @@ Auto wiring
 
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: A Gentle Quickstart
-
-				        
-				        
-
-				        	Next: Get StructureMap
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: A Gentle Quickstart
+
+				        
+				        
+
+				        	Next: Get StructureMap
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/history/index.html b/history/index.html
index cb21521..4c236df 100644
--- a/history/index.html
+++ b/history/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - History
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
History
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Release Notes
-		        	Previous
Best Practices
-
-		        
-		      

-		      
-		      
-		      
-			      	History
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - History
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
History
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Release Notes
+		        	Previous
Best Practices
+
+		        
+		      

+		      
+		      
+		      
+			      	History
+			      
+			      	
+
+			      	
 			      		
 
 StructureMap was originally conceived in 2002 as the world's greatest object/relational mapping tool (and frankly a way for me to
@@ -105,62 +105,62 @@ 
History
 To learn more about the StructureMap journey, see the Joys and Pains of a Long Lived Codebase on InfoQ from QCon 2008, or check out
 Jeremy Miller's updated retrospective talk at CodeMash 2015.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Best Practices
-
-				        
-				        
-
-				        	Next: Release Notes
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Best Practices
+
+				        
+				        
+
+				        	Next: Release Notes
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/integrations/index.html b/integrations/index.html
index c6a1667..d49f35b 100644
--- a/integrations/index.html
+++ b/integrations/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Integrating StructureMap into Common .Net Frameworks
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Integrating StructureMap into Common .Net Frameworks
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	
-		        	Previous
Custom Instance Types
-
-		        
-		      

-		      
-		      
-		      
-			      	Integrating StructureMap into Common .Net Frameworks
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Integrating StructureMap into Common .Net Frameworks
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Integrating StructureMap into Common .Net Frameworks
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	
+		        	Previous
Custom Instance Types
+
+		        
+		      

+		      
+		      
+		      
+			      	Integrating StructureMap into Common .Net Frameworks
+			      
+			      	
+
+			      	
 			      		
 Want to see more integrations or samples of how to integrate StructureMap with various .Net development tools? Let us know in Gitter or Github, or better yet, we take pull requests for documentation.
 ASP.Net MVC 5
@@ -119,62 +119,62 @@ Entity Framework
 AutoMapper
 See My AutoMapper setup for StructureMap from Martijn Burgers.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Custom Instance Types
-
-				        
-				        
-
-				        	
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Custom Instance Types
+
+				        
+				        
+
+				        	
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html
index 661cff5..cb5dce8 100644
--- a/interception-and-decorators/index.html
+++ b/interception-and-decorators/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Interception and Decorators
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Interception and Decorators
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Interpreting Exceptions
-		        	Previous
Generic Types
-
-		        
-		      

-		      
-		      
-		      
-			      	Interception and Decorators
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Interception and Decorators
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Interception and Decorators
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Interpreting Exceptions
+		        	Previous
Generic Types
+
+		        
+		      

+		      
+		      
+		      
+			      	Interception and Decorators
+			      
+			      	
+
+			      	
 			      		
 
 All of the samples from this topic are part of the user acceptance tests in the main codebase. There is also another example of using an interception policy with
@@ -425,62 +425,62 @@ 
Add Interception to a Single Instance
                 });
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Generic Types
-
-				        
-				        
-
-				        	Next: Interpreting Exceptions
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Generic Types
+
+				        
+				        
+
+				        	Next: Interpreting Exceptions
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html
index 370fb31..87ea3fb 100644
--- a/interpreting-exceptions/index.html
+++ b/interpreting-exceptions/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Interpreting Exceptions
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Interpreting Exceptions
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Diagnostics
-		        	Previous
Interception and Decorators
-
-		        
-		      

-		      
-		      
-		      
-			      	Interpreting Exceptions
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Interpreting Exceptions
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Interpreting Exceptions
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Diagnostics
+		        	Previous
Interception and Decorators
+
+		        
+		      

+		      
+		      
+		      
+			      	Interpreting Exceptions
+			      
+			      	
+
+			      	
 			      		
 
 Improving the exception messages was one of the primary goals of the big StructureMap 3.0 release. StructureMap exceptions should
@@ -110,62 +110,62 @@ 
Interpreting Exceptions
 StructureMapConfigurationException -- thrown by the container validation mechanism

-
-


-
-			      	
-
-			      	
-				        
-				        	Previous: Interception and Decorators
-
-				        
-				        
-
-				        	Next: Diagnostics
-
-				        
-			      	
-
-


-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+


+
+			      	
+
+			      	
+				        
+				        	Previous: Interception and Decorators
+
+				        
+				        
+
+				        	Next: Diagnostics
+
+				        
+			      	
+
+


+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html
index a07cd71..2d39828 100644
--- a/object-lifecycle/configuring-lifecycles/index.html
+++ b/object-lifecycle/configuring-lifecycles/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Configuring Lifecycles
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Object Lifecycles
Configuring Lifecycles
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Custom Lifecycles
-		        	Previous
Supported Lifecycles
-
-		        
-		      

-		      
-		      
-		      
-			      	Configuring Lifecycles
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Configuring Lifecycles
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Object Lifecycles
Configuring Lifecycles
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Custom Lifecycles
+		        	Previous
Supported Lifecycles
+
+		        
+		      

+		      
+		      
+		      
+			      	Configuring Lifecycles
+			      
+			      	
+
+			      	
 			      		
 
 Unless designated otherwise, StructureMap uses Transient as the default scope for all configured Instance's.
@@ -159,62 +159,62 @@ Using Attributes
 
 See Using Attributes for Configuration for information about adding your own custom attibutes for other lifecycles.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Supported Lifecycles
-
-				        
-				        
-
-				        	Next: Custom Lifecycles
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Supported Lifecycles
+
+				        
+				        
+
+				        	Next: Custom Lifecycles
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html
index 5435711..3c294c2 100644
--- a/object-lifecycle/custom-lifecycles/index.html
+++ b/object-lifecycle/custom-lifecycles/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Custom Lifecycles
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Object Lifecycles
Custom Lifecycles
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Generic Types
-		        	Previous
Configuring Lifecycles
-
-		        
-		      

-		      
-		      
-		      
-			      	Custom Lifecycles
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Custom Lifecycles
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Object Lifecycles
Custom Lifecycles
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Generic Types
+		        	Previous
Configuring Lifecycles
+
+		        
+		      

+		      
+		      
+		      
+			      	Custom Lifecycles
+			      
+			      	
+
+			      	
 			      		
 
 Lifecycle's in StructureMap are pluggable.  To create your own custom lifecycle, make an implementation of the ILifecycle interface like this one:
@@ -139,62 +139,62 @@ Custom Lifecycles
 
 Most of the built in ILifecycle implementations use LifecycleObjectCache internally, but you may also need to create your own IObjectCache implementation.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Configuring Lifecycles
-
-				        
-				        
-
-				        	Next: Generic Types
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Configuring Lifecycles
+
+				        
+				        
+
+				        	Next: Generic Types
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html
index 15a9ef8..327720a 100644
--- a/object-lifecycle/index.html
+++ b/object-lifecycle/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Object Lifecycles
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Object Lifecycles
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Supported Lifecycles
-		        	Previous
The Container
-
-		        
-		      

-		      
-		      
-		      
-			      	Object Lifecycles
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Object Lifecycles
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Object Lifecycles
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Supported Lifecycles
+		        	Previous
The Container
+
+		        
+		      

+		      
+		      
+		      
+			      	Object Lifecycles
+			      
+			      	
+
+			      	
 			      		
 
 One of the most valuable functions of using an IoC container tool is its ability to manage the object lifecycle (creating and disposing objects) and scoping (shared objects)
@@ -153,62 +153,62 @@ 
Motivation for Container Managed Scope
 The big advantage to the second, StructureMap-managed singleton scoping is that my DependencyUser class does not have to have any knowledge of
 how the ISingletonDependency object is built and certainly no coupling to the hard Singleton mechanics from the first sample that was so harmful in the past.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: The Container
-
-				        
-				        
-
-				        	Next: Supported Lifecycles
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: The Container
+
+				        
+				        
+
+				        	Next: Supported Lifecycles
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html
index 411c27c..66af742 100644
--- a/object-lifecycle/supported-lifecycles/index.html
+++ b/object-lifecycle/supported-lifecycles/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Supported Lifecycles
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Object Lifecycles
Supported Lifecycles
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Configuring Lifecycles
-		        	Previous
Object Lifecycles
-
-		        
-		      

-		      
-		      
-		      
-			      	Supported Lifecycles
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Supported Lifecycles
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Object Lifecycles
Supported Lifecycles
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Configuring Lifecycles
+		        	Previous
Object Lifecycles
+
+		        
+		      

+		      
+		      
+		      
+			      	Supported Lifecycles
+			      
+			      	
+
+			      	
 			      		
 
 Out of the box, the core StructureMap assembly supports these lifecycles:
@@ -511,62 +511,62 @@ Legacy ASP.Net Lifecycles
  
 at the end of your HTTP request.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Object Lifecycles
-
-				        
-				        
-
-				        	Next: Configuring Lifecycles
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Object Lifecycles
+
+				        
+				        
+
+				        	Next: Configuring Lifecycles
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/quickstart/index.html b/quickstart/index.html
index eb721cd..ac94195 100644
--- a/quickstart/index.html
+++ b/quickstart/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - A Gentle Quickstart
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
A Gentle Quickstart
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Glossary
-		        	Previous
Roadmap
-
-		        
-		      

-		      
-		      
-		      
-			      	A Gentle Quickstart
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - A Gentle Quickstart
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
A Gentle Quickstart
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Glossary
+		        	Previous
Roadmap
+
+		        
+		      

+		      
+		      
+		      
+			      	A Gentle Quickstart
+			      
+			      	
+
+			      	
 			      		
 
 The first thing you should know is that StructureMap (and other IoC tools like it) are designed to
@@ -189,62 +189,62 @@ 
Need Help?
 You can ask questions on StackOverflow with the tag "structuremap."
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Roadmap
-
-				        
-				        
-
-				        	Next: Glossary
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Roadmap
+
+				        
+				        
+
+				        	Next: Glossary
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html
index 67c5b9f..2dda3c4 100644
--- a/registration/auto-registration-and-conventions/index.html
+++ b/registration/auto-registration-and-conventions/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Auto-Registration and Conventions
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Auto-Registration and Conventions
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Working with IConfiguredInstance
-		        	Previous
Inline Dependencies
-
-		        
-		      

-		      
-		      
-		      
-			      	Auto-Registration and Conventions
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Auto-Registration and Conventions
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Auto-Registration and Conventions
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Working with IConfiguredInstance
+		        	Previous
Inline Dependencies
+
+		        
+		      

+		      
+		      
+		      
+			      	Auto-Registration and Conventions
+			      
+			      	
+
+			      	
 			      		
 
 The type scanning facilities were completely overhauled and greatly optimized for performance as part of the StructureMap 4.0 release. The mechanism for custom registration conventions is somewhat different from 2.5-3.* to 4.0.
@@ -416,62 +416,62 @@ Register Concrete Types against the First Interface
             });
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Inline Dependencies
-
-				        
-				        
-
-				        	Next: Working with IConfiguredInstance
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Inline Dependencies
+
+				        
+				        
+
+				        	Next: Working with IConfiguredInstance
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html
index 7a9af02..fa981a1 100644
--- a/registration/changing-configuration-at-runtime/index.html
+++ b/registration/changing-configuration-at-runtime/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Changing Configuration at Runtime
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Changing Configuration at Runtime
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
On Missing Family Policies
-		        	Previous
Construction Policies
-
-		        
-		      

-		      
-		      
-		      
-			      	Changing Configuration at Runtime
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Changing Configuration at Runtime
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Changing Configuration at Runtime
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
On Missing Family Policies
+		        	Previous
Construction Policies
+
+		        
+		      

+		      
+		      
+		      
+			      	Changing Configuration at Runtime
+			      
+			      	
+
+			      	
 			      		
 
 Use the technique shown here with caution.
@@ -129,62 +129,62 @@ Best Practices
 the potential new configuration.
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Construction Policies
-
-				        
-				        
-
-				        	Next: On Missing Family Policies
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Construction Policies
+
+				        
+				        
+
+				        	Next: On Missing Family Policies
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html
index 71852d8..4ec2ad3 100644
--- a/registration/constructor-selection/index.html
+++ b/registration/constructor-selection/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Constructor Selection
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Constructor Selection
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Fallback Services
-		        	Previous
On Missing Family Policies
-
-		        
-		      

-		      
-		      
-		      
-			      	Constructor Selection
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Constructor Selection
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Constructor Selection
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Fallback Services
+		        	Previous
On Missing Family Policies
+
+		        
+		      

+		      
+		      
+		      
+			      	Constructor Selection
+			      
+			      	
+
+			      	
 			      		
 
 StructureMap 3.* greatly improves the control over the selection of constructor functions to build concrete types
@@ -295,62 +295,62 @@ 
Custom Constructor Selection Rule
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: On Missing Family Policies
-
-				        
-				        
-
-				        	Next: Fallback Services
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: On Missing Family Policies
+
+				        
+				        
+
+				        	Next: Fallback Services
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html
index 7818e4f..7d85371 100644
--- a/registration/fallback-services/index.html
+++ b/registration/fallback-services/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Fallback Services
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Fallback Services
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Registering Existing Objects
-		        	Previous
Constructor Selection
-
-		        
-		      

-		      
-		      
-		      
-			      	Fallback Services
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Fallback Services
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Fallback Services
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Registering Existing Objects
+		        	Previous
Constructor Selection
+
+		        
+		      

+		      
+		      
+		      
+			      	Fallback Services
+			      
+			      	
+
+			      	
 			      		
 
 The following is a technique that was stolen from FubuMVC where we used
@@ -177,62 +177,62 @@ 
Fallback Services
         }
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Constructor Selection
-
-				        
-				        
-
-				        	Next: Registering Existing Objects
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Constructor Selection
+
+				        
+				        
+
+				        	Next: Registering Existing Objects
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/index.html b/registration/index.html
index 96503bc..cdfc503 100644
--- a/registration/index.html
+++ b/registration/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Registration
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Registry DSL
-		        	Previous
Setter Injection
-
-		        
-		      

-		      
-		      
-		      
-			      	Registration
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Registration
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Registry DSL
+		        	Previous
Setter Injection
+
+		        
+		      

+		      
+		      
+		      
+			      	Registration
+			      
+			      	
+
+			      	
 			      		
 
 As of the 3.0 release, StructureMap provides a streamlined fluent interface called the Registry DSL to configure a StructureMap
@@ -205,62 +205,62 @@ 
Registration
 
 So far you have seen an couple of ways to work with the <linkto:registration/registry-dsl]> and configure an Container object. We have seen examples of configuration that allows us to build objects that doesn't depend on anything like the Bar class, or do depend on other types like the Foo class needs an instance of IBar. In our last example we have seen configuration for objects that needs some primitive types like strings in its constructor function.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Setter Injection
-
-				        
-				        
-
-				        	Next: Registry DSL
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Setter Injection
+
+				        
+				        
+
+				        	Next: Registry DSL
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html
index 2a9f568..aef0ab1 100644
--- a/registration/inline-dependencies/index.html
+++ b/registration/inline-dependencies/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Inline Dependencies
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Inline Dependencies
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Auto-Registration and Conventions
-		        	Previous
Registry DSL
-
-		        
-		      

-		      
-		      
-		      
-			      	Inline Dependencies
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Inline Dependencies
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Inline Dependencies
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Auto-Registration and Conventions
+		        	Previous
Registry DSL
+
+		        
+		      

+		      
+		      
+		      
+			      	Inline Dependencies
+			      
+			      	
+
+			      	
 			      		
 
 While you generally allow StructureMap to just use auto-wiring to fill the dependencies of a concrete type, there are times
@@ -461,62 +461,62 @@ 
Programmatic Configuration outside of the Registry DSL
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Registry DSL
-
-				        
-				        
-
-				        	Next: Auto-Registration and Conventions
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Registry DSL
+
+				        
+				        
+
+				        	Next: Auto-Registration and Conventions
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html
index c9408ed..474cc64 100644
--- a/registration/on-missing-family-policies/index.html
+++ b/registration/on-missing-family-policies/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - On Missing Family Policies
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
On Missing Family Policies
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Constructor Selection
-		        	Previous
Changing Configuration at Runtime
-
-		        
-		      

-		      
-		      
-		      
-			      	On Missing Family Policies
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - On Missing Family Policies
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
On Missing Family Policies
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Constructor Selection
+		        	Previous
Changing Configuration at Runtime
+
+		        
+		      

+		      
+		      
+		      
+			      	On Missing Family Policies
+			      
+			      	
+
+			      	
 			      		
 
 New for StructureMap 3.0 is a feature to create missing service registrations at runtime based on pluggable rules using the new IFamilyPolicy
@@ -293,62 +293,62 @@ 
Using a Custom IFamilyPolicy" id="custom">
 
 You can see the real implementation of the SettingPolicy in action in its integration tests on GitHub.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Changing Configuration at Runtime
-
-				        
-				        
-
-				        	Next: Constructor Selection
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Changing Configuration at Runtime
+
+				        
+				        
+
+				        	Next: Constructor Selection
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html
index 737975e..8059784 100644
--- a/registration/registry-dsl/index.html
+++ b/registration/registry-dsl/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Registry DSL
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Registration
Registry DSL
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Inline Dependencies
-		        	Previous
Registration
-
-		        
-		      

-		      
-		      
-		      
-			      	Registry DSL
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Registry DSL
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Registration
Registry DSL
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Inline Dependencies
+		        	Previous
Registration
+
+		        
+		      

+		      
+		      
+		      
+			      	Registry DSL
+			      
+			      	
+
+			      	
 			      		
 
 Creating Registry classes is the recommended way of using the Registry DSL.
@@ -269,62 +269,62 @@ Named Instances
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Registration
-
-				        
-				        
-
-				        	Next: Inline Dependencies
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Registration
+
+				        
+				        
+
+				        	Next: Inline Dependencies
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/release-notes/index.html b/release-notes/index.html
index 50a3439..cd0da00 100644
--- a/release-notes/index.html
+++ b/release-notes/index.html
@@ -1,100 +1,121 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Release Notes
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Release Notes
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Custom Instance Types
-		        	Previous
History
-
-		        
-		      

-		      
-		      
-		      
-			      	Release Notes
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Release Notes
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Release Notes
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Custom Instance Types
+		        	Previous
History
+
+		        
+		      

+		      
+		      
+		      
+			      	Release Notes
+			      
+			      	
+
+			      	
 			      		
 
 StructureMap is attempting to follow a strict SemVer versioning policy.
+Release Nodes 4.0
+4.0 is a medium sized release that largely builds on the existing 3.0 architecture with significant improvements to conventional
+registration via type scanning and several performance improvements as well as some bug fixes.
+The highlights:
+
+We believe that the documentation is finally comprehensive in regards to StructureMap behavior and features
+The type scanning model (Registry.Scan()) was completely rebuilt to make the model easier to extend and to
+optimize application bootstrapping in systems that heavily rely on StructureMap type scanning. See Auto-Registration and Conventions for more information.
+New diagnostic method specifically for troubleshooting type scanning problems. See Type Scanning Diagnostics for more information.
+New concept of a "build time Instance convention" to apply much more powerful policies and conventions against your StructureMap registrations
+as a whole. See Construction Policies for more information.
+Runtime performance improvements
+Hardened StructureMap for multi-threaded usage
+Performance improvements specifically targeted at usage from within ASP.Net MVC and its particular manner of using IoC tools.
+Removed the static ObjectFactory facade over the application Container altogether.
+Enhanced lifecycle support for compliance with ASP.Net MVC6. Nested containers track and dispose AlwaysUnique objects, the new ContainerScoped
+lifecyle, and an optional mode to make the root or child containers track Transient disposable objects. See Object Lifecycles and Nested Containers (Per Request/Transaction) for more information.
+Registry.For<T>().ClearAll() and Registry.For(Type).ClearAll() methods for removing all previous registrations for a type. See
+Replace or Clear Out Previous Registrations for more information.
+
+See also the complete list of changes and issues for StructureMap 4.0.
 3.1.*
 Click on any release version to see the list of closed GitHub issues related to any of the 3.1 releases.
 
@@ -166,62 +187,62 @@ Release Notes 3.0
 http://jeremydmiller.com/2013/01/30/lets-try-this-again-structuremap-3-0-in-en-route-as-of-now/
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: History
-
-				        
-				        
-
-				        	Next: Custom Instance Types
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: History
+
+				        
+				        
+
+				        	Next: Custom Instance Types
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html
index 9b985bf..54e190a 100644
--- a/resolving/get-a-service-by-plugin-type-and-name/index.html
+++ b/resolving/get-a-service-by-plugin-type-and-name/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Get a Service by Plugin Type and Name
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Get a Service by Plugin Type and Name
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Get all Services by Plugin Type
-		        	Previous
Get a Service by PluginType
-
-		        
-		      

-		      
-		      
-		      
-			      	Get a Service by Plugin Type and Name
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Get a Service by Plugin Type and Name
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Get a Service by Plugin Type and Name
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Get all Services by Plugin Type
+		        	Previous
Get a Service by PluginType
+
+		        
+		      

+		      
+		      
+		      
+			      	Get a Service by Plugin Type and Name
+			      
+			      	
+
+			      	
 			      		
 
 You can also request a named configuration for a given PluginType by using the overloads of IContainer.GetInstance() that take in a name like this:
@@ -119,62 +119,62 @@ Get a Service by Plugin Type and Name
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Get a Service by PluginType
-
-				        
-				        
-
-				        	Next: Get all Services by Plugin Type
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Get a Service by PluginType
+
+				        
+				        
+
+				        	Next: Get all Services by Plugin Type
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html
index 9bc3630..1734273 100644
--- a/resolving/get-a-service-by-plugintype/index.html
+++ b/resolving/get-a-service-by-plugintype/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Get a Service by PluginType
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Get a Service by PluginType
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Get a Service by Plugin Type and Name
-		        	Previous
Resolving Services
-
-		        
-		      

-		      
-		      
-		      
-			      	Get a Service by PluginType
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Get a Service by PluginType
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Get a Service by PluginType
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Get a Service by Plugin Type and Name
+		        	Previous
Resolving Services
+
+		        
+		      

+		      
+		      
+		      
+			      	Get a Service by PluginType
+			      
+			      	
+
+			      	
 			      		
 
 Requesting the default configured object of a plugin type is done through the IContainer.GetInstance() method shown below:
@@ -112,62 +112,62 @@ Get a Service by PluginType
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Resolving Services
-
-				        
-				        
-
-				        	Next: Get a Service by Plugin Type and Name
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Resolving Services
+
+				        
+				        
+
+				        	Next: Get a Service by Plugin Type and Name
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html
index 5b1b173..eececf2 100644
--- a/resolving/get-all-services-by-plugin-type/index.html
+++ b/resolving/get-all-services-by-plugin-type/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Get all Services by Plugin Type
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Get all Services by Plugin Type
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Try Getting an Optional Service by Plugin Type
-		        	Previous
Get a Service by Plugin Type and Name
-
-		        
-		      

-		      
-		      
-		      
-			      	Get all Services by Plugin Type
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Get all Services by Plugin Type
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Get all Services by Plugin Type
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Try Getting an Optional Service by Plugin Type
+		        	Previous
Get a Service by Plugin Type and Name
+
+		        
+		      

+		      
+		      
+		      
+			      	Get all Services by Plugin Type
+			      
+			      	
+
+			      	
 			      		
 
 Please see Working with Enumerable Types for a lot more information about what's going on behind the
@@ -123,62 +123,62 @@ 
Get all Services by Plugin Type
 
 GetAllInstances() respects the order in which the actual instances are configured in the Container.  Be warned that some other IoC tools make different assuptions if you are coming from a different tool.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Get a Service by Plugin Type and Name
-
-				        
-				        
-
-				        	Next: Try Getting an Optional Service by Plugin Type
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Get a Service by Plugin Type and Name
+
+				        
+				        
+
+				        	Next: Try Getting an Optional Service by Plugin Type
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/index.html b/resolving/index.html
index dd0d108..5cb720f 100644
--- a/resolving/index.html
+++ b/resolving/index.html
@@ -1,158 +1,158 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Resolving Services
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Get a Service by PluginType
-		        	Previous
Registration
-
-		        
-		      

-		      
-		      
-		      
-			      	Resolving Services
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Resolving Services
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Get a Service by PluginType
+		        	Previous
Registration
+
+		        
+		      

+		      
+		      
+		      
+			      	Resolving Services
+			      
+			      	
+
+			      	
 			      		
 This will be the easy part of interacting with StructureMap. During application execution, you will need to resolve the services you previously registered in the container. When you ask StructureMap to resolve a service, StructureMap either creates a new object instance or finds the previously built object for the correct Object Lifecycles.
 While in many systems you will probably only resolve the default service of a type or a named instance of a service, there are far more ways to resolve services exposed by StructureMap. The IContainer interface acts as a Service Locator to build and resolve configured services on demand.
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Registration
-
-				        
-				        
-
-				        	Next: Get a Service by PluginType
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Registration
+
+				        
+				        
+
+				        	Next: Get a Service by PluginType
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html
index 72a957f..2e914dc 100644
--- a/resolving/passing-arguments-at-runtime/index.html
+++ b/resolving/passing-arguments-at-runtime/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Passing Arguments at Runtime
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Passing Arguments at Runtime
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Auto Resolving Concrete Types
-		        	Previous
Try Geting an Optional Service by Plugin Type and Name
-
-		        
-		      

-		      
-		      
-		      
-			      	Passing Arguments at Runtime
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Passing Arguments at Runtime
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Passing Arguments at Runtime
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Auto Resolving Concrete Types
+		        	Previous
Try Geting an Optional Service by Plugin Type and Name
+
+		        
+		      

+		      
+		      
+		      
+			      	Passing Arguments at Runtime
+			      
+			      	
+
+			      	
 			      		
 
 Most of the time you will be using StructureMap to build objects based on pre-canned configuration established upfront, but StructureMap
@@ -216,62 +216,62 @@ 
Using the ExplicitArguments object
                 .Service.ShouldBeTheSameAs(service);
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Try Geting an Optional Service by Plugin Type and Name
-
-				        
-				        
-
-				        	Next: Auto Resolving Concrete Types
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Try Geting an Optional Service by Plugin Type and Name
+
+				        
+				        
+
+				        	Next: Auto Resolving Concrete Types
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html
index a2fc5df..1076d68 100644
--- a/resolving/requesting-a-concrete-type/index.html
+++ b/resolving/requesting-a-concrete-type/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Auto Resolving Concrete Types
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Auto Resolving Concrete Types
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
The Container
-		        	Previous
Passing Arguments at Runtime
-
-		        
-		      

-		      
-		      
-		      
-			      	Auto Resolving Concrete Types
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Auto Resolving Concrete Types
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Auto Resolving Concrete Types
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
The Container
+		        	Previous
Passing Arguments at Runtime
+
+		        
+		      

+		      
+		      
+		      
+			      	Auto Resolving Concrete Types
+			      
+			      	
+
+			      	
 			      		
 
 StructureMap allows you to resolve instances of concrete classes without configuring that concrete type with a few provisos:
@@ -152,62 +152,62 @@ Auto Resolving Concrete Types
 In our example, where there isn't any configuration available, StructureMap looks at the constructor of the requested Weather type. It sees that it depends on four concrete types which all have a default constructor. StructureMap is therefore able to create an instance for all of them and inject them into the Weather constructor. After that the Weather instance is returned to the caller.
 Most of the time you will be mapping abstractions to concrete types, but as you have seen StructureMap supports other use cases as well.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Passing Arguments at Runtime
-
-				        
-				        
-
-				        	Next: The Container
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Passing Arguments at Runtime
+
+				        
+				        
+
+				        	Next: The Container
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
index 7fa1a13..e5da0ae 100644
--- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
+++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Try Geting an Optional Service by Plugin Type and Name
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Try Geting an Optional Service by Plugin Type and Name
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Passing Arguments at Runtime
-		        	Previous
Try Getting an Optional Service by Plugin Type
-
-		        
-		      

-		      
-		      
-		      
-			      	Try Geting an Optional Service by Plugin Type and Name
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Try Geting an Optional Service by Plugin Type and Name
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Try Geting an Optional Service by Plugin Type and Name
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Passing Arguments at Runtime
+		        	Previous
Try Getting an Optional Service by Plugin Type
+
+		        
+		      

+		      
+		      
+		      
+			      	Try Geting an Optional Service by Plugin Type and Name
+			      
+			      	
+
+			      	
 			      		
 
 Just use the IContainer.TryGetInstance<T>(name) or IContainer.TryGetInstance(Type pluginType, string name) method as shown below:
@@ -109,62 +109,62 @@ Try Geting an Optional Service by Plugin Type and Name
         }
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Try Getting an Optional Service by Plugin Type
-
-				        
-				        
-
-				        	Next: Passing Arguments at Runtime
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Try Getting an Optional Service by Plugin Type
+
+				        
+				        
+
+				        	Next: Passing Arguments at Runtime
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html
index 8f2adc4..effeec1 100644
--- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html
+++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Try Getting an Optional Service by Plugin Type
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Resolving Services
Try Getting an Optional Service by Plugin Type
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Try Geting an Optional Service by Plugin Type and Name
-		        	Previous
Get all Services by Plugin Type
-
-		        
-		      

-		      
-		      
-		      
-			      	Try Getting an Optional Service by Plugin Type
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Try Getting an Optional Service by Plugin Type
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Resolving Services
Try Getting an Optional Service by Plugin Type
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Try Geting an Optional Service by Plugin Type and Name
+		        	Previous
Get all Services by Plugin Type
+
+		        
+		      

+		      
+		      
+		      
+			      	Try Getting an Optional Service by Plugin Type
+			      
+			      	
+
+			      	
 			      		
 
 The StructureMap team does not recommend using "optional" dependencies as shown in this topic, but
@@ -213,62 +213,62 @@ Optional Generic Types
 
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Get all Services by Plugin Type
-
-				        
-				        
-
-				        	Next: Try Geting an Optional Service by Plugin Type and Name
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Get all Services by Plugin Type
+
+				        
+				        
+
+				        	Next: Try Geting an Optional Service by Plugin Type and Name
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/roadmap/index.html b/roadmap/index.html
index 462feef..add3ae1 100644
--- a/roadmap/index.html
+++ b/roadmap/index.html
@@ -1,168 +1,168 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Roadmap
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Roadmap
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
A Gentle Quickstart
-		        	Previous
Documentation
-
-		        
-		      

-		      
-		      
-		      
-			      	Roadmap
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Roadmap
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Roadmap
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
A Gentle Quickstart
+		        	Previous
Documentation
+
+		        
+		      

+		      
+		      
+		      
+			      	Roadmap
+			      
+			      	
+
+			      	
 			      		
 
 StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's.
 The ongoing work for version 4.0 is a much smaller release that primarily improves type scanning,
-diagnostics, and performance. The only breaking changes from 3 to 4 are in custom type scanning conventions.
+diagnostics, and performance. The only breaking changes from 3 to 4 are in custom type scanning conventions, the removal of ObjectFactory, and
+the elimination of some obscure configuration API's.
 Please log any suspected bugs or feature requests on StructureMap's GitHub page.
-After 4.0 is released, the StructureMap team will finally focus on the new DNX platform and officially support a StructureMap adapter for DNX.
 Ongoing and upcoming work
 
 The 4.0 work can be browsed from the GitHub issue list.
 A new package called StructureMap.DynamicInterception for adding support for AOP with Castle.Core dynamic proxies to StructureMap
-The StructureMap.DNX package for DNX integration (an early version is already available on Nuget.org)
-Sometime in 2016 StructureMap will support the CoreCLR
+The StructureMap.AutoFactory library is being rewritten based on Castle Dynamic Proxy to add more robust capabilities similar to what Windsor has
+The StructureMap.DNX package for DNX integration (an early version is already available on Nuget.org)
 
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Documentation
-
-				        
-				        
-
-				        	Next: A Gentle Quickstart
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Documentation
+
+				        
+				        
+
+				        	Next: A Gentle Quickstart
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html
index c124295..2718da8 100644
--- a/software-design-concepts/index.html
+++ b/software-design-concepts/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Software Design Concepts
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Software Design Concepts
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Setter Injection
-		        	Previous
Features
-
-		        
-		      

-		      
-		      
-		      
-			      	Software Design Concepts
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Software Design Concepts
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
Software Design Concepts
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Setter Injection
+		        	Previous
Features
+
+		        
+		      

+		      
+		      
+		      
+			      	Software Design Concepts
+			      
+			      	
+
+			      	
 			      		
 
 Inversion of Control
@@ -133,62 +133,62 @@ Service Locator
 
 Since IoC tools like StructureMap have come onto the software scene, many developers have very badly overused the service locator pattern and many other developers have become very vocal in their distaste for service location. The StructureMap team simply recommends that you favor Dependency Injection wherever possible, but that some service location in your system where you may need more advanced building options or lazy resolution of services is probably just fine.
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Features
-
-				        
-				        
-
-				        	Next: Setter Injection
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Features
+
+				        
+				        
+
+				        	Next: Setter Injection
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html
index 2e04428..9caf7e7 100644
--- a/the-container/auto-wiring/index.html
+++ b/the-container/auto-wiring/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Auto Wiring
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Auto Wiring
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Building Objects with Lambdas
-		        	Previous
The Container
-
-		        
-		      

-		      
-		      
-		      
-			      	Auto Wiring
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Auto Wiring
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Auto Wiring
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Building Objects with Lambdas
+		        	Previous
The Container
+
+		        
+		      

+		      
+		      
+		      
+			      	Auto Wiring
+			      
+			      	
+
+			      	
 			      		
 
 The best way to use an IoC container is to allow "Auto Wiring" to do most of the work for you.  IoC Containers like StructureMap are an infrastructure concern, and as such, should be isolated from as much of your code as possible.  Before examining Auto Wiring in depth, let's look at a common anti pattern of IoC usage:
@@ -162,62 +162,62 @@ Auto Wiring
 
 See Working with Primitive Types for more information on how StructureMap deals with primitive types like numbers, strings, enums, and dates in auto-wiring.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: The Container
-
-				        
-				        
-
-				        	Next: Building Objects with Lambdas
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: The Container
+
+				        
+				        
+
+				        	Next: Building Objects with Lambdas
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html
index f327dc0..43f74da 100644
--- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html
+++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Registering a Single Instance Against Multiple PluginType's
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Registering a Single Instance Against Multiple PluginType's
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Profiles and Child Containers
-		        	Previous
Working with the IContext at Build Time
-
-		        
-		      

-		      
-		      
-		      
-			      	Registering a Single Instance Against Multiple PluginType's
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Registering a Single Instance Against Multiple PluginType's
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Registering a Single Instance Against Multiple PluginType's
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Profiles and Child Containers
+		        	Previous
Working with the IContext at Build Time
+
+		        
+		      

+		      
+		      
+		      
+			      	Registering a Single Instance Against Multiple PluginType's
+			      
+			      	
+
+			      	
 			      		
 
 It's not uncommon to want a single instance registration in StructureMap to be mapped to multiple
@@ -151,62 +151,62 @@ 
Registering a Single Instance Against Multiple PluginType's
         }
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Working with the IContext at Build Time
-
-				        
-				        
-
-				        	Next: Profiles and Child Containers
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Working with the IContext at Build Time
+
+				        
+				        
+
+				        	Next: Profiles and Child Containers
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html
index de53ce7..cd55842 100644
--- a/the-container/handling-missing-named-instances/index.html
+++ b/the-container/handling-missing-named-instances/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Handling Missing Named Instances
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Handling Missing Named Instances
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Lazy Resolution
-		        	Previous
Working with Enumerable Types
-
-		        
-		      

-		      
-		      
-		      
-			      	Handling Missing Named Instances
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Handling Missing Named Instances
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Handling Missing Named Instances
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Lazy Resolution
+		        	Previous
Working with Enumerable Types
+
+		        
+		      

+		      
+		      
+		      
+			      	Handling Missing Named Instances
+			      
+			      	
+
+			      	
 			      		
 
 Let's say that something asks StructureMap to resolve a named instance of a type that StructureMap does not know about. What if instead
@@ -268,62 +268,62 @@ 
Multi-Tenancy
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Working with Enumerable Types
-
-				        
-				        
-
-				        	Next: Lazy Resolution
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Working with Enumerable Types
+
+				        
+				        
+
+				        	Next: Lazy Resolution
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/index.html b/the-container/index.html
index 80d4dcc..e7f449d 100644
--- a/the-container/index.html
+++ b/the-container/index.html
@@ -1,159 +1,159 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - The Container
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Auto Wiring
-		        	Previous
Resolving Services
-
-		        
-		      

-		      
-		      
-		      
-			      	The Container
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - The Container
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Auto Wiring
+		        	Previous
Resolving Services
+
+		        
+		      

+		      
+		      
+		      
+			      	The Container
+			      
+			      	
+
+			      	
 			      		
 
 The primary way to interact with StructureMap is through the IContainer interface and Container class. The following topics
 discuss some of the features and internal workings of the Container.
 Auto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Registering a Single Instance Against Multiple PluginType's
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Lazy Resolution
StructureMap and IDisposable
Working with Primitive Types
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Resolving Services
-
-				        
-				        
-
-				        	Next: Auto Wiring
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Resolving Services
+
+				        
+				        
+
+				        	Next: Auto Wiring
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html
index 29fa557..ba24c1d 100644
--- a/the-container/nested-containers/index.html
+++ b/the-container/nested-containers/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Nested Containers (Per Request/Transaction)
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Nested Containers (Per Request/Transaction)
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Working with Enumerable Types
-		        	Previous
Profiles and Child Containers
-
-		        
-		      

-		      
-		      
-		      
-			      	Nested Containers (Per Request/Transaction)
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Nested Containers (Per Request/Transaction)
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Nested Containers (Per Request/Transaction)
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Working with Enumerable Types
+		        	Previous
Profiles and Child Containers
+
+		        
+		      

+		      
+		      
+		      
+			      	Nested Containers (Per Request/Transaction)
+			      
+			      	
+
+			      	
 			      		
 
 Nested Containers are not interchangeable with Child Containers. See  for more information on child containers.
@@ -414,62 +414,62 @@ Disposing Services
 
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Profiles and Child Containers
-
-				        
-				        
-
-				        	Next: Working with Enumerable Types
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Profiles and Child Containers
+
+				        
+				        
+
+				        	Next: Working with Enumerable Types
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html
index 4f186ea..f5f01de 100644
--- a/the-container/profiles-and-child-containers/index.html
+++ b/the-container/profiles-and-child-containers/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Profiles and Child Containers
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Profiles and Child Containers
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Nested Containers (Per Request/Transaction)
-		        	Previous
Registering a Single Instance Against Multiple PluginType's
-
-		        
-		      

-		      
-		      
-		      
-			      	Profiles and Child Containers
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Profiles and Child Containers
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Profiles and Child Containers
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Nested Containers (Per Request/Transaction)
+		        	Previous
Registering a Single Instance Against Multiple PluginType's
+
+		        
+		      

+		      
+		      
+		      
+			      	Profiles and Child Containers
+			      
+			      	
+
+			      	
 			      		
 
 Child Containers are not interchangeable with Nested Containers. See  for more information on nested containers.
@@ -263,62 +263,62 @@ Example: Child Containers in Automated Testing
         }
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Registering a Single Instance Against Multiple PluginType's
-
-				        
-				        
-
-				        	Next: Nested Containers (Per Request/Transaction)
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Registering a Single Instance Against Multiple PluginType's
+
+				        
+				        
+
+				        	Next: Nested Containers (Per Request/Transaction)
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html
index b73307a..6363ff1 100644
--- a/the-container/working-with-enumerable-types/index.html
+++ b/the-container/working-with-enumerable-types/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Working with Enumerable Types
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Working with Enumerable Types
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Handling Missing Named Instances
-		        	Previous
Nested Containers (Per Request/Transaction)
-
-		        
-		      

-		      
-		      
-		      
-			      	Working with Enumerable Types
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Working with Enumerable Types
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Working with Enumerable Types
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Handling Missing Named Instances
+		        	Previous
Nested Containers (Per Request/Transaction)
+
+		        
+		      

+		      
+		      
+		      
+			      	Working with Enumerable Types
+			      
+			      	
+
+			      	
 			      		
 
 While you can certainly use any IEnumerable type as a plugin type with your own explicit configuration,
@@ -197,62 +197,62 @@ 
Sample Usage: Validation Rules
 just don't want to continuously break into the centralized Registry class every single time we add a new validation rule?
 By relying on StructureMap's IEnumerable behavior, we're able to split our IWidgetValidatior registration across multiple Registry classes and that's not infrequently useful to do.
 
-
-			      	
-
-			      	
-
-			      	
-				        
-				        	Previous: Nested Containers (Per Request/Transaction)
-
-				        
-				        
-
-				        	Next: Handling Missing Named Instances
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	
+
+			      	
+
+			      	
+				        
+				        	Previous: Nested Containers (Per Request/Transaction)
+
+				        
+				        
+
+				        	Next: Handling Missing Named Instances
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html
index 6863968..1b45e17 100644
--- a/the-container/working-with-the-icontext-at-build-time/index.html
+++ b/the-container/working-with-the-icontext-at-build-time/index.html
@@ -1,97 +1,97 @@
-
-
-    
-         
-        
-        
-        
-		StructureMap - Working with the IContext at Build Time
-		
-		
-		
-		
-        
-
-        
-        
-        
-
-
-        
-        
-    
-    
-    
-    
-    
-
-
-        
-        
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
-            
-              A Gentle Quickstart
-            
-		        
-		          Documentation
-		        
-            
-              Google Group
-            
-		        
-
-		        
-		      	Previous
-		      	Next
-		      
-      
-        
-          
-        
-      
-
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
The Container
Working with the IContext at Build Time
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.0.0
-		      	

-
-				
-
-		        
-
-		        	Next
Registering a Single Instance Against Multiple PluginType's
-		        	Previous
Building Objects with Lambdas
-
-		        
-		      

-		      
-		      
-		      
-			      	Working with the IContext at Build Time
-			      
-			      	
-
-			      	
+
+
+    
+         
+        
+        
+        
+		StructureMap - Working with the IContext at Build Time
+		
+		
+		
+		
+        
+
+        
+        
+        
+
+
+        
+        
+    
+    
+    
+    
+    
+
+
+        
+        
+		  
+		    
+		      StructureMap
+		    
+		    
+		      
+            
+              A Gentle Quickstart
+            
+		        
+		          Documentation
+		        
+            
+              Google Group
+            
+		        
+
+		        
+		      	Previous
+		      	Next
+		      
+      
+        
+          
+        
+      
+
+		    
+
+		  
+		
+
+		  
+		  	
+		  		StructureMap
The Container
Working with the IContext at Build Time
+		  	
+		  
+
+		
+		
+			
+		      
+		      
+		      
+		      	StructureMap 4.0.0
+		      	

+
+				
+
+		        
+
+		        	Next
Registering a Single Instance Against Multiple PluginType's
+		        	Previous
Building Objects with Lambdas
+
+		        
+		      

+		      
+		      
+		      
+			      	Working with the IContext at Build Time
+			      
+			      	
+
+			      	
 			      		
 
 The IContext usage shown in this topic is certainly not going away in future versions of StructureMap, but if at all possible, the StructureMap team
@@ -324,62 +324,62 @@ 
Example 2: NHibernate Integration

     }
 
 
-
-			      	

-
-			      	
-
-			      	
-				        
-				        	Previous: Building Objects with Lambdas
-
-				        
-				        
-
-				        	Next: Registering a Single Instance Against Multiple PluginType's
-
-				        
-			      	
-
-		      

-		  	

-		

-
-
-    
-
-
-    
-        
-        
-
-        
-        
-        
-        
-
-
-    
-
-
+
+			      	

+
+			      	
+
+			      	
+				        
+				        	Previous: Building Objects with Lambdas
+
+				        
+				        
+
+				        	Next: Registering a Single Instance Against Multiple PluginType's
+
+				        
+			      	
+
+		      

+		  	

+		

+
+
+    
+
+
+    
+        
+        
+
+        
+        
+        
+        
+
+
+    
+
+

From 9140639143f5514b5d4e1eae84733b15fe26c5c9 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Mon, 16 Nov 2015 15:56:35 -0600
Subject: [PATCH 34/55] Documentation Update

---
 instances/index.html     | 6 ++++++
 release-notes/index.html | 1 +
 2 files changed, 7 insertions(+)

diff --git a/instances/index.html b/instances/index.html
index 695cd66..499d533 100644
--- a/instances/index.html
+++ b/instances/index.html
@@ -115,6 +115,12 @@ Custom Instance Types
 If neither of these approaches will easily work for your custom Instance, you may want to contact the StructureMap team
 via the gitter link above and we can help walk you through a custom subclass of Instance -- or more likely, talk you out
 of it somehow.
+Missing Name Instance Template
+New to StructureMap 4.0 is the Instance.ToNamedClone(name) method that is used behind the scenes by the Handling Missing Named Instances feature.
+
+        public virtual Instance ToNamedClone(string name)
+
+Custom Instance types can override this method to provide a brand new Instance for a name. This functionality may be useful for multi-tenancy situations.
 
 
 			      	

diff --git a/release-notes/index.html b/release-notes/index.html
index cd0da00..cf20f9c 100644
--- a/release-notes/index.html
+++ b/release-notes/index.html
@@ -101,6 +101,7 @@ Release Nodes 4.0
 The highlights:
 
 We believe that the documentation is finally comprehensive in regards to StructureMap behavior and features
+StructureMap 4.0 is cross-compiled to .Net 4.0, .Net 4.0 as/ PCL, and as CoreCLR compliant (using the dotnet build profile).
 The type scanning model (Registry.Scan()) was completely rebuilt to make the model easier to extend and to
 optimize application bootstrapping in systems that heavily rely on StructureMap type scanning. See Auto-Registration and Conventions for more information.
 New diagnostic method specifically for troubleshooting type scanning problems. See Type Scanning Diagnostics for more information.

From 93c14d714890bde40978b66c1fc8b36dce9f4345 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Tue, 24 Nov 2015 15:25:17 -0600
Subject: [PATCH 35/55] Documentation Update

---
 registration/constructor-selection/index.html | 47 ++++++++++++++++++-
 release-notes/index.html                      |  2 +-
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html
index 4ec2ad3..0d94596 100644
--- a/registration/constructor-selection/index.html
+++ b/registration/constructor-selection/index.html
@@ -119,6 +119,11 @@ Greediest Constructor
                 Attribute = attribute;
                 Value = value;
             }
+
+            public GreaterThanRule(IWidget widget, Rule rule)
+            {
+                
+            }
         }
 
         [Test]
@@ -137,6 +142,46 @@ Greediest Constructor
         }
 
 
+New in StructureMap 4.0, the "greediest constructor selection" will bypass any constructor function that requires "simple" arguments
+like strings, numbers, or enumeration values that are not explicitly configured for the instance.
+You can see this behavior shown below:
+
+        public class DbContext
+        {
+            public string ConnectionString { get; set; }
+
+            public DbContext(string connectionString)
+            {
+                ConnectionString = connectionString;
+            }
+
+            public DbContext() : this("default value")
+            {
+                
+            }
+        }
+
+        [Test]
+        public void should_bypass_ctor_with_unresolvable_simple_args()
+        {
+            var container = new Container();
+            container.GetInstance<DbContext>()
+                .ConnectionString.ShouldBe("default value");
+        }
+
+        [Test]
+        public void should_use_greediest_ctor_that_has_all_of_simple_dependencies()
+        {
+            var container = new Container(_ =>
+            {
+                _.ForConcreteType<DbContext>().Configure
+                    .Ctor<string>("connectionString").Is("not the default");
+            });
+
+            container.GetInstance<DbContext>()
+                .ConnectionString.ShouldBe("not the default");
+        }
+
 Explicitly Selecting a Constructor
 To override the constructor selection explicitly on a case by case basis, you
 can use the SelectConstructor(Expression) method in the Registry DSL
@@ -263,7 +308,7 @@ 
Custom Constructor Selection Rule
 
     public class ThingCtorRule : IConstructorSelector
     {
-        public ConstructorInfo Find(Type pluggedType)
+        public ConstructorInfo Find(Type pluggedType, DependencyCollection dependencies, PluginGraph graph)
         {
             // if this rule does not apply to the pluggedType,
             // just return null to denote "not applicable"
diff --git a/release-notes/index.html b/release-notes/index.html
index cf20f9c..a7e1df9 100644
--- a/release-notes/index.html
+++ b/release-notes/index.html
@@ -95,7 +95,7 @@ Release Notes
 			      		
 
 StructureMap is attempting to follow a strict SemVer versioning policy.
-Release Nodes 4.0
+Release Notes 4.0
 4.0 is a medium sized release that largely builds on the existing 3.0 architecture with significant improvements to conventional
 registration via type scanning and several performance improvements as well as some bug fixes.
 The highlights:

From b6742f6487bf8424735bafc3397148a63ed09a67 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Mon, 4 Jan 2016 12:14:25 -0600
Subject: [PATCH 36/55] Documentation Update

---
 best-practices/index.html                                   | 6 ++----
 diagnostics/build-plans/index.html                          | 6 ++----
 diagnostics/environment-tests/index.html                    | 6 ++----
 diagnostics/index.html                                      | 6 ++----
 diagnostics/type-scanning/index.html                        | 6 ++----
 diagnostics/using-the-container-model/index.html            | 6 ++----
 diagnostics/validating-container-configuration/index.html   | 6 ++----
 diagnostics/whatdoihave/index.html                          | 6 ++----
 documentation/index.html                                    | 6 ++----
 features/index.html                                         | 6 ++----
 generics/index.html                                         | 6 ++----
 get-structuremap/index.html                                 | 6 ++----
 glossary/index.html                                         | 6 ++----
 history/index.html                                          | 6 ++----
 index.html                                                  | 6 +++++-
 instances/index.html                                        | 6 ++----
 integrations/index.html                                     | 6 ++----
 interception-and-decorators/index.html                      | 6 ++----
 interpreting-exceptions/index.html                          | 6 ++----
 object-lifecycle/configuring-lifecycles/index.html          | 6 ++----
 object-lifecycle/custom-lifecycles/index.html               | 6 ++----
 object-lifecycle/index.html                                 | 6 ++----
 object-lifecycle/supported-lifecycles/index.html            | 6 ++----
 quickstart/index.html                                       | 6 ++----
 registration/attributes/index.html                          | 6 ++----
 registration/auto-registration-and-conventions/index.html   | 6 ++----
 registration/changing-configuration-at-runtime/index.html   | 6 ++----
 registration/clear-or-replace/index.html                    | 6 ++----
 registration/configured-instance/index.html                 | 6 ++----
 registration/constructor-selection/index.html               | 6 ++----
 registration/existing-objects/index.html                    | 6 ++----
 registration/fallback-services/index.html                   | 6 ++----
 registration/index.html                                     | 6 ++----
 registration/inline-dependencies/index.html                 | 6 ++----
 registration/on-missing-family-policies/index.html          | 6 ++----
 registration/policies/index.html                            | 6 ++----
 registration/registry-dsl/index.html                        | 6 ++----
 release-notes/index.html                                    | 6 ++----
 resolving/get-a-service-by-plugin-type-and-name/index.html  | 6 ++----
 resolving/get-a-service-by-plugintype/index.html            | 6 ++----
 resolving/get-all-services-by-plugin-type/index.html        | 6 ++----
 resolving/index.html                                        | 6 ++----
 resolving/passing-arguments-at-runtime/index.html           | 6 ++----
 resolving/requesting-a-concrete-type/index.html             | 6 ++----
 .../index.html                                              | 6 ++----
 .../index.html                                              | 6 ++----
 roadmap/index.html                                          | 6 ++----
 setter-injection/index.html                                 | 6 ++----
 software-design-concepts/index.html                         | 6 ++----
 the-container/auto-wiring/index.html                        | 6 ++----
 the-container/disposing/index.html                          | 6 ++----
 .../index.html                                              | 6 ++----
 the-container/handling-missing-named-instances/index.html   | 6 ++----
 the-container/index.html                                    | 6 ++----
 the-container/lambdas/index.html                            | 6 ++----
 the-container/lazy-resolution/index.html                    | 6 ++----
 the-container/nested-containers/index.html                  | 6 ++----
 the-container/primitives/index.html                         | 6 ++----
 the-container/profiles-and-child-containers/index.html      | 6 ++----
 the-container/working-with-enumerable-types/index.html      | 6 ++----
 .../working-with-the-icontext-at-build-time/index.html      | 6 ++----
 61 files changed, 125 insertions(+), 241 deletions(-)

diff --git a/best-practices/index.html b/best-practices/index.html
index 93b606d..3a92516 100644
--- a/best-practices/index.html
+++ b/best-practices/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
History
 		        	Previous
Diagnostics
 
@@ -87,7 +85,7 @@ Previous
Diagnostics
 		      
 		      
 		      
-			      	Best Practices
+			      	Best Practices  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html
index de0d84b..6e511d4 100644
--- a/diagnostics/build-plans/index.html
+++ b/diagnostics/build-plans/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Using the Container Model
 		        	Previous
Environment Tests
 
@@ -87,7 +85,7 @@ Previous
Envi
 		      
 		      
 		      
-			      	Build Plans
+			      	Build Plans  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html
index 208c4df..c1ae778 100644
--- a/diagnostics/environment-tests/index.html
+++ b/diagnostics/environment-tests/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Build Plans
 		        	Previous
Validating Container Configuration
 
@@ -87,7 +85,7 @@ Previous

-			      	Environment Tests
+			      	Environment Tests  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/index.html b/diagnostics/index.html
index be38dc8..e3d808b 100644
--- a/diagnostics/index.html
+++ b/diagnostics/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
WhatDoIHave()
 		        	Previous
Interpreting Exceptions
 
@@ -87,7 +85,7 @@ Previous
Interpreti
 		      
 		      
 		      
-			      	Diagnostics
+			      	Diagnostics  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html
index 32e8008..4743bb9 100644
--- a/diagnostics/type-scanning/index.html
+++ b/diagnostics/type-scanning/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Best Practices
 		        	Previous
Using the Container Model
 
@@ -87,7 +85,7 @@ Previous

-			      	Type Scanning Diagnostics
+			      	Type Scanning Diagnostics  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html
index ff4d0b3..4e63b5a 100644
--- a/diagnostics/using-the-container-model/index.html
+++ b/diagnostics/using-the-container-model/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Type Scanning Diagnostics
 		        	Previous
Build Plans
 
@@ -87,7 +85,7 @@ Previous
Build Plan
 		      
 		      
 		      
-			      	Using the Container Model
+			      	Using the Container Model  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html
index c51fa91..195891b 100644
--- a/diagnostics/validating-container-configuration/index.html
+++ b/diagnostics/validating-container-configuration/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Environment Tests
 		        	Previous
WhatDoIHave()
 
@@ -87,7 +85,7 @@ Previous
WhatDoIHav
 		      
 		      
 		      
-			      	Validating Container Configuration
+			      	Validating Container Configuration  Edit on GitHub
 			      
 			      	
 
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html
index 81ac269..35d4b10 100644
--- a/diagnostics/whatdoihave/index.html
+++ b/diagnostics/whatdoihave/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Validating Container Configuration
 		        	Previous
Diagnostics
 
@@ -87,7 +85,7 @@ Previous
Diagnostics
 		      
 		      
 		      
-			      	WhatDoIHave()
+			      	WhatDoIHave()  Edit on GitHub
 			      
 			      	
 
diff --git a/documentation/index.html b/documentation/index.html
index 046b28a..33a9dfb 100644
--- a/documentation/index.html
+++ b/documentation/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Roadmap
 		        	Previous
StructureMap
 
@@ -87,7 +85,7 @@ Previous
StructureMap
 		      
 		      
 		      
-			      	Documentation
+			      	Documentation  Edit on GitHub
 			      
 			      	
 
diff --git a/features/index.html b/features/index.html
index be743de..da3c45a 100644
--- a/features/index.html
+++ b/features/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Software Design Concepts
 		        	Previous
Get StructureMap
 
@@ -87,7 +85,7 @@ Previous
Get StructureMap<
 		      
 		      
 		      
-			      	Features
+			      	Features  Edit on GitHub
 			      
 			      	
 
diff --git a/generics/index.html b/generics/index.html
index b126a6b..c81c83a 100644
--- a/generics/index.html
+++ b/generics/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Interception and Decorators
 		        	Previous
Object Lifecycles
 
@@ -87,7 +85,7 @@ Previous
Object Lifecycles
 		      
 		      
 		      
-			      	Generic Types
+			      	Generic Types  Edit on GitHub
 			      
 			      	
 
diff --git a/get-structuremap/index.html b/get-structuremap/index.html
index 3683043..94e6f74 100644
--- a/get-structuremap/index.html
+++ b/get-structuremap/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Features
 		        	Previous
Glossary
 
@@ -87,7 +85,7 @@ Previous
Glossary
 		      
 		      
 		      
-			      	Get StructureMap
+			      	Get StructureMap  Edit on GitHub
 			      
 			      	
 
diff --git a/glossary/index.html b/glossary/index.html
index 28bac17..13155d0 100644
--- a/glossary/index.html
+++ b/glossary/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Get StructureMap
 		        	Previous
A Gentle Quickstart
 
@@ -87,7 +85,7 @@ Previous
A Gentle Quickstart
 		      
 		      
 		      
-			      	Glossary
+			      	Glossary  Edit on GitHub
 			      
 			      	
 
diff --git a/history/index.html b/history/index.html
index 4c236df..dc86135 100644
--- a/history/index.html
+++ b/history/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Release Notes
 		        	Previous
Best Practices
 
@@ -87,7 +85,7 @@ Previous
Best Practices<
 		      
 		      
 		      
-			      	History
+			      	History  Edit on GitHub
 			      
 			      	
 
diff --git a/index.html b/index.html
index 5ce9c5a..e7e693c 100644
--- a/index.html
+++ b/index.html
@@ -9,6 +9,7 @@
         
 		StructureMap
 		
+    
     
     
 
@@ -34,6 +35,9 @@
 		        
 
 		        
+            
+               Edit on GitHub
+            
 		      
       
         
@@ -51,7 +55,7 @@
         StructureMap
         
 StructureMap is the oldest, continuously used IoC/DI container for .Net dating back to its first public release and production usage all the way back in June 2004 on .Net 1.1.  
-The current 3.* release represents 10+ years of lessons learned in the StructureMap and greater .Net community -- while also wiping away a great deal of legacy design
+The current 4.* release represents 12+ years of lessons learned in the StructureMap and greater .Net community -- while also wiping away a great deal of legacy design
 decisions that no longer make sense today.
         
         Learn more »
diff --git a/instances/index.html b/instances/index.html
index 499d533..dd7d334 100644
--- a/instances/index.html
+++ b/instances/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Integrating StructureMap into Common .Net Frameworks
 		        	Previous
Release Notes
 
@@ -87,7 +85,7 @@ Previous
Release Notes
 		      
-			      	Custom Instance Types
+			      	Custom Instance Types  Edit on GitHub
 			      
 			      	
 
diff --git a/integrations/index.html b/integrations/index.html
index d49f35b..c2e6d68 100644
--- a/integrations/index.html
+++ b/integrations/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	
 		        	Previous
Custom Instance Types
 
@@ -87,7 +85,7 @@ Previous
Custom Instance Types
 		      
-			      	Integrating StructureMap into Common .Net Frameworks
+			      	Integrating StructureMap into Common .Net Frameworks  Edit on GitHub
 			      
 			      	
 
diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html
index cb5dce8..0bda22f 100644
--- a/interception-and-decorators/index.html
+++ b/interception-and-decorators/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Interpreting Exceptions
 		        	Previous
Generic Types
 
@@ -87,7 +85,7 @@ Previous
Generic Types
 		      
 		      
 		      
-			      	Interception and Decorators
+			      	Interception and Decorators  Edit on GitHub
 			      
 			      	
 
diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html
index 87ea3fb..921f38b 100644
--- a/interpreting-exceptions/index.html
+++ b/interpreting-exceptions/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Diagnostics
 		        	Previous
Interception and Decorators
 
@@ -87,7 +85,7 @@ Previous
Interc
 		      
 		      
 		      
-			      	Interpreting Exceptions
+			      	Interpreting Exceptions  Edit on GitHub
 			      
 			      	
 
diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html
index 2d39828..3729b2b 100644
--- a/object-lifecycle/configuring-lifecycles/index.html
+++ b/object-lifecycle/configuring-lifecycles/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Custom Lifecycles
 		        	Previous
Supported Lifecycles
 
@@ -87,7 +85,7 @@ Previous

-			      	Configuring Lifecycles
+			      	Configuring Lifecycles  Edit on GitHub
 			      
 			      	
 
diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html
index 3c294c2..75eaa1f 100644
--- a/object-lifecycle/custom-lifecycles/index.html
+++ b/object-lifecycle/custom-lifecycles/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Generic Types
 		        	Previous
Configuring Lifecycles
 
@@ -87,7 +85,7 @@ Previous

-			      	Custom Lifecycles
+			      	Custom Lifecycles  Edit on GitHub
 			      
 			      	
 
diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html
index 327720a..6922097 100644
--- a/object-lifecycle/index.html
+++ b/object-lifecycle/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Supported Lifecycles
 		        	Previous
The Container
 
@@ -87,7 +85,7 @@ Previous
The Container
 		      
-			      	Object Lifecycles
+			      	Object Lifecycles  Edit on GitHub
 			      
 			      	
 
diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html
index 66af742..d58c503 100644
--- a/object-lifecycle/supported-lifecycles/index.html
+++ b/object-lifecycle/supported-lifecycles/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Configuring Lifecycles
 		        	Previous
Object Lifecycles
 
@@ -87,7 +85,7 @@ Previous
Object Lifecycles
 		      
 		      
 		      
-			      	Supported Lifecycles
+			      	Supported Lifecycles  Edit on GitHub
 			      
 			      	
 
diff --git a/quickstart/index.html b/quickstart/index.html
index ac94195..9f2c0bb 100644
--- a/quickstart/index.html
+++ b/quickstart/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Glossary
 		        	Previous
Roadmap
 
@@ -87,7 +85,7 @@ Previous
Roadmap
 		      
 		      
 		      
-			      	A Gentle Quickstart
+			      	A Gentle Quickstart  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/attributes/index.html b/registration/attributes/index.html
index a2da07d..1d77f74 100644
--- a/registration/attributes/index.html
+++ b/registration/attributes/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Resolving Services
 		        	Previous
Replace or Clear Out Previous Registrations
 
@@ -87,7 +85,7 @@ Previous
Repl
 		      
 		      
 		      
-			      	Using Attributes for Configuration
+			      	Using Attributes for Configuration  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html
index 2dda3c4..ce1c661 100644
--- a/registration/auto-registration-and-conventions/index.html
+++ b/registration/auto-registration-and-conventions/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Working with IConfiguredInstance
 		        	Previous
Inline Dependencies
 
@@ -87,7 +85,7 @@ Previous
I
 		      
 		      
 		      
-			      	Auto-Registration and Conventions
+			      	Auto-Registration and Conventions  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html
index fa981a1..d5773fe 100644
--- a/registration/changing-configuration-at-runtime/index.html
+++ b/registration/changing-configuration-at-runtime/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
On Missing Family Policies
 		        	Previous
Construction Policies
 
@@ -87,7 +85,7 @@ Previous
Construction
 		      
 		      
 		      
-			      	Changing Configuration at Runtime
+			      	Changing Configuration at Runtime  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html
index ce0ca04..3200d8a 100644
--- a/registration/clear-or-replace/index.html
+++ b/registration/clear-or-replace/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Using Attributes for Configuration
 		        	Previous
Registering Existing Objects
 
@@ -87,7 +85,7 @@ Previous
Regi
 		      
 		      
 		      
-			      	Replace or Clear Out Previous Registrations
+			      	Replace or Clear Out Previous Registrations  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html
index 8271646..5001ace 100644
--- a/registration/configured-instance/index.html
+++ b/registration/configured-instance/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Construction Policies
 		        	Previous
Auto-Registration and Conventions
 
@@ -87,7 +85,7 @@ Previous

-			      	Working with IConfiguredInstance
+			      	Working with IConfiguredInstance  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html
index 0d94596..142d677 100644
--- a/registration/constructor-selection/index.html
+++ b/registration/constructor-selection/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Fallback Services
 		        	Previous
On Missing Family Policies
 
@@ -87,7 +85,7 @@ Previous

-			      	Constructor Selection
+			      	Constructor Selection  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html
index 6672581..e1699aa 100644
--- a/registration/existing-objects/index.html
+++ b/registration/existing-objects/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Replace or Clear Out Previous Registrations
 		        	Previous
Fallback Services
 
@@ -87,7 +85,7 @@ Previous
Fal
 		      
 		      
 		      
-			      	Registering Existing Objects
+			      	Registering Existing Objects  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html
index 7d85371..908722c 100644
--- a/registration/fallback-services/index.html
+++ b/registration/fallback-services/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Registering Existing Objects
 		        	Previous
Constructor Selection
 
@@ -87,7 +85,7 @@ Previous

 		      
-			      	Fallback Services
+			      	Fallback Services  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/index.html b/registration/index.html
index cdfc503..27f7f1c 100644
--- a/registration/index.html
+++ b/registration/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Registry DSL
 		        	Previous
Setter Injection
 
@@ -87,7 +85,7 @@ Previous
Setter Injection<
 		      
 		      
 		      
-			      	Registration
+			      	Registration  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html
index aef0ab1..b3a6962 100644
--- a/registration/inline-dependencies/index.html
+++ b/registration/inline-dependencies/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Auto-Registration and Conventions
 		        	Previous
Registry DSL
 
@@ -87,7 +85,7 @@ Previous
Registry
 		      
 		      
 		      
-			      	Inline Dependencies
+			      	Inline Dependencies  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html
index 474cc64..8edc88c 100644
--- a/registration/on-missing-family-policies/index.html
+++ b/registration/on-missing-family-policies/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Constructor Selection
 		        	Previous
Changing Configuration at Runtime
 
@@ -87,7 +85,7 @@ Previous

-			      	On Missing Family Policies
+			      	On Missing Family Policies  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/policies/index.html b/registration/policies/index.html
index e9c053c..13bf3cc 100644
--- a/registration/policies/index.html
+++ b/registration/policies/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Changing Configuration at Runtime
 		        	Previous
Working with IConfiguredInstance
 
@@ -87,7 +85,7 @@ Previous
W
 		      
 		      
 		      
-			      	Construction Policies
+			      	Construction Policies  Edit on GitHub
 			      
 			      	
 
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html
index 8059784..c984862 100644
--- a/registration/registry-dsl/index.html
+++ b/registration/registry-dsl/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Inline Dependencies
 		        	Previous
Registration
 
@@ -87,7 +85,7 @@ Previous
Registration
 		      
 		      
 		      
-			      	Registry DSL
+			      	Registry DSL  Edit on GitHub
 			      
 			      	
 
diff --git a/release-notes/index.html b/release-notes/index.html
index a7e1df9..1635aad 100644
--- a/release-notes/index.html
+++ b/release-notes/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Custom Instance Types
 		        	Previous
History
 
@@ -87,7 +85,7 @@ Previous
History
 		      
 		      
 		      
-			      	Release Notes
+			      	Release Notes  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html
index 54e190a..3111109 100644
--- a/resolving/get-a-service-by-plugin-type-and-name/index.html
+++ b/resolving/get-a-service-by-plugin-type-and-name/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Get all Services by Plugin Type
 		        	Previous
Get a Service by PluginType
 
@@ -87,7 +85,7 @@ Previous

-			      	Get a Service by Plugin Type and Name
+			      	Get a Service by Plugin Type and Name  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html
index 1734273..0268c23 100644
--- a/resolving/get-a-service-by-plugintype/index.html
+++ b/resolving/get-a-service-by-plugintype/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Get a Service by Plugin Type and Name
 		        	Previous
Resolving Services
 
@@ -87,7 +85,7 @@ Previous
Resolving Services
 		      
-			      	Get a Service by PluginType
+			      	Get a Service by PluginType  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html
index eececf2..6392b26 100644
--- a/resolving/get-all-services-by-plugin-type/index.html
+++ b/resolving/get-all-services-by-plugin-type/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Try Getting an Optional Service by Plugin Type
 		        	Previous
Get a Service by Plugin Type and Name
 
@@ -87,7 +85,7 @@ Previous

-			      	Get all Services by Plugin Type
+			      	Get all Services by Plugin Type  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/index.html b/resolving/index.html
index 5cb720f..b9d5ed6 100644
--- a/resolving/index.html
+++ b/resolving/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Get a Service by PluginType
 		        	Previous
Registration
 
@@ -87,7 +85,7 @@ Previous
Registration
 		      
 		      
 		      
-			      	Resolving Services
+			      	Resolving Services  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html
index 2e914dc..57a9756 100644
--- a/resolving/passing-arguments-at-runtime/index.html
+++ b/resolving/passing-arguments-at-runtime/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Auto Resolving Concrete Types
 		        	Previous
Try Geting an Optional Service by Plugin Type and Name
 
@@ -87,7 +85,7 @@ Previous

-			      	Passing Arguments at Runtime
+			      	Passing Arguments at Runtime  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html
index 1076d68..ed74965 100644
--- a/resolving/requesting-a-concrete-type/index.html
+++ b/resolving/requesting-a-concrete-type/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
The Container
 		        	Previous
Passing Arguments at Runtime
 
@@ -87,7 +85,7 @@ Previous

-			      	Auto Resolving Concrete Types
+			      	Auto Resolving Concrete Types  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
index e5da0ae..805feea 100644
--- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
+++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Passing Arguments at Runtime
 		        	Previous
Try Getting an Optional Service by Plugin Type
 
@@ -87,7 +85,7 @@ Previous

-			      	Try Geting an Optional Service by Plugin Type and Name
+			      	Try Geting an Optional Service by Plugin Type and Name  Edit on GitHub
 			      
 			      	
 
diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html
index effeec1..ea31dcb 100644
--- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html
+++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Try Geting an Optional Service by Plugin Type and Name
 		        	Previous
Get all Services by Plugin Type
 
@@ -87,7 +85,7 @@ Previous

-			      	Try Getting an Optional Service by Plugin Type
+			      	Try Getting an Optional Service by Plugin Type  Edit on GitHub
 			      
 			      	
 
diff --git a/roadmap/index.html b/roadmap/index.html
index add3ae1..1b8904b 100644
--- a/roadmap/index.html
+++ b/roadmap/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
A Gentle Quickstart
 		        	Previous
Documentation
 
@@ -87,7 +85,7 @@ Previous
Documentation
 		      
-			      	Roadmap
+			      	Roadmap  Edit on GitHub
 			      
 			      	
 
diff --git a/setter-injection/index.html b/setter-injection/index.html
index 4abf994..375a3c3 100644
--- a/setter-injection/index.html
+++ b/setter-injection/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Registration
 		        	Previous
Software Design Concepts
 
@@ -87,7 +85,7 @@ Previous
Software
 		      
 		      
 		      
-			      	Setter Injection
+			      	Setter Injection  Edit on GitHub
 			      
 			      	
 
diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html
index 2718da8..42a6445 100644
--- a/software-design-concepts/index.html
+++ b/software-design-concepts/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Setter Injection
 		        	Previous
Features
 
@@ -87,7 +85,7 @@ Previous
Features
 		      
 		      
 		      
-			      	Software Design Concepts
+			      	Software Design Concepts  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html
index 9caf7e7..c8016ab 100644
--- a/the-container/auto-wiring/index.html
+++ b/the-container/auto-wiring/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Building Objects with Lambdas
 		        	Previous
The Container
 
@@ -87,7 +85,7 @@ Previous
The Container
 		      
-			      	Auto Wiring
+			      	Auto Wiring  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html
index 3c06800..2f2b707 100644
--- a/the-container/disposing/index.html
+++ b/the-container/disposing/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Working with Primitive Types
 		        	Previous
Lazy Resolution
 
@@ -87,7 +85,7 @@ Previous
Lazy
 		      
 		      
 		      
-			      	StructureMap and IDisposable
+			      	StructureMap and IDisposable  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html
index 43f74da..42eb167 100644
--- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html
+++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Profiles and Child Containers
 		        	Previous
Working with the IContext at Build Time
 
@@ -87,7 +85,7 @@ Previous

-			      	Registering a Single Instance Against Multiple PluginType's
+			      	Registering a Single Instance Against Multiple PluginType's  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html
index cd55842..41e617e 100644
--- a/the-container/handling-missing-named-instances/index.html
+++ b/the-container/handling-missing-named-instances/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Lazy Resolution
 		        	Previous
Working with Enumerable Types
 
@@ -87,7 +85,7 @@ Previous

-			      	Handling Missing Named Instances
+			      	Handling Missing Named Instances  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/index.html b/the-container/index.html
index e7f449d..33d01a8 100644
--- a/the-container/index.html
+++ b/the-container/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Auto Wiring
 		        	Previous
Resolving Services
 
@@ -87,7 +85,7 @@ Previous
Resolving Services
 		      
-			      	The Container
+			      	The Container  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html
index e781a43..fa93bf1 100644
--- a/the-container/lambdas/index.html
+++ b/the-container/lambdas/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Working with the IContext at Build Time
 		        	Previous
Auto Wiring
 
@@ -87,7 +85,7 @@ Previous
Auto Wir
 		      
 		      
 		      
-			      	Building Objects with Lambdas
+			      	Building Objects with Lambdas  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html
index cac6fb3..54920ea 100644
--- a/the-container/lazy-resolution/index.html
+++ b/the-container/lazy-resolution/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
StructureMap and IDisposable
 		        	Previous
Handling Missing Named Instances
 
@@ -87,7 +85,7 @@ Previous

-			      	Lazy Resolution
+			      	Lazy Resolution  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html
index ba24c1d..33c8df7 100644
--- a/the-container/nested-containers/index.html
+++ b/the-container/nested-containers/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Working with Enumerable Types
 		        	Previous
Profiles and Child Containers
 
@@ -87,7 +85,7 @@ Previous

-			      	Nested Containers (Per Request/Transaction)
+			      	Nested Containers (Per Request/Transaction)  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html
index b4a0dea..c383e5b 100644
--- a/the-container/primitives/index.html
+++ b/the-container/primitives/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Object Lifecycles
 		        	Previous
StructureMap and IDisposable
 
@@ -87,7 +85,7 @@ Previous
StructureM
 		      
 		      
 		      
-			      	Working with Primitive Types
+			      	Working with Primitive Types  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html
index f5f01de..e5fd562 100644
--- a/the-container/profiles-and-child-containers/index.html
+++ b/the-container/profiles-and-child-containers/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Nested Containers (Per Request/Transaction)
 		        	Previous
Registering a Single Instance Against Multiple PluginType's
 
@@ -87,7 +85,7 @@ Previous

-			      	Profiles and Child Containers
+			      	Profiles and Child Containers  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html
index 6363ff1..5abd419 100644
--- a/the-container/working-with-enumerable-types/index.html
+++ b/the-container/working-with-enumerable-types/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Handling Missing Named Instances
 		        	Previous
Nested Containers (Per Request/Transaction)
 
@@ -87,7 +85,7 @@ Previous
Ne
 		      
 		      
 		      
-			      	Working with Enumerable Types
+			      	Working with Enumerable Types  Edit on GitHub
 			      
 			      	
 
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html
index 1b45e17..9b6e49c 100644
--- a/the-container/working-with-the-icontext-at-build-time/index.html
+++ b/the-container/working-with-the-icontext-at-build-time/index.html
@@ -9,9 +9,8 @@
 		
 		
 		
-		
-        
 
+		
         
         
         
@@ -78,7 +77,6 @@ StructureMap 4.0.0
 				
 
 		        
-
 		        	Next
Registering a Single Instance Against Multiple PluginType's
 		        	Previous
Building Objects with Lambdas
 
@@ -87,7 +85,7 @@ Previous
Building Obj
 		      
 		      
 		      
-			      	Working with the IContext at Build Time
+			      	Working with the IContext at Build Time  Edit on GitHub
 			      
 			      	
 

From fa10130f6363f8ff961d33b991fe7ee788929274 Mon Sep 17 00:00:00 2001
From: jeremydmiller 
Date: Wed, 2 Mar 2016 11:19:21 -0600
Subject: [PATCH 37/55] Documentation Update

---
 best-practices/index.html                     |  2 +-
 diagnostics/build-plans/index.html            |  2 +-
 diagnostics/environment-tests/index.html      |  2 +-
 diagnostics/index.html                        |  2 +-
 diagnostics/type-scanning/index.html          |  2 +-
 .../using-the-container-model/index.html      |  2 +-
 .../index.html                                |  2 +-
 diagnostics/whatdoihave/index.html            |  2 +-
 documentation/index.html                      |  2 +-
 features/index.html                           |  2 +-
 generics/index.html                           |  2 +-
 get-structuremap/index.html                   |  2 +-
 glossary/index.html                           |  2 +-
 history/index.html                            |  2 +-
 instances/index.html                          |  2 +-
 integrations/index.html                       |  2 +-
 interception-and-decorators/index.html        |  2 +-
 interpreting-exceptions/index.html            |  2 +-
 .../configuring-lifecycles/index.html         |  2 +-
 object-lifecycle/custom-lifecycles/index.html |  2 +-
 object-lifecycle/index.html                   |  2 +-
 .../supported-lifecycles/index.html           |  2 +-
 quickstart/index.html                         |  2 +-
 registration/attributes/index.html            |  2 +-
 .../index.html                                | 27 ++++++++++++++++++-
 .../index.html                                |  2 +-
 registration/clear-or-replace/index.html      |  2 +-
 registration/configured-instance/index.html   |  2 +-
 registration/constructor-selection/index.html |  2 +-
 registration/existing-objects/index.html      |  2 +-
 registration/fallback-services/index.html     |  2 +-
 registration/index.html                       |  2 +-
 registration/inline-dependencies/index.html   |  2 +-
 .../on-missing-family-policies/index.html     |  2 +-
 registration/policies/index.html              |  2 +-
 registration/registry-dsl/index.html          |  2 +-
 release-notes/index.html                      |  7 ++++-
 .../index.html                                |  2 +-
 .../get-a-service-by-plugintype/index.html    |  2 +-
 .../index.html                                |  2 +-
 resolving/index.html                          |  2 +-
 .../passing-arguments-at-runtime/index.html   |  2 +-
 .../requesting-a-concrete-type/index.html     |  2 +-
 .../index.html                                |  2 +-
 .../index.html                                |  2 +-
 roadmap/index.html                            |  9 +++----
 setter-injection/index.html                   |  2 +-
 software-design-concepts/index.html           |  2 +-
 the-container/auto-wiring/index.html          |  2 +-
 the-container/disposing/index.html            |  2 +-
 .../index.html                                |  2 +-
 .../index.html                                |  2 +-
 the-container/index.html                      |  2 +-
 the-container/lambdas/index.html              |  2 +-
 the-container/lazy-resolution/index.html      |  2 +-
 the-container/nested-containers/index.html    |  2 +-
 the-container/primitives/index.html           |  2 +-
 .../profiles-and-child-containers/index.html  |  2 +-
 .../working-with-enumerable-types/index.html  |  2 +-
 .../index.html                                |  2 +-
 60 files changed, 93 insertions(+), 64 deletions(-)

diff --git a/best-practices/index.html b/best-practices/index.html
index 3a92516..a2f1c7d 100644
--- a/best-practices/index.html
+++ b/best-practices/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html
index 6e511d4..b7648e9 100644
--- a/diagnostics/build-plans/index.html
+++ b/diagnostics/build-plans/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/environment-tests/index.html b/diagnostics/environment-tests/index.html
index c1ae778..99315d3 100644
--- a/diagnostics/environment-tests/index.html
+++ b/diagnostics/environment-tests/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/index.html b/diagnostics/index.html
index e3d808b..5af162d 100644
--- a/diagnostics/index.html
+++ b/diagnostics/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/type-scanning/index.html b/diagnostics/type-scanning/index.html
index 4743bb9..a9afac8 100644
--- a/diagnostics/type-scanning/index.html
+++ b/diagnostics/type-scanning/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html
index 4e63b5a..2703607 100644
--- a/diagnostics/using-the-container-model/index.html
+++ b/diagnostics/using-the-container-model/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html
index 195891b..dffcb01 100644
--- a/diagnostics/validating-container-configuration/index.html
+++ b/diagnostics/validating-container-configuration/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html
index 35d4b10..9a02c00 100644
--- a/diagnostics/whatdoihave/index.html
+++ b/diagnostics/whatdoihave/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/documentation/index.html b/documentation/index.html
index 33a9dfb..d8b47f9 100644
--- a/documentation/index.html
+++ b/documentation/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/features/index.html b/features/index.html
index da3c45a..fad1ad6 100644
--- a/features/index.html
+++ b/features/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/generics/index.html b/generics/index.html
index c81c83a..f267fe4 100644
--- a/generics/index.html
+++ b/generics/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/get-structuremap/index.html b/get-structuremap/index.html
index 94e6f74..d7366c2 100644
--- a/get-structuremap/index.html
+++ b/get-structuremap/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/glossary/index.html b/glossary/index.html
index 13155d0..87588b4 100644
--- a/glossary/index.html
+++ b/glossary/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/history/index.html b/history/index.html
index dc86135..2a53d7b 100644
--- a/history/index.html
+++ b/history/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/instances/index.html b/instances/index.html
index dd7d334..788b025 100644
--- a/instances/index.html
+++ b/instances/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/integrations/index.html b/integrations/index.html
index c2e6d68..30e4828 100644
--- a/integrations/index.html
+++ b/integrations/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/interception-and-decorators/index.html b/interception-and-decorators/index.html
index 0bda22f..f4dce2a 100644
--- a/interception-and-decorators/index.html
+++ b/interception-and-decorators/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/interpreting-exceptions/index.html b/interpreting-exceptions/index.html
index 921f38b..3c9d8ee 100644
--- a/interpreting-exceptions/index.html
+++ b/interpreting-exceptions/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/object-lifecycle/configuring-lifecycles/index.html b/object-lifecycle/configuring-lifecycles/index.html
index 3729b2b..aaf4276 100644
--- a/object-lifecycle/configuring-lifecycles/index.html
+++ b/object-lifecycle/configuring-lifecycles/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/object-lifecycle/custom-lifecycles/index.html b/object-lifecycle/custom-lifecycles/index.html
index 75eaa1f..2f7e34a 100644
--- a/object-lifecycle/custom-lifecycles/index.html
+++ b/object-lifecycle/custom-lifecycles/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/object-lifecycle/index.html b/object-lifecycle/index.html
index 6922097..26fa10b 100644
--- a/object-lifecycle/index.html
+++ b/object-lifecycle/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/object-lifecycle/supported-lifecycles/index.html b/object-lifecycle/supported-lifecycles/index.html
index d58c503..a73d06e 100644
--- a/object-lifecycle/supported-lifecycles/index.html
+++ b/object-lifecycle/supported-lifecycles/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/quickstart/index.html b/quickstart/index.html
index 9f2c0bb..b75d740 100644
--- a/quickstart/index.html
+++ b/quickstart/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/attributes/index.html b/registration/attributes/index.html
index 1d77f74..7b95c09 100644
--- a/registration/attributes/index.html
+++ b/registration/attributes/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/auto-registration-and-conventions/index.html b/registration/auto-registration-and-conventions/index.html
index ce1c661..5f3251e 100644
--- a/registration/auto-registration-and-conventions/index.html
+++ b/registration/auto-registration-and-conventions/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
@@ -174,6 +174,7 @@ Search for Assemblies on the File System
             Scan(x => x.AssembliesFromPath(assemblyScanningFolder));
             shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
             shouldHaveFamilyWithSameName<IWorker>();
+            shouldNotHaveFamilyWithSameName<IDefinedInExe>();
         }
 
         [Test]
@@ -182,8 +183,32 @@ Search for Assemblies on the File System
             Scan(x => x.AssembliesFromApplicationBaseDirectory());
             shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
             shouldHaveFamilyWithSameName<IWorker>();
+            shouldNotHaveFamilyWithSameName<IDefinedInExe>();
         }
+

+Do note that StructureMap 4.0 does not search for .exe files in the assembly search. The StructureMap team felt this was
+problematic and "nobody would ever actually want to do that." We were wrong, and due to many user requests, you can now
+opt in to scanning .exe files with a new public method on AssemblyScanner shown below:
+
+        [Test]
+        public void scan_all_assemblies_in_a_folder_including_exe()
+        {
+            Scan(x => x.AssembliesAndExecutablesFromPath(assemblyScanningFolder));
+
+            shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
+            shouldHaveFamilyWithSameName<IWorker>();
+            shouldHaveFamilyWithSameName<IDefinedInExe>();
+        }
+
+        [Test]
+        public void scan_all_assemblies_in_application_base_directory_including_exe()
+        {
+            Scan(x => x.AssembliesAndExecutablesFromApplicationBaseDirectory());
 
+            shouldHaveFamilyWithSameName<IInterfaceInWidget5>();
+            shouldHaveFamilyWithSameName<IWorker>();
+            shouldHaveFamilyWithSameName<IDefinedInExe>();
+        }
 
 Do be aware that while this technique is very powerful for extensibility, it's been extremely problematic for
 some folks in the past. The StructureMap team's recommendation for using this feature is to:
diff --git a/registration/changing-configuration-at-runtime/index.html b/registration/changing-configuration-at-runtime/index.html
index d5773fe..da0604c 100644
--- a/registration/changing-configuration-at-runtime/index.html
+++ b/registration/changing-configuration-at-runtime/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/clear-or-replace/index.html b/registration/clear-or-replace/index.html
index 3200d8a..635718a 100644
--- a/registration/clear-or-replace/index.html
+++ b/registration/clear-or-replace/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/configured-instance/index.html b/registration/configured-instance/index.html
index 5001ace..51ea4d5 100644
--- a/registration/configured-instance/index.html
+++ b/registration/configured-instance/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/constructor-selection/index.html b/registration/constructor-selection/index.html
index 142d677..6f306c7 100644
--- a/registration/constructor-selection/index.html
+++ b/registration/constructor-selection/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/existing-objects/index.html b/registration/existing-objects/index.html
index e1699aa..ff87d94 100644
--- a/registration/existing-objects/index.html
+++ b/registration/existing-objects/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/fallback-services/index.html b/registration/fallback-services/index.html
index 908722c..7aafb68 100644
--- a/registration/fallback-services/index.html
+++ b/registration/fallback-services/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/index.html b/registration/index.html
index 27f7f1c..5e4e669 100644
--- a/registration/index.html
+++ b/registration/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/inline-dependencies/index.html b/registration/inline-dependencies/index.html
index b3a6962..70802a6 100644
--- a/registration/inline-dependencies/index.html
+++ b/registration/inline-dependencies/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/on-missing-family-policies/index.html b/registration/on-missing-family-policies/index.html
index 8edc88c..6fc6de2 100644
--- a/registration/on-missing-family-policies/index.html
+++ b/registration/on-missing-family-policies/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/policies/index.html b/registration/policies/index.html
index 13bf3cc..61fe05b 100644
--- a/registration/policies/index.html
+++ b/registration/policies/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/registration/registry-dsl/index.html b/registration/registry-dsl/index.html
index c984862..1f54eb9 100644
--- a/registration/registry-dsl/index.html
+++ b/registration/registry-dsl/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/release-notes/index.html b/release-notes/index.html
index 1635aad..4009264 100644
--- a/release-notes/index.html
+++ b/release-notes/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
@@ -93,6 +93,11 @@ Release Notes SemVer versioning policy.
+
Release Notes 4.1
+4.1 was mostly a bugfix release, but also included some new public API calls for type scanning discovery from *.exe files.
+See the closed GitHub issues for details.
+Release Notes 4.0
+4.0.1 was strictly a bug fix release.
 Release Notes 4.0
 4.0 is a medium sized release that largely builds on the existing 3.0 architecture with significant improvements to conventional
 registration via type scanning and several performance improvements as well as some bug fixes.
diff --git a/resolving/get-a-service-by-plugin-type-and-name/index.html b/resolving/get-a-service-by-plugin-type-and-name/index.html
index 3111109..36479fa 100644
--- a/resolving/get-a-service-by-plugin-type-and-name/index.html
+++ b/resolving/get-a-service-by-plugin-type-and-name/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/get-a-service-by-plugintype/index.html b/resolving/get-a-service-by-plugintype/index.html
index 0268c23..b92e15d 100644
--- a/resolving/get-a-service-by-plugintype/index.html
+++ b/resolving/get-a-service-by-plugintype/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/get-all-services-by-plugin-type/index.html b/resolving/get-all-services-by-plugin-type/index.html
index 6392b26..b09a293 100644
--- a/resolving/get-all-services-by-plugin-type/index.html
+++ b/resolving/get-all-services-by-plugin-type/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/index.html b/resolving/index.html
index b9d5ed6..03de309 100644
--- a/resolving/index.html
+++ b/resolving/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/passing-arguments-at-runtime/index.html b/resolving/passing-arguments-at-runtime/index.html
index 57a9756..fddc4b8 100644
--- a/resolving/passing-arguments-at-runtime/index.html
+++ b/resolving/passing-arguments-at-runtime/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/requesting-a-concrete-type/index.html b/resolving/requesting-a-concrete-type/index.html
index ed74965..bbb71a8 100644
--- a/resolving/requesting-a-concrete-type/index.html
+++ b/resolving/requesting-a-concrete-type/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
index 805feea..a07cbb7 100644
--- a/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
+++ b/resolving/try-geting-an-optional-service-by-plugin-type-and-name/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/resolving/try-getting-an-optional-service-by-plugin-type/index.html b/resolving/try-getting-an-optional-service-by-plugin-type/index.html
index ea31dcb..6040afb 100644
--- a/resolving/try-getting-an-optional-service-by-plugin-type/index.html
+++ b/resolving/try-getting-an-optional-service-by-plugin-type/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/roadmap/index.html b/roadmap/index.html
index 1b8904b..cd716ec 100644
--- a/roadmap/index.html
+++ b/roadmap/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
@@ -92,14 +92,13 @@ Roadmap 
 			      		
 
-StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's.
-The ongoing work for version 4.0 is a much smaller release that primarily improves type scanning,
-diagnostics, and performance. The only breaking changes from 3 to 4 are in custom type scanning conventions, the removal of ObjectFactory, and
+
StructureMap 3.0 released in early 2014 marked a huge change in the StructureMap internals and public API's. The 4.0 release was
+a much smaller release that primarily improved type scanning, diagnostics, and performance. The only breaking changes from 3 to 4 were in custom type scanning conventions, the removal of ObjectFactory, and
 the elimination of some obscure configuration API's.
 Please log any suspected bugs or feature requests on StructureMap's GitHub page.
 
Ongoing and upcoming work
 
-The 4.0 work can be browsed from the GitHub issue list.
+The StructureMap codebase is going to finally move to xUnit.Net before doing any major new work.
 A new package called StructureMap.DynamicInterception for adding support for AOP with Castle.Core dynamic proxies to StructureMap
 The StructureMap.AutoFactory library is being rewritten based on Castle Dynamic Proxy to add more robust capabilities similar to what Windsor has
 The StructureMap.DNX package for DNX integration (an early version is already available on Nuget.org)
diff --git a/setter-injection/index.html b/setter-injection/index.html
index 375a3c3..193d28b 100644
--- a/setter-injection/index.html
+++ b/setter-injection/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/software-design-concepts/index.html b/software-design-concepts/index.html
index 42a6445..1a37410 100644
--- a/software-design-concepts/index.html
+++ b/software-design-concepts/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/auto-wiring/index.html b/the-container/auto-wiring/index.html
index c8016ab..0216c12 100644
--- a/the-container/auto-wiring/index.html
+++ b/the-container/auto-wiring/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/disposing/index.html b/the-container/disposing/index.html
index 2f2b707..04b6a09 100644
--- a/the-container/disposing/index.html
+++ b/the-container/disposing/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/forwarding-requests-for-a-type-to-another-type/index.html b/the-container/forwarding-requests-for-a-type-to-another-type/index.html
index 42eb167..ab1f710 100644
--- a/the-container/forwarding-requests-for-a-type-to-another-type/index.html
+++ b/the-container/forwarding-requests-for-a-type-to-another-type/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/handling-missing-named-instances/index.html b/the-container/handling-missing-named-instances/index.html
index 41e617e..cd6bbfa 100644
--- a/the-container/handling-missing-named-instances/index.html
+++ b/the-container/handling-missing-named-instances/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/index.html b/the-container/index.html
index 33d01a8..1718950 100644
--- a/the-container/index.html
+++ b/the-container/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/lambdas/index.html b/the-container/lambdas/index.html
index fa93bf1..809044c 100644
--- a/the-container/lambdas/index.html
+++ b/the-container/lambdas/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/lazy-resolution/index.html b/the-container/lazy-resolution/index.html
index 54920ea..393320d 100644
--- a/the-container/lazy-resolution/index.html
+++ b/the-container/lazy-resolution/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/nested-containers/index.html b/the-container/nested-containers/index.html
index 33c8df7..1b0c5c8 100644
--- a/the-container/nested-containers/index.html
+++ b/the-container/nested-containers/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/primitives/index.html b/the-container/primitives/index.html
index c383e5b..8c72a97 100644
--- a/the-container/primitives/index.html
+++ b/the-container/primitives/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/profiles-and-child-containers/index.html b/the-container/profiles-and-child-containers/index.html
index e5fd562..eaca57d 100644
--- a/the-container/profiles-and-child-containers/index.html
+++ b/the-container/profiles-and-child-containers/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/working-with-enumerable-types/index.html b/the-container/working-with-enumerable-types/index.html
index 5abd419..2d0ed8c 100644
--- a/the-container/working-with-enumerable-types/index.html
+++ b/the-container/working-with-enumerable-types/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				
diff --git a/the-container/working-with-the-icontext-at-build-time/index.html b/the-container/working-with-the-icontext-at-build-time/index.html
index 9b6e49c..1302d16 100644
--- a/the-container/working-with-the-icontext-at-build-time/index.html
+++ b/the-container/working-with-the-icontext-at-build-time/index.html
@@ -71,7 +71,7 @@
 		      
 		      
 		      
-		      	StructureMap 4.0.0
+		      	StructureMap 4.1.0
 		      	

 
 				

From 043cd2417a851d12d73ab59d27b84cfac2e9a834 Mon Sep 17 00:00:00 2001
From: "Jeremy D. Miller" 
Date: Mon, 1 Aug 2016 05:42:00 -0500
Subject: [PATCH 38/55] doc updates for 4.3

---
 best-practices/index.html                     | 156 ++++++------
 content/images/structuremap-logo-114x114.png  | Bin 0 -> 6999 bytes
 content/images/structuremap-logo-144x144.png  | Bin 0 -> 11460 bytes
 content/images/structuremap-logo-152x152.png  | Bin 0 -> 8275 bytes
 content/images/structuremap-logo-210x210.png  | Bin 0 -> 12719 bytes
 content/images/structuremap-logo-231x231.png  | Bin 0 -> 3970 bytes
 content/images/structuremap-logo-455x455.png  | Bin 0 -> 7598 bytes
 content/images/structuremap-logo-60x60.png    | Bin 0 -> 3976 bytes
 content/images/structuremap-logo-72x72.png    | Bin 0 -> 4398 bytes
 content/images/structuremap-logo.ico          | Bin 0 -> 41567 bytes
 content/images/structuremap-logo.svg          |   1 +
 diagnostics/build-plans/index.html            | 158 ++++++------
 diagnostics/environment-tests/index.html      | 156 ++++++------
 diagnostics/index.html                        | 156 ++++++------
 diagnostics/type-scanning/index.html          | 217 ++++++++--------
 .../using-the-container-model/index.html      | 164 ++++++------
 .../index.html                                | 156 ++++++------
 diagnostics/whatdoihave/index.html            | 160 ++++++------
 documentation/index.html                      | 156 ++++++------
 features/index.html                           | 156 ++++++------
 generics/index.html                           | 208 +++++++--------
 get-structuremap/index.html                   | 156 ++++++------
 glossary/index.html                           | 162 ++++++------
 history/index.html                            | 156 ++++++------
 instances/index.html                          | 156 ++++++------
 integrations/index.html                       | 156 ++++++------
 interception-and-decorators/index.html        | 182 +++++++-------
 interpreting-exceptions/index.html            | 156 ++++++------
 .../configuring-lifecycles/index.html         | 159 ++++++------
 object-lifecycle/custom-lifecycles/index.html | 156 ++++++------
 object-lifecycle/index.html                   | 156 ++++++------
 .../supported-lifecycles/index.html           | 236 ++++++++----------
 quickstart/index.html                         | 156 ++++++------
 registration/attributes/index.html            | 163 ++++++------
 .../index.html                                | 201 ++++++++-------
 .../index.html                                | 158 ++++++------
 registration/clear-or-replace/index.html      | 163 ++++++------
 registration/configured-instance/index.html   | 186 +++++++-------
 registration/constructor-selection/index.html | 181 +++++++-------
 registration/existing-objects/index.html      | 161 ++++++------
 registration/fallback-services/index.html     | 217 ++++++++--------
 registration/index.html                       | 162 ++++++------
 registration/inline-dependencies/index.html   | 168 ++++++-------
 .../on-missing-family-policies/index.html     | 166 ++++++------
 registration/policies/index.html              | 175 ++++++-------
 registration/registry-dsl/index.html          | 170 +++++++------
 release-notes/index.html                      | 174 +++++++------
 .../index.html                                | 164 ++++++------
 .../get-a-service-by-plugintype/index.html    | 160 ++++++------
 .../index.html                                | 164 ++++++------
 resolving/index.html                          | 156 ++++++------
 .../passing-arguments-at-runtime/index.html   | 158 ++++++------
 .../requesting-a-concrete-type/index.html     | 156 ++++++------
 .../index.html                                | 161 ++++++------
 .../index.html                                | 172 +++++++------
 roadmap/index.html                            | 163 ++++++------
 setter-injection/index.html                   | 164 ++++++------
 software-design-concepts/index.html           | 158 ++++++------
 the-container/auto-wiring/index.html          | 156 ++++++------
 the-container/disposing/index.html            | 173 +++++++------
 .../index.html                                | 166 ++++++------
 .../index.html                                | 170 +++++++------
 the-container/index.html                      | 156 ++++++------
 the-container/lambdas/index.html              | 156 ++++++------
 the-container/lazy-resolution/index.html      | 172 ++++++-------
 the-container/nested-containers/index.html    | 182 +++++++-------
 the-container/primitives/index.html           | 169 ++++++-------
 .../profiles-and-child-containers/index.html  | 173 ++++++-------
 .../working-with-enumerable-types/index.html  | 173 +++++++------
 .../index.html                                | 169 ++++++-------
 70 files changed, 5005 insertions(+), 5062 deletions(-)
 create mode 100644 content/images/structuremap-logo-114x114.png
 create mode 100644 content/images/structuremap-logo-144x144.png
 create mode 100644 content/images/structuremap-logo-152x152.png
 create mode 100644 content/images/structuremap-logo-210x210.png
 create mode 100644 content/images/structuremap-logo-231x231.png
 create mode 100644 content/images/structuremap-logo-455x455.png
 create mode 100644 content/images/structuremap-logo-60x60.png
 create mode 100644 content/images/structuremap-logo-72x72.png
 create mode 100644 content/images/structuremap-logo.ico
 create mode 100644 content/images/structuremap-logo.svg

diff --git a/best-practices/index.html b/best-practices/index.html
index a2f1c7d..6ebd4a9 100644
--- a/best-practices/index.html
+++ b/best-practices/index.html
@@ -1,96 +1,94 @@
 
 
     
-         
+        
         
         
         
-		StructureMap - Best Practices
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Best Practices
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Best Practices
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
History
-		        	Previous
Diagnostics
-
-		        
-		      

-		      
-		      
-		      
-			      	Best Practices  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Best Practices
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
History
+                    Previous
Diagnostics
+                
+
+              

+
+              
+              
+                      Best Practices  Edit on GitHub
+
+                      
+
+                      
+                          
 
 All of these recommendations are the opinions and sole responsiblity of one Jeremy D. Miller. The single best advice I can give you
 about using StructureMap is to avoid being too clever with your usage.
@@ -130,25 +128,25 @@ Favor Build Policies over Fancy Runtime Decision Making
 the container behavior is surfaced through diagnostics like the build plan visualization.
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Diagnostics
+                      
+                        
+                            Previous: Diagnostics
 
-				        
-				        
+                        
+                        
 
-				        	Next: History
+                            Next: History
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -182,7 +180,7 @@ Favor Build Policies over Fancy Runtime Decision Making
 
 
 
-}); 
+});
 
 
     
diff --git a/content/images/structuremap-logo-114x114.png b/content/images/structuremap-logo-114x114.png
new file mode 100644
index 0000000000000000000000000000000000000000..fe1fa7f89d44ae831c06d30dda9a0119a6acf82e
GIT binary patch
literal 6999
zcmV-d8>r-oP)ENBH
z26+Y2@pLxDkedS997@Az5v`)>bRl`r|5bU@0;-|U>2Cu4Oz+a|bTJ)ibvivrUlaD@
zJu0>bJ@{)PeLxVRf<17-iJ`dUlrWrqY!KYduCi0Q=uwKL!(ArYLVppw`~q;+Wy3IG
zVKx>l-Heel5^($(=fhw!%eH?_vuRM4mex}zVf6Vis3;zXAD&78nzMoDa?n+uiTCfD
zgBx-#M{KC)?wxWW9j>y_BLp`OFU-hXiQ8)5Md`=?qU@7a`VZxww&JPxf5-O6n{mas
z8PMwV=y{)uY0yL8mRPQiM
zG2LD{VU}$74pMxbMcv0o`Qoq2RQr0!kb3RKJUp{`H1s+R_&m>(3pt}Mq0XaEJ`+#8
z^9x7XAH5EeIL-cz8%ke+mFsHH&fJ?6UF!%N7oIPs)INnM*Uk3YbQ~Sw4L(mR#gj8?
zIbmAbGBH*5Aw=nSh%iq*|8lujUO|ek2VHbp)bE%GypY?s5T)mHkv9GmIZcfqXVl$l
zwHh1mDixcUz6VKSdYznaz+&qvI}n!f%Gp(POUs3knNsAimuJXsqsSKrM!M@
zcCye>mw{seGc)d_y52nuYZq-*rU;Nw0A5ivv5Or
z;6ro$o5hbO#rWaB>U5x~kCz`WeH%EJ?noZ
z;UO-0CfvNV@-^$)X6R2J1^x-=UO5U+bA(Z^LKLCj-TW~^Y_YQ4;}jd>Z$-AI*6mUF
zZ)+4DTM!7XS_Lnw0d?Ca_VS3%e(st%;Z)ffuaVjDAy&L*Sy>0m@@kk;?t$9fAG`^Z
z5_0j(2YW6ia{(ltO8e6wT;kQB?ey4vJX5JO{
zPcyvTjd*zNaQhBcY<`-uDXRy6ZYHj!zm}&UVb?k9k90CQtc)uw!z@cHUbU>M1Haob
zP~+6iQ0Wbj>*ZZdABkxbr5trnzyGIwq%vT!Au9d&A8dc38Sy8bF5CS!g^;r9&w^N=
zKZ;D(OW>?DS0@??iy0mImp
zKN|8%BS_^y5#}Wo2Me|#Gz;43GobPbgUaXzbzm%X$6W%~p&2kH-tnI5
zL1;;}H~GU6NsPoliz4d|6{7TCQ5aeZE`)JqBP>hGU`~G!rUf^`IOiIe67PUH>rt`M
zfMqprUs-!BsT@Is$dUMJuR;`-Rl~fj@;`>zVOdpg|6AVEFz5V_Tf2x;+zjJ5{?wb0
zx*PJQ?&tb(-F^3dtqUZqJMc2yQ}uqS8${~v?)UZ0B#hPRKf`C;@`Nn1hu;|Xk}pq!
z%*#zJ{{~KXo7(CRv3B=IM29N;(vxjjd*uZUslWZ_rf7&m1K7RFwEyhd1#3<--~2}_
zI;{<`wDo8QVC#2mr18@V){Tgg?(_%o?9{NnjEso&VLiTL*b6no+TL1Yxb}V8J++4Y
zBcekUe(AXyir%|=xWH|2#h>A_#G-3@lw*pLiF)A^i%h}=LmYm?~7
zFHXVVyu+@&-yps9BJE549WJ6@$<9ZVD%iJn15$bP)ie-4;~~BYL~9D7a~^fhI&L5X
zsbA?!@y#Ebq9dY_KxP*pLS2DW4C{)NX@43WG2G3+*-#B@Dk60JKyF{xLLB2D4gj$%
z79!dm2ePY(W^Edx-5nQ@{>CeGAb!n7^h#n8qJ8Tmr1Hocm#0kU69yuB3yAhKMElhL
zklQw1sRuIm6$cTG?kJ1Jhz^Vo86QzIosW5l?vQHKrz1L`{)Y6cSBpT3FS&>w5D^`!
zPCzQgtC!(AKH?yzitey#S~CzGqW*>4wk|DvCSpU1vE7K>f>iDYqUnCfMO2L1OhkvN
zKOy~6Cg)eh7f}(12Xr7FFo|7&R3CZyQd~X;qCFGQ5$Zq4tw0Q<_?&}?^ZQ;YHx_mqU4=fh>lW!K@P6VW`m0Oj5mouEN3PniVzEug;;bxU`?Xwjw(id
zHlhgi59DAum+{+0>;j~E9}rC@ViAaWYYw8Q^#$b4a`xIlicgt{K>$QVoDzft;`1Tm
z`)owhnuCZ_&qHoopSuN!zmGo7K&*u{wTCZ1542h1`wEIwmd+cc<0@MD5m7kh^611{UIg9u{~N
zF$Gck#e+N}@1BRL;7#Jvw?-ACwh&Pg^$g^$^*qGk-H0+b6;V<#A%XZpEW}iyz6eoL
z^#tUua{Bt9Dt?KII0D3=BDM{dviBfLvZ#<}n6+!pdhE4xQik9pJ#&H?k;rSbPdxE>m{(qeItm!J5kel|V{lAsH)(@EKp8MV7cYha<
z8e|sIY2Mit5@7<7pgO1m!hwO8Mpwc^Qp!Y3vtPar5do=%Wy;A40h3P%0W8C|r$3KREU&AZIxJ
zAdnt5so*Pc8Qcf=z$FdQ=RIm#FC8BqA_Tgf_G%GtzYuYbtsWpX(YKjU+t?z3wP9tM
z{PQzujOirQMkwoLkk2;+D0exN6B_(qM=UT4D&w
z-%gHTv`m*GUQV{v2c#y5F5qjxfTM#0xka^bm<&d9{qn(_-y#h81iF}-Z0^5Wv`$wd
zS|B1IH9@o|jphrPTd|NZu2j1r*KXF5%T}$;*1#Z{_Y>0S4hj$2S41W78Q}0DR-T*C
zfWO(+n;#q*CQ8!)Y`=!`=bL)+wBB_&xKM!j1?7VM`1Ht7A!b$)??A*Wb0Ql6QVWC*
zOb5^5U&HMn-2T)!zP@jeC~QSht0=4c>Ak+Zcz9DTXDcZ3*5FPzb)ECFm`Os!N0?1^
z2c#y5MCoc-wLx=sEPq#&)9w81x-doh=$}`GW8|Qz3plD&c`4|BK}+B?V!;o9J2WoA
zKY!RySeM`;WG)z$wwa
zxeF5p_@jy+-n_Iq^JDx!UQG_G21rfx>Ar4HtY$wxh*k(=!B?6>Kv3|)9kPPRTN_-0
zEn{~JF@=bU`}+V=lME5=82pSpCT*RtGJ|L?OV3fgEWBLb>ODk?`DxZ#$+v+R|85={
zqRe~l?yV`(~ZX)8wCHz@d5I=#SYQf85&|`+ORzqAVwul(JJ+Wsw
zgjVdQ*P>OHdSV{AGaiuIAS#0UA+~7Vdf_M0(%cnNnnKLpa)6B{e~G9TcgP{+o!Ad|NM5w_Y_?1V2TYzP^G^OB5z;5*
z|4`TJ>sl+2Z?YrZAxr*$o$TcJ^5f02W`4FrED=-#B8u(61B1jGF#F4oba%+Jz)0$c
zD$9=?+Yl%nS%5V}Jg`B~VjORYMY}rK6Rs!Q#^XrrI$9>zi866cYzTl}C!PL~I9PT!
zjBgHKVyNALDSrr);YG{S0v(fIAZrSSu^&EX`lDk9IamuwE&jbc*o+gD?M_6@ig1VA
zKdA;Anh$jSs7HsXj{*}9#sJDI7@Nh%__Y{t*VUsQrZ!`~r-a1;fL_As2SI@27XNlY#ALTb6u?xFFQhhNv%|&1S2%MN
z4>FBES{6`V!L5g{9LGKdsNm}16H;+YL^rxcnTYo1cs6JRAc;@NToY1ur;%F}x5VU#5r8t`6EZ8f
zAT!($a!t-mY$7)+Zi#bjBLQW>CuCOe!zZ{D5>sPK;(a3Y;fau<
zB`OthzTLHmJ|Vp;WctL$wn2%AID6!)$+kp5uJH-!6(PksF~zq2!F=~byeYa<*CP6a
z^sb@r*^&S$KrJDCLJAR6?Q8BU
zZHdW|69Fki4IzC(@`7mNjpWGH4;CoxP9rA)QjSl^92fE%hzN03iS9Jj{fW)Bl*mbd
zJjEwu4hs3rpcf+AR^C@6Vid!<$^po8d_v}!knAYqcP&}Dh}Y)WCj-hZJ|S~J$j=<)
zhxa}%mlGSeMVuQk1yD}l6Eb^33K6eEL?w&;d-GrX+cpJI4&kwoJ|W{+$IHn8uheDt
zm57Lm4faN-0m?Z%64EE6f8wEIdlw8c-b#sFqD;gn#(wK`Ksk+1NLNB8z5McK811n&
z@xZA|DbXwL&$lZRF(q;aAQi|WWY)a%zK}Wpvh0b6`&*}|)F4kL2sr
z*);hy*PXoT!S&Q=nCRNv5)rKyEzv#`kXi^K9mm<}YvAE8Cq6#uaGn#gfa6>sUVVQZ
zuhw_*`ufA40dj`34+_k~-;c+W&Wy4F*4ipF0+;?-pPY(Q#anR2F_f3L;t*PsXMqH8b}3}^BWLf)~gFW-!fEr+vZ==SG9%P&O%
z$}1FF%~o@-MK}B!_e#&Z(2KkS)AKIZMC5HAu>Nz}!8$-M;rxTtigboEvZ%zQBM$P{
zb3Thfl$Ohn8%+K@v`K#c(jnX-UCd6!_&FPpnjp%N-uOO|M&zg05Sz_rwggz&-(-?`
zGlYFYrobdo6PY(6h76|7q|rSW&XvEHx557*nF6NDnn+jS4;BChT)#pHFBsZ{Ki$xi
zFYQd=>!?ir^@DicHK#ofiL1;7ti}vOK|Svs5X{a>-qI&QwrPOW1n~#(AHc;zBe>Im
zF`TmF2yZy~wJ1|tbL3M_T(pH7weG-ryc+<3L_I0Q|DDi*4M5m;Zkg1QpBx(@Du7X6DC;9dv8X731>fxG
z!=0Lx6hAz_S<8E*n3+Yy>=cliAliZlKoo-F0`P$!9-_YR9;0X!+!EEk`@er6Y7UdP
zALgjivRaw`3<^>1L}PFVaFe#3dE=>XkoP0rmo@M29-vbB9xwd(G?%PYJyW%^^P6xA
z;F!?-{Ezi-GhcM0gd3H?Pw_S5x(as*4lkhReoAq}pc!QWHc8@L#|^M@
z*{?8H5Eo|ineVtlP3f;gn}L?R8)33Syi>v$-h-U?e0}GYCJ;OR^eb0u*h1#L6BsB{
zlmoYeEPi}^QAZ)75^I(x5Hqe(EQ^a-%L;c$F(%IP!kDN58v(!Gv8QN(vJU@M?8P0v
z`tU!waB!HsD9y>cF%NLv*V>7e2i(gW|Bstaf6JlvSebVmWr}5h$9Ao*OvFqr^GB3*
z7s+oHUF?VP#pf}T29TN{N`r?5ixlVe$G=eOA|<-9fm7xS(19aq_uz~A=`3v&$
z{eKbSD9w9x%4*hX#l-Uz&;!a3zAhN#&);qDE!{kn1H+<(b`|Aa5>MWVk$~Ix8Z4Zk
z6dDhSR9JS`l&npl7)l(rwm)vX2^eiq?
zs>dO?L*fQJpDiH=O5*I&0UXZTjo!EpSh-YowCnh?c-hiD4j^oTXU@35;ti2H5IW$DB9X&D@Tsoqu
z{J|;YomdJm^IYJ;WCw_)%1tg+xu)>20oBMmF%fXLp-IBJOu3LZ#l}X}`psqDEdXi3
zNiAB^zPWFC*1bafXP|MFa4F;)mJS~kI
z=;P0>A@^I#@`i}Z_x+iz`Gj@bkDwqB(F+Kt#D~X*EB9vqs)66c`r=hB9Vqi%vlL{$j3^05z+g+)}g1&dl6*{3%Ce)
zXk2A!$mh0*pKk0aU$4ZVBY8La01maq@~Th%;m&kkv|e01;qQh?hxB#}A@4>Uz#2A~
zm+ZM9X3uWrjjni9@@n=oiVgIuAeyp7Rq$VphQ!InJ$RY&h2IhM6c7%PWBK@!PHYd(
zCq-Nc^yJ;}1DgRym#HW&%E2EW2}eaI7eZ`4?*$N18rMDn?aBM014{shMwQ@s?;jVw
zt(bi~%UcWs`?1$LGIV%x1w^VZxkVKm22n9Z%b_2;tH>c}pM!B3zQ<$jpK
zTzQ;Tphz*U)vOhF=r@Yv6Xyuu^YS(7v&n3cdH)LDAvePadVo{l24E+A1(tvq%3Dzn
zd?XKuCT0002ovPDHLkV1ninUT**Z

literal 0
HcmV?d00001

diff --git a/content/images/structuremap-logo-144x144.png b/content/images/structuremap-logo-144x144.png
new file mode 100644
index 0000000000000000000000000000000000000000..ae3ef3035cd691321ae023a633f5947fabeb68cb
GIT binary patch
literal 11460
zcmV;#EIZSQP)@Hn;+X7e+8}$Q`!aK8=G;4EivNTKP=Kc30q`mq2p$HZKm{y;
z8P)%=1S-%DJZo-lJ_d}{f96Qwb^V{!6gHq44q&vMt>s}yg-vdNheKrxwHt?O+&IwF
zq0&iVQ($jn^|htB`5Yo@1#GE)hBXMqXPs+fXaB82_jxX*Q&c(aOaB=1s&fYnK
zkG}H)CyeUFk!}6hNokW~ZccGTqyZLGf5Ht!Lz)Yr?Yr^d=taC_>mmN|%QL+B*hPtr
zU!UW5c7M;4lU8%vuD#j8*`)xoEhC~JU=B>74>Qoo#>!%MD_s+QdrE)EGM4$PsmwQhe+Y_NreMT)X|e{C7cuiV#?Rd&`t6H!Z<=L#W^=Wv^@J^9UDUkPy}
zX|^28;w{Is4TIOVL8i>Vnb#jW!F?Wmj&1Gie+sYUJ24-bEaf;5;^sI|CDEec
zk?g3n`GJVqlf0reT8y7Y&R)XXf67OWlOu$abp!Q8Y
z`MWhQGas5HM7T9RpU8iHGK3@B_+4&=Y)C#auSL7gm)4-`+WvFC5aE^(33ke_h1|Yp
ze>S(Ucw3q$YGmP$;rfoK7dxZ%k-9G9@a0rqI4qJ~RJNZHk&fgM-r)0*vlmMz9^A4(
zB6mu|=qv`Ukex!AMMP?9WYI?B<#=l2yobd|%7_9@;oXa$;t+qA93tvU@`$^gT$=nA
zzhO7;_@zJyU=+6FcfI%NZ|vsj!_sVhBa6PRbZ#ZzqWePrV?2QlPvR3B2XS~)&q^YC
zLMFMvKwW6-f8I>{1_E6&nm|$>1)8_*#F$`=A$(~xARZR^&xwx*i<53VfeuaNb6baT
zrxspJM6bwXvTb-+rydvI-E-WiEf55feqZ~@yM;i@8=F9nv~T9ge{Oos_yTSFSD*nh
z5okoK&Jhsk2cx$@JAb{z9U}V)fmSv)fzXAy7k{_r6{B}yC()`2Ic3y^4bU`idG3wW
zuZ=4Zl5sJq7~C?PiD)V{vS_REb~?RjfsvEwFQ#(lQY6sZ;bCTG
zc5ukFSn0%XGtw|V1H<^Ki{E2Ad&M~-@@b59KjV91((e=||1b%7>+*ayfwNLZ@_k)2
zY)&LR@|(5hngBjgbdo
zDdVjv{n*=8ahiyFkh~(?%-sBku?ydjS|A8;%ae%n-rLDeE^cLwc2$1sAaDO}fmZ9<
z1vlZ}HVwJ8(HKTwXHjg{t))*n5zPh;B%^TO%pPXGt@ioqn)CAQhi<7A5+kn-NB`om
z4&5rTjPXArvZKZpXOcae@Ur0fzs~fpyr;P>zxHrjK9@2=5`hoAeq)QM=>Bq1u{djB
zHzuMK5KJ-(<@jCh4zmufQ%u@gMqbT0ylXH1-`*c2iO>?=*svXm^QLdlbH68E7KLR$
zN}si{#o0w#_ncUDY{_CBmoL?!F3gt$oGp3K1FiX2v_zH2Wl&IdZISSr^q$Wr@ZYE-
zib67OXJd6jsvDM3*p12XQADSGporO1p`86G+YepE~sKlzfV1^R=CA{t%Sb#9K@BQH)JSGHKo`3YLiiPLZ?L|XTzAMY7lK}6qyXGuokJaL1gGCF;OGG-4e
zr)RKoY6>f7A7s0s?=X2a<$$JPJSpK_ejina+m7c5LG%>pxg-I3P%Hg6&wTq6Zq=!W
z$a%g2JsV%QHCNXpFJ2v6wnQh%lMQ(;!^?H(y?l$Bxto2bu(dw<^1Y!IAI*M%zy03}
z{O6Xz=-!4)oZ38?kF9x;x6XfgB^A)<|-Gs!5NMsIRbMyJk@O%Sb+wwRY{*IkVDZ%#z_fz@PY_Ps8^v+Ulk
z!TfT+P>Bb+g>X}?SDB@y<#8g~0GVM~h^^=`Tz!$E*>Vl@>-MMq$2PML~^kNT9({eLgdm+x-;9hEsaejfDDnCIzwIE4T
zS#Xs+d61`Qv9>ZVLA(0&d~bh1mmzhB?$l@0IqLKxQ|Ni{@&rYdkeafmC
zd#jjrkfrDF8X!3#$rGJE0||4HL3w8GLoSq_sfSq@28?2@>Y_l{5F2SCc0?qbgyRAR3yfR79n%g*>GO<-uqREzq9p{Qoow^v}{J
z%A5r43PbV;iWftk1kJ9(WFKEZ*MV#WqA?rn6jRgQLvB+FSqu)<@qDIY%FZxA*F&Qg
z=#Q8{Cn@Jaw`EA460|&cKJDTHoiCv4M3w>t#;meMx3vcH6hjgNEsw}~GIlGY(wg1K
zI#r_;=ya^NTVA~8EhNmv`H6<*$w|;;T$ml~1Ly{joj_8{6P31F8MC(t{~rctnDITs
z;q}y@+T}3`Bux_LC2Cipx)~akK!0G85JUASL-Rahv{k-DTb>iIPQMTz>;vc~k%d4GF)1#J
zsEoCc=jwzRh;Azr@}#GV$wWXmOQR7eXP&=vcA{pQXn8IrRhOr1sir(PL7iHA!YuzJ
zS}|&~2P9dKZmS$abwe#rnUF{E`gTu1w?d;3C^z2MB{xnJBg82HSC?d<R><
zt@Q(Ri`-d(W^eUDw}nc=y%mP#*)5(=#j3j}pj)KD3j}#uxL_G#Mq#p!3$B=9&eE@{
zqr$K(H$HHCcC0!8kP*030#&OdG%(t##P_tz3!_G$VGDF}UQ1`u@?Z_ipgbjz2j913
zqa*{6k+>rQ;Y1p)B-G2Je?HxA;#Pk^Mxx;g#K|rW7ZWtoMYnY+vHHSjNwSbf{mHpm
zep*0AC6Ky^gJ5$MzyUpq_^CW?hoL&ac4RmET_
z=i{0N1FB2vS|Di%j-fhoo9gmR6Y`)2dphcQVs`ifszVxvK%(2q#zlXHNxFi98svdg
z8E59}S^%nR>QW%pxUFtjF~6dc(BNq64ZE03UqE$C{TJxyAhN_Gej|1SxTL*kR(sMdLfFz@(K*egJQ6}B<;Su
zI8891+eKXnL@^s`t|XkMAF59im4q2SfNm4@SD<4X&}}VL#}*}O@(h(^6bX6awFh&P
zG(muFAI2AmVpiHi9>bM{Qn$5N{QfX8{D5~XL#zLOrqU7pB^-{=_o2WU6qA?vHIdHQADW;@*K$`W+
z7=0z7!Io!N+T}_@86ayX5c@p$3Pl9IuKNzY5k_lG`lrB!Zp7d)A
zgk=Y*l5pCd${H&PqtYNxrY9hoAYXxmJV=PgVYF2){d9!u;_$Z25fB8EW%zD!0AXDFxF
zScWRTXV}H0`2&(0bk9&vn_+8Gt%t2)>lYJ25?c>^gRMud&$1cz-e^Fzam^PIUZ6Kv
z;Ot<#-QQjHbD*cg8F1F$Lvq7&bC3}#pL2I&TSvyM>i4npdVPR
z^>MuLMDGxu^ICUa6LTMbIQJom)zk0e8LxKbhk68Ykgsz-5v?20Q8_a!PF+~BOvhQV
z|80513^T;qnU$ms1tb^r2WX^|(&nqqEq!?6v+enV8U6X|RnPH>j|NJJyS9Eb`(BQE
zu_H&c_G33E+hgPxzR7mP+C1F-6rvcYB%Gd>shYg2DImFkum%y}9WTGY3+*HN@RI{Z
z^0+z4JSFj6u!<)vSk5nvoWzm+A7bwSO#zYFM?~}xaJZ3;>L1-u
z1wfT{PTwcnU748KAW_k*r7=hc&vX8`+{M!y7-a3xJ@%(Hq&-u>lYIB
zT~(U?o`n0QNTjtS2?---nHMu9KC!!wk|luX(!7#<5VSQ{G|tv)BmiH
zZZlktO9YvjQChFI{=9ejGhB9Xg4h=6+Iy>iIzc+X6?jkP
z(x>qk>d&15tl*m;m!l;@BF#vsQ?eGR!vM(zA&;$%GOyykgcnpFoZrPW_`q+Drb*%~T|g
z3#9F#@SalXrsIhp@8gcW?qLfHi_i4=ufcG_u6`eMZ{^F!*1amVF4)TG`uC6c6p|gD
z%wMd2nY)Ggajzh2KD$6&QMpu?nzcw93P>&>e8AcfkGA1+JBAA(ZhWr{{7iQGD2{%%
z4VwkFW82|t%N%BZy8Ln_pgV5?I*I0>T3-@oEHZtCaA&xhN8!^yf%faC(g7L07E
zcDwW&TAu5d#{l@*Gh2sp`=(w@>dxubPtIxvNKPPzI5%<6p7qXV?6^~SQ(HdaXQZxf
z#g3yK5Y)Vqh-T=Wk-`k9?QN|7j2j+_zJAKhA5b8~D+epa_hBMBW=#|ZNG>44TvWE-
z%^uX9D{n;}ApI=%3tK#<7rQ&!{4TdmR}flo`1#S%x4diNR*;VTXzctIVz%fni-+dRP4R;UMNiM)<5aUgyvX^$GW{
zB%&ywAo;}W+GZ{D#oqDTjj;8%*ns7e?=NtR@GgvWXW`{m$llJ{^0OHOx-x$~m3f~L
z_7KHiW(mG89@UG9=m2md1HnXQ97EKY{hZGeQ74i|gxlCFj$za#S`MS_+MI$s
zYGulo?BL>BMnqizJ+Ah0>YP&38jHN=){&`{8$eikLjt9b_qmFa7W0|
zOZ3*$uG|_+6Vm7lU6}C%5_!-t?$pAIiRcxX?C3K*v_rRxt1^!pS)d$gW4dVRA6+0Iz;vp
z0<9p#;4obiF3B8YWPv71dy(GPDUc`iQ898L(Vg5j@~!}@|I&>3`j?wZ^wfbeF
zcVQ2Pb9us}&N=*M&;`^)|38V^e~_!3tt)VIsxwHUPhSQVk$lZ)-X>2f{c96vN|6tdVV7@CZBDS^Pe+mues{4!rwftWF|#p|)T4LR~~othOC4rDG#h$sY*rInTWhUf2Y&Xq@Ra%R@RY;@l4u{`$4b`?bQ
zvCJkCM@O{wtvt2qHKR?M=3oN$zRnsZqM1NN@`=^G9(<~N!xw+^wx9EiB2fCN3V!g#
zp=@Pkvs=F`L}uUtZ&yX>*Q;I>tM5k1e~#jJX}p~-N=c=>qOF6{_V}WaJ@Hv@btwbj
zcdUx)&pu6*XNf41~`
zq4dzCo0AAhcp3hpmyNxPt*tChN?U2mD6+A`4=>ln9E-y|_H1D>#k?RcRe-Cq`s9EDyxn^?L~xQdhFd(K$;b=)jz=
z3QI5&U0K#!llpOizFgtD$~qv8IG{!Q#_>B-`m=|#v|2l!WE9v;&M`Y)Hv@P6D5_i*
z#2Arrkf$Awd$tpw+B!^hMc0=Tp@kLiJ)b&?V^O`}<*GPGM14u#@v5Ctb$Za$`MmM#
zvyu#3rM0oFYt{lG@fPouYJw&u{f|Ao{R)UE23P}wVF4aOX~#E@MBpGNKOt2bO7%gQ
zER&Wx4(K^JL6Sxq4&%UQqJr^>ULmZou{tKz(8?(Oj??<(C1^L4NJafx#yT7qCFywQ
zFfSCo*>dORo}4`HE0N1*Ty-TppFp865JP*Hd&
zyhk6N@z%$XBUeg@cl}nVAEo6=!fgF17j;9IQ2$dd)eps?2n~ri+p8QzxylQ`ifRcn
z&>gG|@pmpBaDN!5E`E~FZXX6|q^288=F0uA^J(M|TVfyO5s$Uy7HZdWB6=TmAsNL#
z3j;lK6SN-`Cu<~mvaY}CxHg6FfBrQN3~pXwW@h$@{tv~9ZXmqDlNRRY>wKc>s94
ziw}1Wc44iz;{|I=i%mrI9PlL>#p#$}x2!nr`z7KIuZfzgE;G_fh5x)PXxWCrp3U{e
zU{i5*#y+i|ducnZ8+X(>NrY=%S?A|bhC;N@^woF~z=`T-c!I|;i@es|+wV+pvliSX
zqBr-s?-B4Y_qeM+hqh|RzJc02OG|5UUS9-(bdzBQyr_BKk<@$WDU0qeux0y)*fRV<
zHjj9jDPq8HWaHjPFOE6MD1Mvo?3f>~Sqn+Z@)Q0mPkw@sN7_#{;Zj0?7a#$`o?7;8
zXYur+Gvb0m>N`rp?EcAY@zngY6x_W75h)8a*l}MK_$7G(8E>n(9laL^`Mj{;NBnhJwp`?4ZIqw2#ST`-xkt
zh)QR1uEjYAR2y_XZ&FO!(HFOA`w`bXNe5G6)&W*c%Q&ilFaV5JtYqru+rMImEfV;=Jx<
zoa@FXkks7)u$nyL-*~zV+%7AAojnLuKB0{35h58YNtu3>pfvmwu4lYLwP)rLu+MkG*PY_MBSf@U2O
zW^6!bKpu?3auT$g{(xkFt_PDqjYOdHn7_gHPwNYlusmTvo+2SnoRFur6QJwGBv2y|
zs1R#g`B*EUOMllK0fCb7yi;^3so>>HW3KFXCt73ed;#4oCV?8DKqvL`K$4=ur0VjBwJo$f+lyk=0f24=lRynjpv#qng^&jVRbN$?
zwujPeH`X@bCV?7|Ko`*+iAut%+XMes9$cJQwLB50iMzb2ZVXHUH4uStV@{8pcmtJ$
zKy+i5q_r(g{MkiXcRJpPc^-Q3%i^3GBQC^MFR#DBBgqkh5)2cV1
zy2d0>JrW2fOqCsnVz4A_v7t)BB2*IQVqx^x7_B>?+kr`-dLodtww0iHuQ=)2m4xWt
zTmaoJOaj#dfzHfDZF0PBZJ~im!knsNuoB$8Y*ThZpcA0mh|C2t350IT&l?Hz`xtGN
z*HlS}c^-phsCAF51u_YQg;D?9czq>dqPBXsB~=otQAz0N4CoFZSAk3diAutJR1y}|
zSV^dB*gb^Ig0|+fMkGN1TqOEDhZJo*H}rYzdz58^K&)9
zfaHQnpgIspx#+t{)q*dMs}>w()y(}>EX1Bsb3Z?1=>9;WupN?oP*OuBVG%}KkS8u5
z^Fe^*gz95D!-rH0zxwyH;v9o7kBf5-s5a=j
z-V{0bIqE;*1Vs*E>hN3@y+<+KKjk>-x;F=O8F5Jsx-EmZm4iIeP`#>>(8C>&+@R1t
z;b!-ZKSvR-FtvZYipT+Me*eU?)V6OsKn(`J@KCdR#{NLP2IF%+rvI!1+3enNCoCcd
zJ`1QeuK6OOH&{j%*1!1sd6h)A)9@pa%_KUs3}g>)&mtl^3KBs_UL2q^8WB{sarXWE^}EkupRED>*Ou2L
ze%bIUA9>?xUOAyJ-`_=BVn+0H53SXKGxIg2Vr!?1vDI^)oOpGt+~h$t18>;a+Wpb3
z-$P|%uq$!WN4t4d#y7n7z|Ruzq<_r`8!~w0?8P|9_mx;!S^r8z$v{&NZ?G9}Zej6D
zr@QVg9X)p`Cw-X7tJ44fv%b6gJ6^nTA5V;XhdcKAzwXWgxQ*raOdjf
z)?p|!Gcz+YKV~d5Gc$A3JV?sS%-n`-{iV(MF$8Yrclm4PTZ(5Qqa
zNP$#b$e~4|lA_9$NMHX+Be;hk5!=yWoPPmHDEj?(f6h2O4DKMjf60V85bo;^G2R;Z
zWwZwY<|v5xNy2y1|J$OcX`lq92(32iSfC{?eZusWup;>;Y&!Q63CC|>E7xmDZ-{!#
zpQF4CkpZK>T?}QyB53wKfT|=E3=2W+@hKDZZq#>+3E3pU}N>GXCT{7yl3Dg-h1YZK{`n=fsal
z8j(Aa&0!u$94A?&ycb0IXyC!8KGyW_eK+34JusA@6rp*bmg0l7ZS+uWdLnyncv|#Y
z0*@>@av5qg??|APIjCZSGOY+|4+YP{LlCtpB*3Zhgb6_)dMg&Jk_M`5z``V{;P#VoV6g+vuJw4~+G#>%JxCGkCM7rNET~SEeOWXcM
zQ({8o9rYy5L>aiOEgV}LM5a22BU%w9C`4ox9bMcnb{q9E@vrg;V9SP)5DCZV=zNN!
z1e9g*Diymt`rAc_FvuUZkf=SoZ`oiZ=0rv(7lN*ox3gh2YBifxH^yvVwq&9B-9n0S
zb&D4zUtcH$LTjIWMg>R415M}KWPs7q@<+2!+47Nq*B*q@D#TY6YO1ADt&C;IuTwsg
zZ(nISBZWjI5^(oxiSQ&8HW|cQODEQq4Maj;G2VGC1DbUo1UiFZ6VI=dVIC@#I(Yz=>YMR9Za&Ww=6q8N_uwql58D}fgYmK*
zCRnwoyUBW+7^25=pZokW*t^Fm=muC{;QrT|xY?{$Wugj9qjN3Kw5D%+qE
zXKTTM^WYy;o(8q0LUO*5v9%h$Type^tTT`uOcz)on)09tf|{}KWe*^U+Em20nI?8qXUbB
zm6zc1E@2l}cZbL_#b^oZp^zo4iEp`3E1|2mUwtRrpi(J6ee2J-gauPxP*YHb4G4`&
zcshUoIe7z!mar2Kz{{^J2x>Loaj%8UbK8AFU?&ZiaRwR=Kh0?eMcqu-@iXcP%CM-C
zKEBUBUbqEz-OQ3{P_aL9(+ZPjt%YJ9K6JBK6yj^sLd8qo`gX%nS#u!bsm|GZ8eHBh
zY$XmWO7L_rY94L*tck2;d=_dk!fEmPKl0suWtg9%t6Ngnksng!Bu5oS!T`#Ic7w))
z$l#LBhO%XMo#rY(9-=IZc64^R++*ygQZw;+z7k5h
zMyFwu35$IeuU$c5z9#C8rki8FTY~#wuk*K+arz1Dy8|%#yT#z(;`T;@6srWuOlrpF
zB!+py!yWyJou20)qK()~E4x9kxo{d@_j3hqFd9(fd;>#a$+2tHMWzmGUb?dQ-gH=a
z_!4*r1cFp)>J{dz4mH&`Ff4uEzOyu2<~4YTBTv;Uor40#)Zg-P{F9Z@YsAw%8-zd_
zGU0g;9msj$P{0vS{vj@1^<#Z$K=<)23}u>G)M__1={gYBoq9x@szY
zccE_E9-tP*Rg_CA)K?FjD3apqG~wTuSD(4?bv+NBOjw{SbJ#y&u4daXHJ0=rt*$;ToO=Y82-O8j+>)gGb6WhO!tPoNm@{*9(>>-=wV#
zDpCJ+aOr211MI$O18UIKY|#k}Mu#iXF1$*?{#rCz-P!m$O<~dDOOy!b%vXF3EnAC^
zT*lyO4qBc5JYFm2-+Wc0D(ki4>4Z=Z*i6SeXovon(ZB7~+eJZ>G?G_tHvIGQDfJ-K
zw=f2enktbXLHS0$Hqz-$=fYwt!<4xjcv8LRrj<%n9AJL@fs0P?QL~VaGiiaN-`>H}!5H;H4)a)ETbp`JY(M_}M(pw4?yRQ^jRQ6+#WpTeLf1>8A
zMypMx{4poKGL*lXv6+Qk4e#if$NG;N!R>XuAbsCp44mwa^}9WT;QZ1qFmq%LsBZBF
zS4Z6oeBVd>1YE%}5f!LbtLHg5xuoMEav1#abUdz_3TsZ>%PxI!P}ii~gPA*if&L$S
z4;A98W4Z3~mN7Ps#)$`F!7vqH&KUdF(b@HN#e|wL@S|xkYiA0qNxe^gQt;rPAMifU
zsBacRSWFdgba8u)zJ5dPiQL{OCW<(XnoV^uXz$UEeF)AlRm*!pd}v81$e
zqxgFYrs+`@^y537!Fa{V)h!c!ML%O8Br=|Nn5jvqHyZCSQT&Qtn;&0Q(p_3YI+D=?
zqwyoggt7SNPEsl7f)bUM1LVWkLZ~=Y7xZ-sY9j5SNkQZG|IAl+DW~a*evU_dKz>Ud
e=At?A_5T2uI^LfFiCRzq0000)JHGh-
z{Qmg;F>_|_oHO&fcOG*e=XuXWXlW?p<51xsAtB+byit7jY*YVjSQyWHiY^95BqRnZ
z6-7B6FXRIlx|`0-*|oJOFE#TaHMwM`lx$Rs-SMgePbaOs;iBQ<61Ikl)2=>xSiKG8
z?%sO&bWA2p!A#}w5zcqKm8qHFz<$tnH`jDE=G%g53+6A2;Lj7ENVid#WXi)bx_0Z%
z#A3B2fkn_MD(B$|hTy@9{poS)9*!^V)28G^))l_bfvHuAeNQr}8)(;R-aAQ}3&TlVRC
zyl^ZP{uA@l_w$YbQP0kNS0l4`S2+5d?Sz`wf*&aXcuk^Z;nF?$WW{n}%VHiUA|UXN
zCg^MfA9VLertx;t9aQxsM3C_lqg3Q`l!o`B*M0y|dB+c}e3}z$%Rt-;st>r?v^zmw
zANkiOzJ`B(5M-9>Yxhl_Cv4EDhy^lB#b?vxIq>>vA5?j|bxr$)ZbVu@oo9Nj8#gNZ
z8!ztt7F|TTJDTtom7ZG9j@VLN);I<|Fzgx*A!I4Kl9xBZQa|FYbeILwbt5~BB$}yv
zR9WK*E_`K*drsu8%^V%~mvi_v&;NifBQM$f3Gib3imBf@&lGGY=wys9-Z3mZdIfTj
zXRn8Q@BQjE_W5e>(_m@aLwwad#TCpaCP7QdfNLrF8I>p&zpH1u*E=tp$P{v_piF}o
zITDLYn1vYWSqBSc9>9$Qu+F@^&SuF0pMt51DqgpGrFow6-!g@g+Eg%-pQro3(4cW`r
zR}}BWeJer(1EFNT?p*2oQw)`oEdh{L=6`1*dB_z^9Y|HtbMcB+^(-q29f0~^j0-R6
zB7te_$fce5S>}Fhyg4_X?Z@lY;+#HuHS?Qlb>exFLbL?zyZaXdM=&QHfq52wlT^e;b
z$BIWN2%tSIUyxVQNmu$6PLLY)2J}$2JdHBDkaex36(k^B&xR%Lxq8dBnkA9OjySy3yXlrSsQwO$
z2|XRuW^c`2xW2Q;8>a8JpeM|Bz9#l0&~Q|T;0r~Vv2E3@s`$TEg=W=VF
z@&&(U=Mwk1#au5*)HA?}hs4(sI&V!|fF`y_jH#s0C;-%lU-<|wf$F5(6jM`hcH$1m
zC^7=*U#@%SwzzH&(j_v%+>;cF==V!@y5Hw>$;kL@N^xl(6nxn3Z!k+`UpAthOWrmb
zKB;<lDzV<1ActT{0m#$cDwG^+~9{zTW?}
zyG42xcb^_QJiY$KYYBMMbg@#=yKmSjp8{71OCVk@RdH=Imns(%zd^%@i1eIaRflc7
zSfKkOQce>LQ5Za9BaiE-Ers@x+7BfNfV2g$UCeqxbM?{ZIKYofJTJL`wQ$rnMR1Va
z6=pO+@UZB9%3>$`)%@(jgnlVJsNY_E6!^=~45o{n*;~Uyx#HD$(y*YP_YVJt%$83J
zffMckqhBA75C=p_5Zrz~+LMP!RCb&;7Md+2JT$cl&R>D$j~u3PW5nGX|7gDGs@Y-=U6
zBdo*1mQb{(FCVVB&;-?@dENu8?Ip(8lxUPAD&6qnirQ1+|RJMv_F!p*O!{c#1!RwWFAHWIt6(~py*?;RhLnkuX~W_0{P?S?5_g3W0&-34rH&V=&;b=|V-4x9aM
zu8tvq9IZDMJoG$zpWO0)!yD**qaR01y032}p3Vkp>(D4r18%;*vgCcZP+ox>Raj>>
z)x<^RL@dXz90$kgL||N7`$q>T2NJJILA70254mJJT7KcH7+A`zVB*rihjHqYEv9VZz%Q@cT+rKD^$y9^$3RS*@6btDpeShX13@KbeS^J4
zz?9)@EA1OdL;_d5=(z+gkr{W1SsH&PSx_Zz9G58eCq<6+Ky7Lt_e9708umB52wWu>
zY*Vr+)>9rl;G|i;X4DXo`i)C5WH3!F5Hv)teqZy0H(tq-ciA-ps@7_zD#KGkxzFPe
zWki_}l<%k;QG2A^Nw
z>qok#=n~grD;(rBwG_1*2nVxkG3E0(zkk67Me0NwNN&7~tT%>`IQ2%>1-r|@JoQg!gwJGj~F0g#*Fh#X9pp!$|DOQO|RC3h$+$vTm-GAu4kvN8+^y)tUOC9)8n#
z4>KG;GQ1fx1J&8B75I>rcDh&QVx>QN$qh!ohMdnDqC|K8kWmBx-59rsp0gd%GFBy`
zWGr7u_l^`4yk;1orLVg2d)^O|R}Ra=o2YCbz>RH0-W`SJzcqer#&J=#Iy?QL7zfy-sFl
zd9(4&yW}zF@)FdzXo0SZ*|f%fs=vZ^;WDnQ9G>I7T9d5bTpDT{yZps!tpFgI5)8V`
z`8OZ`%o>W7ynR*nP6)|eBt`Plv{PDB@2=95wwgXU-A<4^1b-s!dZOz$aZndiwF|6I
zzx}OV*-Ab2wA~Wr@Q30M_~X|f6E<0>9fXQO`{7$a?p$5Z$~`DyZ;~U`T9A}f(+yIC
zdVD+;acdzjxiz$|w{k-*M~_b8-1E2e%HkZZLDe~^p8H)Raa3_UX?=MXVSwRmdW$zj
zIvhon*p=V0nrlLhqx??q|ywhleN
zE8(^9NZpm53?(D?1C)xU`
z)1*@IQqiZn(N@g5pTlP16)Wip=BSY9i!k?9MD31F%$sh?8jJ@F>3L5
zzcyc92?>)
z4<*iaf6itM}k2B~Yyj#QDK
z2{a*(tvRIPzdDuowyuPcRfD@C#q@vZpf7@NvvNYelmAktza8@!>QwC8hbM=)`6WY#
zOZOylOA~oK{SUB*@YL27Gi<#P2Z0oCCXq)Y2S#7h%B4*#&QB8**%L3m^WG(vHkU>X
zWQyZZIxT#h$T9)j5{pj+8NR{q8Yi00Y5gHvfaS2tYi)1NSD|Jnp7V1ovVWN(iF~Vv
z&{W8VwUtA%!TKA!KANEQE3S3un!Q@&u!%se`XgM7&YpYJRKie!HIu|5J}t3lbZz4D
zDghOyj@}+{s_ha;?sqkgH->fjvjOrNfqS#IC-fD6&FUL|4+f&!D^D-*l!?A>&sW^x
zM8tefEi@y|gD$0K1Fk9tAX2%gU{kghCBNlNQKNXyFMD?wJookIAH^>$?hg((bN&eE
zz^`FL6al}l)OvvL<(^`mcJ7vZ6IbGTc8<`tC*U-THNnT^DVc3WR}}*!e!5@hTH2ri
zL=Ey=hjsGk3y=K@yXn3tJmux4$g&(LRE^^EtK~e#A-u6^u}2qNiXTT?r>|XOkcX)^!Jz|QrlFR3`GiG|TA
zZ6t1p%;eFB&es#A8HmxiYOx$pkgimPJQ`)e(S|NF;j(rSfb$fPsd281$%TKIF`o(*
zOvLhlL{=glr-x%$_0|ks7`fo9HJZ6Ni~KK}N0vIpXj&&B!4U~h$tC`poojYR$~Ak+
z8MFSDQyhw|bNHB!Ef()~L!XAQn$nR03brU38Av
z+eYbq)@GO@5jz(dv~;<{5@LUUAQFm5XimU!9aoZ$ecF{WhGg}k?TRSu@
ziHZQy{twj18ejnoI{du8(MC12b)Pf6|QU~A(b*;V4G6Lbv;mnv!LSOd-~d=nDVYCpzzqqo9G0T
z+s0OCh)51T$Tn%mc`e#4a+knm$Wz*O8;*K6;EIi1M%vx#rQUU4Y~20Px4aUbmKM>w
zAB^K1Ly$xIVA#^|bISWLu22ID#T>5X`Q@0W71vrJ>E#tnu0FKm##oZeoc+|D^{t4X
z4cXsG5F0e6OjH+3N;d>E^>M&x&zgoVsTH9ixMdRZ(fEBz}4y
ziy>!tv(u*^GPmNNt5G7H?Ub+ftptb@5wo98^FVtKg*p@0y^_;m4wPycD&E7v?HEwCGXGA7cw^N5gBF$5?1y3iS
z6iTy*(2?Y{mY%4;j9%6WkMgOdH(KzE83XGWe9qvtNjk*$hEm$1AS72CAB)T>HjNV3
zCQ4NRG~)5J(e<-Faa*`ug&R)UREgk0vB)aKuYDt(-f?w4`>}J1t#WNKDcflv8lhk8
z;Ogd-a5-BPQ5ZK`#Yja$jV$E3|3;*(g*Mb@&OE$`wpm=CQR*@JJ$L+@9nzNEaVA%*
zF|%{$EOPpnVPq_UT@f~l*nX%xt$-1GuQH4gn?-TH?<@AGfx5w5&#QO9^OwKFi^P@L
z&QDJi98G1;k1v7L622+Bbn)`FtTeKUv-KITyP6-kg(`)yMoX?(Z*#4p25tWM_aT2a
z_}~P}|FizUEkJ%|S>pEk?|wP`
z_V|iqvC7w%P>N>JCMqXiIyW(Cyicv7u>o{{PH>B=S-bQ+w&KBCYJZ;BrV(}kYY%h$updM;5Xns@%`_B
z@W;Qa|1f}5
z{TJ-VYkjg0&mw!E&!qEg{{M*h{~{>)W)iOklauhDK|-g~vdQHV4*ZjklY)z$FAnwk
zukrsyJR1`Jw+4S!s)lJz)J5_z`c7uu0}i#AOe*ZU5Cf
zdg5=a8}Ob``xf&*!P5FI-oD&AwJ(~zy-pgBNcMg%gbiire{v}F8_gzZXD&uAEIOB!
zw6z&v=;qO*J35H@?3!*d;}i0$bBwrqY4kVY)fJGKdu9-r%j!ccdI9i$#po>H-+oj(
z8ECd0!nQai4++@nLp$?$h(5rKRanX4Z~AHIJJ6<`Ahx@jseBuKzgdUr^iU~UP>3t}
ziPC|keSL>jJ+p~8s`mrJxt(c?q=NoW$ey}M8&@Itk5)n?u&b7Po~P(C;LpuRqQ@F`
zx^{NraF3M0C?nrD@@+hN7=ysT-#JyxWcmy9=EKVh&P(G@EeQ@!H%KRAVYP@h#x0HwN`L3!H7MS*jcK0n{of0C@HF*95N(mA2o}`p{8~%NVi9|NYX*>dY^+$MGxS
zEO&F?cf>rqfv~JU*@9epvd4@jS}_LRyo#UmVI(
zBvyl2bo)^SxYy>=j#1Gv%D2k@m_pTAA~VavI*x&FQ)M{bk`_)C3+89S;Q}iJOK=DGc=qRN3K`INaDTtR}srHaubq!czrHQzg&xJ
zkF!!}X!6>g(^>Of*T~}i)OCTx=C?}uoJ4Y-WIL_WDd}y6M0ttQ2mO3+<=nSx-h>U$
zg_iTFFeXO{fvdeo!D2h_+?WXjw}*`nNkyU*dLWAG7mkrT4BKel>=z*&X-?gh4gCC)
zR0WrzLs5B?8z<FrzE%$9i)D9aO$*h+$iQ;$5tI9Rc9Z4VsGyp)ZeyuelX|Wn-Q&h%QV0&_C_-06ED`FeE6qu!V0i$N^MKSe)a+iY)F
zbVtLaHVvWrI~`j2mPDH8U$k@^0iwj#WpTbAa6_W19}?k-Tn_{}W%@e1!}DGJJTn6+
zwD3UCY5djldsW0)-;7Rsmrk|I;9XVlJUS7Q?$;Wo1h2GO+sb1rd4JYeqgG>w<-deO
zk>&Ujmuo|<$IfSrVNsLFx$%;h{%Go4rUS87{Ap$n8Kl5syNVj7bT61C#4j8~onHG<
zH1@6-pfu`0U)4tSqd|xejS&bIWNxT-pw@LCH8_mx6!~8xkx)l)X#OwE|
zagx1yVy99-`}3N7;xURac*@!OQn>3c8QHdKiBJ`CGtXUj53w82eyly2WCU=xpH
z36@j#3qXFWk=i{orCu|5B=7|%_D<3qbtp3Jl@;gU1z+wLsQ`NNeVHH+aZEa2cNF2$|9Q5|Pit0;!gX^m;|bpf4W`ds=*M)}QNQ2psq?
zs@1C3c3Sxp#|M(gr=wQ=cfuS@Z~~=(mECyZubiJfhN6UJrYYM{_|lVwj%Va|-Sw05djo;+4C
z>#iDdWB&xl1?SL)JXlQf>%)h7?J?H;_1)wP>>pPyipyG%n(pjI?R=o}^8WUZn$aiT
zY&xzPM-FoRCAp?t#+2(F1?SK6rmx2=!5geA2wMm9K?}#EDHysMswB8
z%_~yM_v>wtc1+Mvh>d}lCW;R21vEvtFL-P_%P`N&9Y%nAR&Jt_dvARG5$ZjB{P|a)
zd&u(~`g#z-XB1cmaiP5T4k?NWyCWk2tHr1q;`M4m14fFA%z
zv;E#NcH+<9-cx#dooib(>rdW`l9-_FgcU5NHpb8^&^ZAM-5s6*uSGtObLY$`ov%oA
z=Tg!{h2ws7?2gAS)U9DRv90Zxj3=b{XZqT)M*%;lmiX(%m!ZV?n$^E(lmf_H-cUQ=H@iaKtM!`ZLQ7rjUkV0BAG(-oQaB9JD3#Q
zyr!DOI#1Lcp~#fQ&Y^k8Mm4P{ornF59?EV^B_zmZmiIE4VZ!A@?__tMe-=Pe0ct2#
I$eTg_50a4odjJ3c

literal 0
HcmV?d00001

diff --git a/content/images/structuremap-logo-210x210.png b/content/images/structuremap-logo-210x210.png
new file mode 100644
index 0000000000000000000000000000000000000000..ece8d377cbfae264078af153c81fb66033bd0de5
GIT binary patch
literal 12719
zcmXY&bzD@<*TCscX^>jFkuHg4=?s8FQS#WGEbOgG8?>Cf#)P6GBehc-o-utP3p&KT_jQl4=Aosc8Y$Rj_(2@s0(?)QR
z6g=-Ps2r0b+o01HyTC^b3#31%Y(!^9^ypICfFng74*V%CBSeZ;A41*bCzH$Bxqc#rO}svKQuEYqx!;8
zg+EKc$|H+kMQVs(@%3v_X?{_u@ej_~%|4yd^~UsBk7KN8;`b=(V~h^WCN@ZV?Bg!>
z0Vvfpv7WH;sjA>s;I-?Ws3HT(1hR}4qrLr6NY?pW!sdlwpzXJ@B3@dfWE$`mk^jTD;`5hI3Oc{MDiB-9{wDs18vGnV@6OEaTEbI
zsL5T}mV0VwN>l7X2v4W^7)T3ZJz&aiXGU&E(!O6TzOuTs&IqjcbIl6P
z&pcUQ3(VEDogcP{WdEobX^VMI!1|U-r4yUWgN?(xi7M3*YE;PmYa$*$Be#C+v$T}|
zso3VNq{+n9e37-YeO-DqD=N+O8dclGzfxSSUug44G4WbZ}i_
zj*`LcTPxZfnmfVUi8D#5_S5Om&+Mbr{u^ky^KD^Hj8eo242I*KmYWZ1ulb5!DU{x|
zA+vX%t8ZefB4mh`;#lKSB1~}=t7sVv^PI`WnWTyC!GB-QCzzLH5djsNC{w?EjL(u_
zDK>_+d55DOE8DlI9G5=mFIl?X{2_thrJmby7QQTRO2%d`!W9~Q3;-xh-+I`LH$U&}
zZjWp~urV`ZVG`kQxO5q=U5$j1=*iy@;k#PUul|0YG)y>7Hx?e*?Q4pR>b1_~zNuJW
zeZmSDs-Qm8EP*fBk^bDw&8|I)z-K4P!P#=m1sGD`ywD#+H{lp1x$b=aHJ7vN5;Gzq
z4X!;o#(vm1z)fPysoy;(K_dPQxH>-pq<#d|EB>V#z0%{=|)E(W&F}A(3Eh!J-7{j~x-2
z*Bk4fh!SF2RoDJ$tvA#vJkGbyqOObMgHkS8yAx2L3sJ1+p@Y;%E9I20L+IYlUOjK5fmp7+Rwf
z-4JR1{j4Z|gZE~g#M|!H8i!~a%n*TsrXVAAZqO6Cd36pkpO?FARBu@d_4-8}INklW
zdTq6bAoV(CL~AXq$47^2!dnZ26WIk%O({N=Un|I2j
z(HX^^EWcGC8tS?B2_;1LYJLYE%Gdd^D^p<->fcx;QEzF-S@Q@@R3P3OWtXETaZ~JX?
zml8Ae5qK`FsIEi$hV=n{9IHROA>`zJL4XRcBdKhlQqy15naiGavXtb6PhUns(u6;L
zP+a&ieq5yQz(Z^V~Ud3d<5=2nyOF_QH>$)dx*U>!1*!AsAw$Ng_x-Ky
z$|-Igfk0sB^Y$O8(<>o_`KvLZQ4WE^ehFBsD`Wq#ms{AE+Pr2(uA8jzj(`BDeT
zRKuWcN8KzQ1#P=e+{P@ct!;Y{1bi)DSEJBrKM0?}5za{WoIvA<*_Ifk;AP{dvZ&bUr^y>DP%jQc;$EV?;-4q;z$T
zR&;;)PNOkGIT)j7xGBqH-xe^OWZ+tGuu!%+TN%cs#}Uk~s=DNtXRg#@v%hsPYqL0<
z7K&^Pf0(gPz0g~b>|(<1ll{>3@%E-_ct{lqd5jq_QLT_3DGwMCyLEToA=HiAVbZvg
zqIziEd&|-UPqb+@fn3ap7cBznL0qx)Y~0
z<6$87AOdoqbX8pCOsB4|Cl3=1%Y2C1ohwxr5)4JMwF=!47eaanrm4|iSrdptQx=go
zu5R&oWPEyqwi6ybhF}7purnN5jTKuMSH2XeLd|nbY;MSUiREN$li!TMtF2W$8lPgwXNB`J-96#XBaoXd
zqq-B2VUr2*r2&xQwD{2gXkO6IhQh@!{ZHhV)+t&NTL+FeD)sBP-?Kn2pt_15X|4br
zQxRJwjZU|A7x8Rb`-}SHwjCs>ppTx>YJX1u{-Mn_tYSiJi3sTLKm?QFJ6pu>LQeoo
zZ37;cWryqGMj;#2;a3n2FVfDzCe7JA3PuD>?R6RD5_-0=2xjs}@((^YxtZteK#Y(89P=!|zo13?TL*
z_ii#Y$~2(-!vd(j*%j68X9QIXe}XZsohv~gEJnuy;rIeMh@ryo3+EDEZGaL%
z?9IGs4?XsAo?1jp3`GeVT{mKC8)vKm$??CqiS0f1?|Or|R)lF@=wvY!A`T+OL`!Lt64L2`AOgag7`NHtw|*dx^Vzap!e3d
z(7_L7&BIOSGI}kp!*%8!IJ;2JsAab0Q|PvlC#Am{yC#C;`I{$IxMUP0)72
z{*lYR*`n@mJS1=%x3T=N?&QfhOARf7xvB5C(Xf_Pk2!0;9XkGqTLiQCR`gGqLU1qO
zlDxq#reIZ=fxcjTT)|`f#)Z?)L$%3$Y3$>KZq|F^P4@R9e((x!L{+uqY}TZZ4tF
zpX&O(mRFoW0pHS=ow2ZGS(OV}BcD|Y=j9)`cAXg&
z1!O^r^6q$3KOuLSt_~fG-itBT`=c)Ns@YjH%adymKR{iq1u8!5h05?d`YN8~@HjT_
z$Gjit`PTCoOfO>r{-@GFPnL4E8sB3*Ho)xk_au)}ll$Sf&reWl}Y0!_n2^bA=^`EwlW_R;NnN)%9^AYIw=?ZB9D?W?u6|>
z+cP@t0|fDgg=w-0uP}%1Vl#Uea8K$OHSOpTW1bIqh}Fjx@L6arH^&d_8xv2QYCfP3
zk$P}Sb%@G2{}Z>HTVDRsyD@}(iH(-*Y`kcv@t;B49zo(6eGcJDUc>g>Rw`g(-I}W}
z^~QnKaJ`9=(wIg_t+5IC$yt<;E-9qg()#*K%qvHF4#o-xf%?%xUcVy_&xe
z@-mN~8Svr$1ix&k#3jXGe|mF(rij24Py1UpaJl&L7@95vc0&BX(bbo#m(QAjhQYM?
zN2z;}4f_XfM4-A$B)eRS@6?Y_yz3yrI9jgVLjsLvB`+%!{F8aJ-rI_=KJl*ce|Ek(
zCp9L0SF5;wOq6SBl#qFWaMN7nZNau~9-|JJ$nOID!?!9<>TE@@88Vk@yj#*}^myOKC3aKX0=NBN`)j
zbw%uK3cvK+FFK@K%Hm0FAXlLpBJ>KuD~a^JUSjGZ>ci>8_h?WaBizEvkX)5yt0+zW
z`pxL}XRP9C^}Dg{&r=l>j)0&9f~D!+>iW_6kummkVh&hq%25B2q{c9}U;9w79t
z^Cuq)3JIrCY5(2Jwq0{-b+TahR)n9IvnUv)8uOvM5qRv7jzE3
z?%pv!`C?6N;=2(eWZnUZhN*Xo+8Vd+%WJDm{7>0X-&y+A5K*f&^?%!a3y{!7u0?yQ+)?V#)D0F_gttV@(a^x-!jGsI9^NBBEn
zbAAs&1LrNu&gQN(hc{O4eP-0KsxS7l@EU=+NVo^%az+voy!kH6sTvG!Iiq`b^13d|fEORZI|Uc_
zXKzyhaqErEvfzTQq$bTn(0Kw)>2=OinI(Ud82lVKS_94(!^Y;(#myuV&cqd*Xnue+
z{~;8JP)j1%CBAHc>T#}^b;pyK5oBPA3v7x*B+)wkFqzWq>ol|5bJ
zy_8Y*N#hv*1Yi%$n9q_Pod&33o%|F@29tOpDZh>k656Hg-QhBF7lp7*p#-f-qeBKXu|zWFj_?
z2tQk{Ve9+-5et8_^j@;&?QiSve
zf0a&skfF}{r26RpSJa*
z)ryIFsg<($kr^#g%rl>*-O`BB9a6^A6a!y#9I}9U&_yRe(^to$AU(U
zJfb|vCY2&-gig3(gIIj`9VRVtqD_rL+gN5?17f*xCtUWFl3h)0UiNATKe**;k!LL@
zb)`o{A{dSB?@}rk0|%~IA@KQt#^nMH=lfZ=!Nk7>4K49_s|c62#eyoU11mlL<8
zeSZ-x>m6}GqLSOqI>QI^WUZ>+@h+&IT6OY*;=44l*ze<4(g+&{4_Mb+{$-
zM8HAs|J$AE;M}a4AMKh16nTqUWI~%^*Q$uwLAAet$A-pF?&&3okV&!P0CktI8
z@pOk~YQnoxn}m)z?CF3%`U~Ha`Tv_qNGwcZ~2e_^fpdo>h9d_W*FIAS(fQh
z6F6@^E?>=w4^OS1@&ovdG;z9QSu}3K;X9)OOt^HsXGc1X(wJJi7Mh;lA1q)$H_r0R
zb~e>nqxFGNhD)p<+-gEW4#ZKRRuwCjo?ZjiC*HB?HxfSbJT5^dcN+(e6pv&E6WjI2
zh1nl=qsSRXNh%ReZ+dVt^1iJ8X|!@NTqoL#!U_B=;9yr8cV{#CFO4vmUj&(Wv~<6=
zHd{guA70VvDz!&ysGueq+~uJ7yGyVag|J~r6@bX44ES4gOs?G59b%CfHD^4eq_8D-tyC&
zl2irPB0xlx8i8u5;%7S7_0R!Ysb>>wExrdBmTp=1&ssn5j8w^!T(L#Z`@1O6
z5?3RiT2~>0!BVKak!aL}+&MBymj|_oj`U1z+JOjS9KDI-95qx_Wa)Ictc(4gec)nE
zP{U56ID-bVp?h_+=4-?SH2rQYM|yWf#bKgUFI8LLxt!g{*-x0&DF-!PIIiTc+0
z;CF6h`-I_jTuc(^I}cin05WXLmaUXVrrMi=^}FxV^)&=7uD)0YtA5s{W=4AB5o%IN
zlVtuIez}&hhtGD?MOj=Ig@3hX>woP)=AX4(zpHL-85h*@nv6Q;wxRRJ?|$~ZgMI@H
zGZz!kNtXiCQsP4|KOW
z`oJfD?=7SD@c3z|`y)muJri69?fEs2$Qy_B#SHxdkXxO|2uUqjZ<+>3hi3?s9%Ogm
z=H-rb{bTcSx4?gzFnc03ELUSFPbTZ2vK(Eij3opn
z-e%YONckI~j(37CxMQ)K?~84?NuY?mgjj9`-j*TvR&47G(>5kdVdNjtiXg4ohXYr*
z=kCRVCLhEw6FLzkrMxh0VkmCCNdG?YWIT;qWjx(5`mTa{tl5h`ah+NFiPR2SLe-dgpjh__M&UPL(un`5eg3KJcVD1@A2y7%3jN*5i^Zjva%L
zVUv}KkMbk+8!ybn^NEJnsl_Js_z$H{2y>lp&xP+O)QJbx(!R|hS%5sR^s7b-_QhQ6
zM7|l?ePvq6Fq-kK$8GXRQ>L2ecnM#2Ehq?rF;7tvu2o?Q9(+)5$#1US-5V4DZ!NAl
zEO}ro{V~Bhr*CJ`&Xl~3#Fl#SnAe%hOGR`F9c@{ou_5#A=Azvc^=Vddf?Zp?XQeyc
z0=ZFb<(FvGzXKbA!fdr1G;}>a-D?bMm6R%vSlJ4wFF8Wze`sI+{x#N$*+=gFM&F&)
zf`Y$VtpK|0nE`x!O~5;b@0IAHem>*9cUl^lQ(M8jQK*&J&bc^)%bSE>i&`VNdER>d
zBjq1!Tw}Ii~5Dn$TjU2Qp6AFe>_K
z|Hn&MXy0E0r@w_Rih!<4p^xt?0-5mYbHRmRi_f$gh7Kerz1?C4GKE|OW#5t*6y>dk
zKp7Ai{S+e5Fl-dX^Hv9H0(pw!O0&d7tusYaKZl4~JIQJ?(+aO;wdBizpb=L|u8Q&x
z8bF>7(UK8eb*m8nq`1+u@#<Sx
z&ibvQe9XE%|8N$sfAl{=JF{BEM13pr>;T&f@)!*Ch%3T+<7D2E2LHMxfDu!CftTO0
z(!Bo^xj2QsC>Qc1yh#uaE$qm9_I>84NwO>X=YV+k9C_nV?hWt8VR_jCu!Zuva2xgs
z-A8%+biIGwJ_{N|n-H+jlEKtB;@lmJ;mbXPq8o~azR@H;g~F!~vXj9~kyHi&VB6R@
z0v1$Z7gM^8DKvrx*atV}Dc@kSCeZ&m>vPD3p{j3k=tF^8D0cC%(O!UnBK63
z&M6co7fh#(W9YpStm|p<`!YO{*yqWX%~MISyq&l>LPhysd2R4*jVhV(uybD)wIfkM
zH96E-Bv*($>^+1LG{IWIj>TMcV7`#4ue1-08UK@HD@HI#6z2614PXNH$#ughIq@+(
zcu^hboe|3CfBQ;+X-}BYs#eHEV3bKvt?w?$Pp2tQHbAtK6qgjo6Z1nll<)o=kWnudml)=1jt!+6nv-SE_S`;2P5$BMtQeZpIvY>N{Z
zxp)$lWVR1qk9x}P^+^n+8zB1hjcM!s=-IA9I0<|_rQ0hqn1K0@e%p+y-TnR`OEXUd
zLZAGObz}mBS&p;lPomvwb}F
z9$Q`iZ}AQzG<>?_xA3`KLU3OY&7M|}`UubS%(~ji@1K7@?H}F~Dx<_psvA1%w82O+
zI{=J4i^|rO6G&C$*QCkCui!4wrz0f}$a>TPWKV
z$L-?roO64u5{K1{$Q2)AitN|55V&Gwbg<}R%4aUgA<~#j=hyO`#AsC*Qo(>de`hHz
zA<|xp+4jDfwyu&w8Wv;jV79^)2M7pQOs!)U&;p*ZPsUL4$$z82pb+ZS64w0@hA^`0
zN&gk3%p;O(FW@g3w_}%hqHJrwz>79Ghvz?B2?yqz?KG|-XLj-e!y?tI;0ob}lPhWF
zzN}>%XJ0ci(4Q80+-Bv?F-_S06nWw0SaXgnZf!_z#v)hh8_{8is;POqJRxZvkBE<4
zkBD*ZTp;BzGRbsyO(Vh+e6VAazg+-{iB^7GPbi?PlUVTgHzNdJ1O5dI7|5tLTov--
zY~?43v8RJ}TWXsbXq)K8A)R~E4B_}+&8Qx@nsaJqX@R@!qum7JxCp}
z8gkn5qRT8`+{l5+s>%|mJ%}pcKMwmd5Kmp?&x_W`)=GEb^{h3~8
zEP(J6#uP1usc9Cubifx%dFiE8hN!;$Wab$I6c|l++I-{2S1Sk)@%@CF>r0Ez_j%k0
zZwT8Vp}|bE0owGL;0ZLRqi1RF`z9rXj84^Ja
z6o@^VuhinJzVID=`lR!KI=6Ui@w~V3opv1mk5!GaqJ+Vps3Jn9eBK`xLXmq!{
ztugiJ-p)*MDBr6fT@ooI7VbmYI&@9KGo=Po&A1Heu1d!W*nkJjEE%5?dO=8YES
z?{={8W)3}?M>J!t>c(Y+46MD);qlRM5WMRxt(WflWH{G7yIl~H7#q%!UZTGPbAf19
zbWS8{a^Fx1@wI|ePM;t$N#@(bW;6O45}{84ClbUSp>L#q@b<->oOIuXsQy*}C1@4c
z&djF3kQfMFM}(Kwt*$l6S^%%StEbeg$d>*`(S%!dba_03*VW2-P<}6}7&miD2O#66hxK
z`8V8zyPVqdZkz(cS-HKLvo+s+P0hhg
z-H5(>r-w31?%64O!L;Y?XpZ9gMn+zSxbW7d6=~R|6Tc6Wo)TAUG@9R>Wz?^eeE3Ni
zdxWhrd1ywSyIZZ|IWZuF|L*tXGfQ=B{U#e&$f1}Alrl0$UhhetPl(7QCbKNTqE(I)
zYsbp$_{-(~DA3T$W--rkS3KUd%E{!dgn{^z93qEd=YW(y)z!ityo-YcGcIkh)dxVt
zx?657w^}QTjYW6MzuT=^>j7rL&~wvnF%4uf(BYprXUm#@>||)HCvo5!%_*U7@7n4^
z!2vCZ9#(?Zm0`a&+3eE&m}ZlB9vGe~*w(i1iuHmWu6&n&!er^y04q3>MfCRCqku&#
zR*xzs#(S<_E{Ot25XQi;s$D<*l&>hRzJ%0)$v}M=2zlAa>@FIfffY$63l57Z_
zv*I@To8@CKC9A@!J;eD9KfXv7X&d*HEWKUD?pz>1!nA|HQT9nrxWy$@4K!hPkG
z9EGd(leH5sKOv>k5djZf#Wp?o?RwpDJ&Hjm1v80dC2Bg-cF2ep4a9+l1JQoh#4?SOSc?FI*I
zByAJX4s#1adq4CaG@U8Y_9<9L2&g$6PJX+hV?Q@^!l_gGya(agFuj)Lpv;K>?NqAX
zlGmzB#+d!&go278OPK$G$=}^Z_K&E07@;O^?lW~p1VyFWu(MT9$(cJ72?=ILDabSi
z4Kcvf@3J&T%{i%s{%rOM&IQx8*Gi4r1bQXTF~LEu`VZ2nRMKk7mj{-@pWfQ*Pdi&7
z@@&qNmG4Alz{t_*#x}y{RP95r@Ia$G-Z{^T7sg<6>cDklgsLDritqasQ`vFVpYQGX
zzR(G_jKIfZLfN#Kaf?nVW!-+?Ve5^9VI(*e_?dN-z;3ZPtK}syZy;oPT_dC2x8&`D
zN2pgm-3Arr@_Um0XO^&VwZ@#R~?+ZPyuVdIIw
zJJ0NBpzym?_26teZb$c_*pn?XyWh1k#U$`()Wa-YC}nB=$WwTAAoQsadfeCDI)ypO
z`{A>z0Z)r)ftUv@r9*RDtF^u!9LR2>+mzPoX1Va`kqq}3Yipfqz8wlZw(L|$6U^^K
z_V-pbs9&ux+ZtO(k6IYq3)@#-qgz3?hkx3b9A4yb*AKrG!8)1Qf!{!Vt;eb!L}7NY
zBPuo+Bo*dlgg^v8nH(8qL8r08Dka5DUk;F{_E<<2{|ZpmN2N_Rz`5Vz%$^0g1QaxJ
z2Y^FdIX~)<^LbG*42cH`v*+W+yri}3?HHO$-v!aL6f23M?i!|}YKV)8ya9ZdC5}q8
zM=}A5y?+OgBya})tKw$h=>s|gOzxR2Rb6fgcAuBluHRfjzB
zFVRbck{>9SXJG`VxGY@%@7~3M!o5>PqRCsF)0es>|PM8IpJE
z^b#6+hFAd;0sW3)LNgeU?txoCSZzGv3hGj`)#Q)L8Bw2(Sy12hAOn9a
zi?yq8#S_i8xkSxJhQC%nR+!A%Q8;99WYE%(#u0ys7?kRI;(c{cPwIEC1pOY!;C9wfm%3Yv!hzdJgA!@uXeqY#PaAb)2t-pKU<3Rj?I>(v+9uf
z2V%0BS2NsCrC}A~@)AP)*#~ZXxQUU_MM1`s*!BqPA*g{bK_*?M=NQb4zc7d@a%pvu+L0D&
zNEb#nc)3YtUls^fS+n8IyPVJEh_}5-{`(*S@6*n>3&SMJ6;h&9z$E_ZGV1sPRP
J1@Kew{{RlKZm|FW

literal 0
HcmV?d00001

diff --git a/content/images/structuremap-logo-231x231.png b/content/images/structuremap-logo-231x231.png
new file mode 100644
index 0000000000000000000000000000000000000000..4e5f3bb81e9158efab73ad84d91c0cf06f1b4fb4
GIT binary patch
literal 3970
zcmbW4cQ_kv*T-Xz7`3TgN~sz(YDR4$wkn}Ev40Yj*j2PfwPF+0jHq3sq_mW@W{Rq!
z=s>JW&DN?np5OC4@9*FDy|3$>@8{h2Ip;d}b>08mDVF9&%#0Tq0RRBAiLt&lS&8RH
zPet|<(#`Au07Z!<#MXcuzKREs(nX2Myj$s_AX9e;;preNi!pdc%NN&feQFL5GCM)HO#on=HF{3`X;o42E483W46Js(zfoV^Kc
z`AFL93gTsFJbr};NiAHg^{R?BU2pNbz{xEu#(B?Oy`q24LH|nQ#D<)jw!V@OG$5is
z#{mSkDZ-62MR$ovT+IsB4YIusae|Q^U8)^fnt1B6lq^Cesz3o`1Kw?p&BLOa`rA^i
zxtXbe@Y=b1!roCS<57Yg0T*eF{3DFmY!raBAZK7?$KloG9r9TEq1NU$0BRf;k($Vb
z)1Z!p603nC8so8CI1y+yI5XfHX$|`HfVc-5kN>sbd%7C8?+nBP8w>C`;rrlBTj3hw
z-o3c51DpMk*jVz5urSfrv5lbE{FK!AT?O!VoBq;1@5HUli)+E@TmrC!?ZoeY{PGgK
zl0EQek?o%=dhkeu4Xd{Mm1r}H?~7HIs=@2oHt+c3nkTBt1944(8@8ZhQu{V4>M-8-
zo$#v!*0z5_N>n*{6tKWO;#(9}2=^G9n
z`RUM04p+Mbs&vaHI?;MKI~jn|*M^EqjKf%0?>tuvR&E44V}HF#$Dg#+)V;sa#$UdN
z`ZKcn2;8tW)k5F)T6wkWfC-J~>t?F{C>~{tb6rsGSSach?9$OA30+HAJMz4L#0eR*
zyba*!53OM2omOhS63?*V`Ft%GvxRd_R??wL_wvc4vfMREh~$ZPob{Ws^C=g~N0s$b
z$eW^SpmXl;M#CwXd|K`TzOtr5R`cO8V%@lu()mXfxwRAA$
zd#YV}mOaL3Has@*zsMz~kzk&9(0%!JX
znHpPzuTN}#ipJyghi>;MYW(&(qW$5EoB+WkV!j&Ib}-N_cG9~-ytrM_#jvr)`)im5
zys+hvz&zcgu}0G8dDs|{0Qj&j?f{JUm-fmqBv4QX7W&Yy#3w@($}&$@xaqR57dX1A
zrB
zq8F@Yqh*u0Kz*a(r2;0+5Fm?Duo=0+V}5d*e>aH7VMHQ)gErB@i`Pb7U}5WKQ>ZtB
zbxVidF_UNpy;CRfNhK?4TcGF#hN-^bbB9Iqy<&n$7H(hTKsC^huoU};#y=z4-7{-2
zr*yHOzXyrf$UlI%g>Gz+ehxiyAw4#n@j@)S#GRe;f5DR$V@7+TDz$BR737ANT?&MU
zI}AS`6tKs!YfsZMCQ|?gdP1K01UpdC;!gR#avgfz_pDlZWmSH-Mo1})+iqRq(Z={?
zL_kAULt4Bwo7KiAi;mK(wK2Zy&kKjO!pAFNDm+nt46;h*1^(=LYj>_${BR?K1W^hZtLF(=Xjp5W)>N#_%{xk
z#r+4@%;M~JPXkx~br;b2T~_`V|2=9MgN08YN8!&C)y1I4r+-3m+QS+IV*4YJj2)n)
zZlo?ta!TqmaHP`%@VAC_XI?`(v>2myIhp2M37SPu(x8t=;rT-<)8W#I;%cN&2BXK
z&+RH(H1hG#BSK0i-F(rqTP}Ecq>%*1&|%~1+y#m0@Y-)B(br))wIzm1(xAz4DoiR?
z?r}+C|EBm5Wa=ZXL(jdPeVIZo*|f4)AS9?2uK*9j8R0okTZ`HEU8Nu5V6Ubzy{9zP)GWd9~i`I$fO3KodM274R%@!e|a+b9NnVM#s|&o^oX
z_N9w=;*-*xYIK={_`RF=wnS6m3nDuCm2}5H6hDau3`aKMhZLjl%E!;FbNA1jfnuz!
z%G9yCQt)5idS%JZl-ZukeB4lBJwYAXwMx&j57?c_K>a=$$*rq^=bOP&#`Of$FilZl
zDGNiU9N|UF`)q5V%zND42+H79am`r7oo{G4M;LQTmTot5;_iy%w_+xVWbrYf;I14s
zD|m>W&&&N8
zqx}<4^Sf9ucz%hX{h9zTN!gHi7XYj)qIRUypot6H13S@CwKlz0w|^QoYRH)-ZEHVG
zUCUuV&D3N*AMa+ZnfDRv0T6C7zedt%HPnHm@`H|9UW@b{vrK>{l2p@8;BR5V47~cG
z!X}@10#s?-5N^_oJk;sczk8lG5%}+;a)CC7AUVsT-=M~(zZU&I5EVbd8g<(;NOQZY
zVTE@(BdcSDFQ3hgLbds^j%Y`(MG(3%>_?ve9bZC+RLq=9U%qB-^ld8LuZvR`h#KR>
zecRfOlX|N|(`q?4h|r0KR6fUIbc)9}A*=K(16A{rw42?k+pNN2OVsjW>Ilkw
z=s)ZzWGH`@9RE|#85%;FUr5$c0V3Ak(OI9*-{nLors?~Prw{S?kDrqo35&_y;H*367HL+IT
zql{;8x87`9C^pB?t`pRrfHAlnsL8LpS_jJl5nr`DT2M!0@KJqTo0~JMKy_yJ}?Rb_(8q#r+7^vq%
zpSOgfx+;2bBtt6owiXk|mT~NS*n?yVCx7SO2W$>#KTFQtTnz=KrLGMmD19L$Gv|I9
z=bITe#1{}lnu#EMGX|y<@{#H8i);h*5y)ftz(GC$GmAB?&>b|t#v#RE1BVQ89eHCVMdC-G
zypei&aIxx}=nB+vV#ldwDMtnxnb$de0a80QAZj8t`S3O|y)MgdmJc-!h;8ClZBEte
zal7S5Ul%j{YTvy|<|55i)&crQj0+s&UuX!rX}yNcZ99-m10RLfcmzdyfQhYL7SBb(
ztsxh%W9ntg%RV~}4<9^=`r*UPPU9xA)+-KnVn!zBNwNZeDWn?c(11bsgb}sc1^n?v
z_^+&==GO7(=BMcTRdJq&inPIgNbUQF%7a69bzo!0Kap1`dggNzyttjYcB1_+5cM)c
z6#GNGBtE6{x~uTGTpe{4vWo0A`&Mmn7QE^Oj6&W`#7n-j1`Am+gz&~Ho4&&?UkVXO
zLIFQCc)HtOh)K3BlvwV+R<7;=#+Rep2aDN+fx#M&zi9uS9_YU=Z>}ekwm%P1%BlHQ
z3~ZL3mclxkiVDPz+qr=VYEgqIk+Z5MbTGAZ?>6C@X;1M4bK8l(Zt?7NR;JY=4CBWv
zIsH6FQuHMp`YbeN+S9$Ht(TH&|B6bHuB^CYtf37DQ7MOjC=YYx(_EbWSL!
z3&=y7)bn{O(ZE7yWp}OZR7OzI_fazCrno0I-}O`0lMmY~o@11XBf#13Qzabd#V0Tv
zxP43UA)sNK0*1E$jULUgFs}tW0bmSv6^T&knS1<79bE?ih>yfqg^Xt^9vtzV0V2=nvga82Gk+Kr>B>;fY^Y@L9
z^}yV+T7^6SOD#2Bg$GFF_x0NY1^{?LxPLzYfX(;JdmmWkISBx=A$zfmME*_x&OfaC
zam@c(S@z;sH=}4CY69QpKX8_ZVlS5IVf~K_gO(HHF+H}J9_|av2NIK-mB71>5a*%%
zJA7z%~PuiUn8Z^_V{c
zj))e%VT7F&$!BYtE)V(`?Z*%P`%aIV>HX_(ZdK#EWE50(cg*!sr=rF~AS?%Jtw
zVCLX14pL2ac|r9EOU=Y?AI?e~(7YDKjKw0TBS_Tv4&(y^K4&K&@7Y#3xGo~Gb#wFlZ7<*l06>RQhRW&sV4#2Y
zIn@eK;FzldmoRq7o?_P64uI(;kEJ-X|7yQiz0t@H&UqOSiOkg8X;vmVpEm)g--khL
z_*OoTzYI1&>$DKA7KBz6RLqg2gTuU%e&fM;H0DYt9TYE2Uq`gwF-gZ9a2oZ_ZIVOW
zZ}i42MZBg4Ee_@alWZ@PgZ(-*3lgSujep@CN7^3DwJ9AQJbUfc)#r9A)NP<`GGIJ-
zFl7l@7;tW`ec#BaQ9yOf#P3o==hfx>u?ou`o-##@a6LMEa&PXw9RAT%aHQV7b+<}#
zg+J=CJ%OEPlA_Of>rVeSUlZ96&lLnU-mjQ7l(H3uOu=qM6fQMu#aai%kM+s6jp<|W
z=QIw#3^|0^iSJ1F-hUc$O~D(~sicSTGq^@sFu|17E#GZ0sriw~{z#R=05!fq(6J~PYP>fo-cbFqgFR;9yE*rllotP?P5Ir+wP
z>wzh_$4Uh=D4{4VP}W@1$5`!_@Nw%Ud%28QHXmUu?zL`{XF+jBMAChNbq&b=x;&5K&rPKA+1!Eq_V3Is
zN|U$zVLIG^CQ`?G{y}vf$TWUOA!PbAAISlD9ob}Y+7bzfWvf0g?*U=Z5V|uwF{n^+
z1Q02kW9J>1`=aqN@c2rkzr2sT7j!;O#Y@JGwW`8pxEu@+k2eWN|vytFpT
z&1UnKLOASw1^Gt1sGJ-l&tj;;Mq>hZAVD)?6NMuYQJn2>Z<4U6Bk}t63=6c>*^!w%
zLk1%DEVYmy$5((p5nO+cTbkHsKb7fr^I}Q*LWv67mAlc1T!VZuLsb6%0CZ@zy_YWb=pym|bt!><+w
zY{V=~6MkH*1yv)JJD$cz3divo#OYCs?)}veV-etYgxoP9I?B;A%d*ssG(3MZy{h+=
zt~yM6eP;3SFj_A>dswh}oIsz!LFlNCUQv&&qufy%HN!w6SU}8tO2fG(fGJe&KGhsK
zG|ylKeH!GX^WIgT3{3bOLek`j4Q8fmt#yBrB1qKabo;yKD4r$GsJE>aw^U}(i_i+&
z8eo;kL%J^z^`QIN`)0)ts)AzyZbSVFN7y=vuSaOVr?=I1UQ_WUac2&W@2#ZBUR@SX
zB>NeB_Wml+;7QXF9mZI3Ta&Z)n|C;LLWnkTKh$hq2AS7en{6vlAYS+Zl*DbIwblUq
z9M}8D#v`cC#F2j2Z#&(hhgN&M)4r-7I=xGzSVgVG2L=U-^u}p4s@UP@&^uNM7UpY&
z(~PbC*bNh$VLx{y#5Eo9>bHAWJRB-F+|XVd=pE9q=RGYxgT~M3QJR!E`Q*O1XXaFJ
zE6r!x?1S25HmaYI2V1ihmb>R~%$t4CE}9*wiX3Hp}xD_Sb2ezD6qAH@)>Z@et18cJ6lyWpwRnHv0^dxhEk_{N|P%?|6Yt6
z+|)0eJ9ag{F8s-d=S~M^hJ!DULDtc~M8~dF9t=!9xO00SY5jBdW{WNq$DSt;8{UBl
z(U<90G-sj9WV8WS=fMLJd54X-RC&lFplHy8sUjfdKTH^)7N$UOH2}Vj$O9UNppIap
z_&l;!mtcGBhlU#<1e0hqJ@^Fv6BDxWU~B}yFJa5Qys}nzV`6UqNzw+_96U&K(L4cG
zciN(?M9b;HDe&GOVjE00|4k`T%#Ub!iz%?M@c{lX{r@<);75#T|10YM%kBIB1I9##
z@tl9t$s?){S9k-g77CqDsM^P#UnxG2xBuH@OYMvlBh)6M;Fwh;2go2sMt{;W{Hpmn~%{UVR^vnE%+>W6#v1G2HIou_<_&x
zA(&KcK!0oy#)qY7X-s$s&N#l*nPLZ~JvO61*c=0biLke-27p3gb%KTfcn5g??>xVN
zj>J@j4-s^V1r4QgX66okOqdWotDbk_JUZaR3(%J9k?p>ePbMs0Kn)7idCK5UR`9s^
z1iG#5);5x~(_J#`&*UeTkFbwz`867n%Vf^8WakyNl2n(-Z->9uAKB_D
z4>69st{d27?^J72Jh=NaPyDn8_T_sg!ZiKeXq^+=UA$61+4
zU%@xV=J*5GgUw-a);SnSCt^o+3Ij#p3^n4hU9`Gaq_ec
z6`cXLp_kp7&h6WI$S0el3}S8nmaozjE1S884#Y8SNSav;#pm=u%MsYZg2>T!eK+Gr
zx`@M-0o^x{a>GkQbdQnMp;_zd1P%H1&E!(2eW+gGxt;5w60-cH$9_E1{Vmn;;*8O
zKoI@D!u8lP@xbV{ndsR~Pe~BxqoXq0PD!1&PgrZSlKgP@UyhXkS9eSyw)B-|Fc##UM)0
z8g3rM@^U7O0-v1$wzj$%00MTaMfC8TVB4a63@r{sLv-W>YeB8Q
zx6C+A$G9nwv{V^dwJZl7nb-VdI7tW96$!6=1GZdA>JeiS@G7Z~9!Qe9D{~E*rS?+8
zUDKZUl4szWPnIm=YY4*g({S3h?5y|d3bO7g2`|Pnfmn#6_B15gC6m7-nD}Sx8+$$o
z?Jv+BDLdt9*;Bu`wsR8lhw52|E=(zj$t0gBn;e7^aE06ah>N7)p(96%?KBX->WcsL
zvH7L>VuHl>pXe404o&XuS=sMV6-thF$2pC7PG0Q(tzL*Y#nM8bFi
z+BCo@GG%lAEDRrryTL6!kjc1_O7RSi!MR16#nt
zz5?gQE2YSt)*n}-vY>2et#*sRHwv0!A?_uGEY2Xe6zl5*9t}osEkB=IFU;jyonhKL
zvP#KI0!=309~w5UOZ=exi)B&&J8q8w0qgTQIpIT$H%g6q)g6a=80T(9Zyt}WLPdg<
zq3SG;hFOkd5D}4;Av%K*LL?PMuDxJw1ZhkezizdnHYbc0Pk(%}4=Zg?H9w3BD6Kla
zT6*+6AT;yBG>*$DabSYEprR!4J>aO(qg`!$RSY^wIsS{HrktI?cUDEbJ^jzeFj_1>
zpJlKhu+i5Cu@mVP7Fxm93
zaErJ#`$pJOK~JoI(??Ow;M4`0935+1KojdwopvH9WSKjERDqAQo6K6_?UT3jndsJY
z$8-{q;y(}P9oiB)YyDKPl&8t5qTc7iw6Z`QlVmVqNFB|f&}LonhJcuzl=VE>`LF1}
zqP5Q?T{+s?lk!mwT-W6^G&)Dg49F2ZlggwoI}9%-J=9gRlENO%t@?UTXt@@<$ITWm
zZ{zR{sJ3lsm|p&|7id$FHaKWb_4Hh8KuJ|SKXUGs8SsLl;h$?}n6zmhZ*SYbAx>v&
zIuo6EU|&5z(@NqdIui{d&+i?}y`8DA{GtxIdrQ6E?Z6jj-Jz2nMH-Ax|8hMjyl+p~
zsd(I=5jJb!Dap4Wi~b1peqq3SV1F}}y|1*A7{%A#(1T&Qtl}{xix!F5ZMPvhmp6ng
zH62Gw`5p4ty7Q>Q(1-iOa8T&%p)WrOb;nF$qz01Cc^>~NVt}es79SNver=`yeYW=E
z&S7xGYhw=LCnfnoFJjbijHVBDd*^U#uZdRVNgOq_9mj7kqG8QP79lOW$O+)MaaW@7A{8&zqaIOcs-@+1P8Ek4u=|)>rTu*9s4fqh7HdTb_KIe
zI3>bR)-(8tWA}@p!YpW1U9`z;qJ$&!*}*q)I@qA4{F_<$uNL8NgxS$J`0#C@F9bfT
zLp{^;I)Ce)z2C6}3idhsv7Gd$>^|eeriuvLSv*7NcPTz>k-r-y9k#G4#
zpE?gx&$q%%^i>~42YNb~b$ZYVdI>*fk7KVXqngME2KYyHd!NTgS>y(&G@~>G&Zc4*
ze%J@eqA$6A%%TZ8X@`4DZA%ouK6jd!$rdiB8Z9%dxpBp=x0ssW{4UR8yucUV
z?8(q^eMSnGICHWIgk4mZwhDc5#Nomqg;7e*PFaF11-ng>fNC&t7a&fa4Ma<(!MNo^
ze_@VS4a36$JbZk0z1-#R4&kmIxdFdLYlpQXVWd|mM(Hg&|C2mt^jP>m5?>pUFoOS{
z^`D1b|CihRbMHSU`_C-^#--Upyg(}i;|W~aZ&d7TOK$mpnQ#gIA5RD4i9!C0WNxEk
zS3Qh@g~8~te=f8k51yVP6kot%RH#6RX8ALX@8ATa
z)L+kK!be6%mW6RWiWpl8tmmU-y>_yGi!e6UkfDe5jvaKOP3I4@9s$WeeiyMFCu7Mi
z5kJvEm`)$+GLlffo$A)F-^eBz7zGJ070%j!RCXtU5j&1EwJgx5HY%zIqmSZczBJfN
z40b-{eb2nci}hBGu|b@vzGZ7FyTX)gk7lNb|ID^&cr0AA2VOX9gEx=+a#x&3w(2Fo
zZ3k{4!uSoli@{s4*8`g^SNOA>8G1;x2N2#zuXL8BM)3xz{+BeBgFepDXcS9=wV}G=0;O?Ln%Ag-A}(K_dEkM+!R)EnjkV
zJ0@xll?lpeyQB!(zf9~IDof;WiG9hj*U%g74LV8Da!)U!W#~J{olLLmwn$Nc30b^I
zr0`EJEaGEO=Ds?nQp?dPX04y`acW5inWh+ce^!!r;3<@niRDVt@P6O@LLo@d^0TNo
zYHX3pwn^xHT(
z?edOT=1W`sihe8@Vd9d0bZM>@{3dhGmDNN369X(y!AYriNqHzx
zK&tPPqOEOLsG4=sly5)t!+$Cx(~_ty&bhx%(#%S{=ts>Qa%{-$EqV=C=xPY5A=bxi
z{^8M7%W>NTDO_)(Vy>0@=aVi>MKs`Z(*2Bi)eilk(X64>&8qNirAbUo3Vn4W>E63O
zsR3WE9sCqdgU=GMlf1dLWY>>aC8RYyWfh+$8uur8b@ky!3-Rm;rlrIl1T~x+ObE^U
zD$touWJ+k$EgSFmox@ra1ayqFLwKL?(N$q9-W?oWiUej#irit6+qlS`Krq
z%f8~@7BEFzTscB}j
zVt=CP|Je3qGML5umEYo8zv5!@$k}%|bxi`pARv0=Buu$0FJ3EWOOSyHy%Yj7lnrI%Sxs6Q@H5
z9(0AG2ZSNM<3-Eb6NwxoMLTlLKt0$snsQ`)i`*
zrULlKThl34RgGQNbz;^@vn?>@a~T8U3&d4LIvQFjoC(4ADj>DU;iSnG5A!=iS+ivqL2xvY|qf{fT4)8kNML%?@j~K
zb&n}tZvUUGvTb7{eMaJKnWqF=d94GhI#AAm0!^F@D+7pqG$Sft4q148Z6w|uyEk4l
za}$!YWi$8g+el4?b9Mg`Xo@2{um1I;G~>>QJoc~N?Gb3nNSjVY
z{R3Z8j&@JAK9_HTa#LQO`cxhW5?@V=MO9WdxPHk&#
zN2mVX5RiQfpp07k@1m`(yIrgx1SG6y&V7zX77Ixw|9|^FpYusVPA>QR&b{ZI`+N7X
zw0yA9T+m)bdkt+en&2t6&qJG|qoebdt}c5wzJCQx#QHxv#-OE2Y)pPwFi8wcra6L-
z^D_#rzV0XZcfY65zP+xl?mh>1pZ0mnLSboW82ARx0%KE)&+)rOXu8^jHPdJ790;1?
z01f+Jfv)N;0JRZtj5;AivG?j$`oQ(#MM*!5IosMKa=WM}9@Ho}zYpT&d
z(9zj3Gx#Mqc}an=?Qr7jdvN@#CgyY5Er6Ju17KoiagmGyZ2()0G39?=oD%|YJ_eu)
zqg%}wd5_TBptU3n0>=s4(Ra2cqsPd^{QUNh3ZVE}Hyr=6k-!pT-sfFvfn)gUKVv?i
z?^hu3fw6(zv@7M6r8jypS+$VFg_*j8v8AD#L7&4pM%o`a*bLg{
zel}g+ohyN>sdn&ZPd?0+n1v~Lt!X-_4T
z$*JTT;Kvk#?u4b_=-~rN?;M1Gp1ubEbN)xjJuZjfSKa_FWmtnh88>3EjoZbxty20E
zrHqE=Ofj@(({Lr(2G-561RJqE%$X>G;Au|a=0*d@OjwCO8Lv+JoY+!YkXW8iB~=0y
zR}55qDe$B6L2q6dP!eyja~luzIDar3>j%14j;HY_^oYXVm(oW&c1hqK!Zu}y;T{@D
zg;1S2vqiA(ADyFuQ()AhXwVP+J8R@Dj>$M{XGJkO*6|=z|@*NMspU#+3LOGN1W8D{XZuC#~UU
zDyr_9Pb@!2#TCAR?OrAAQ_0mp
zrN{yO-x(2Dg_L${&6ZSl?81mX2HTFq`hK?kd5AOeVMU%9kCAD_xyN)=Ksps)lFfQE
zpEFeZR9u-WMzIW|*f+9C2%AuGmLFH_E{G~|#1nW6?SW51Ilh)Wec+~aD?0+Kd@Qn!
zXi5Sr6`yb3De`9`6jwA^kXX^AF0eslfrv_|sC+nQRj^eU*@|=Am_k1$Ye$!OAnffC
z1^(%8HuQZNeGKQUY8c}y8P;uCbVGBx_)$U<#1sUm3v9COgf03X>kC`Vz~V`e^J0p8
ziJw-0m07mp)@*S;!u3f|od}PK>l+oUX29IkQ#RP?BZCcNg!+;fm+wXVv;zD~rqKF+
z7RkmmLaOF$hm3)}*q9}rPy93m=0z7;QE{b*21`(QN&1E#eQFl*(+Y6oE}^?3i>^@0
zNMs*}#bGR!)Hh{`Jc*yCz@+1tT}!az1Ltf)`FUPk0W)&60^BSWJG5m>>XkA{A6W7k
z=W<5k4=H5IDntSUiaHdaMeL*UVg
z`9drz4h~FEX
zHb(!;yx5Wj`R0a72=
zD0b3rYR(Kx7RNB#PHfjRf06{2PIUkeXCdgjO#}8Txy)ohFf0SIlGSansEu
zZe2csvms#iLJ+z8fq{kX{}KtfzeMY2YREm8wl)y1A74kbC&sQGT?cD|ePANZ2l*Cj
z=+33P+oW{ePboIE`nt64CqaP{IFAAVBh%Jzg&*@!0C>?0Ol<6dy;25()H;lA*>{GC
zh3X3P#zchopFS5C{dI8S;yuX!whcb6{SMYf?*J21b0X1BdsMFSx%zpruTFZP8J~#+
zsM$h{dEbHH>z4SyVlN7ZHLXy}#2KyG_Oq0k_RqCt+bfhqH%`7m
zbS(n>sQqr#rju6s0LN(}aH9$?A#gBD{bPgsgekor$uC36^&ZH(*bK)};weCly5vR=
ztO`#8E=83wqX3U3fu1%!_lh??(3q+RifngKVhwP!f}?9JyWt%N1tzd|H04m%og-1+
z{Hv%v(AfwIWg!5c#SSXs-7iC3+S|5^W#_e816X5$k@1%FK!-|ZvfokS(`
z$mc(Ucfhl~=(~c&*42@13h@PKi0liiGA0r$=efgM3yq<7w*(Yf;$azCLDk|^2z0lE
zpD?<=D$|Debn9TGGyrzC5j)=4FTad%iYLgl9q{~`aL{G5_YE6()qHpOTaXC?JE#R*
z9X>Mim8@EKiDtLT
z#G7zI@k8Q#W0>wMf@^sj22EPYp#i|->g8cy3>kzGPFkwV((3_m{pcEix(LRuA6bL9
zK)k`2uirqf)9Uo#$DJO0g^WH#BK=U8o{hTn*$?|&mR|M)Gb00{OHWV>QRB;!>Tu_d
zwy1S+7Qte?UIqn7z}eXz^bO5V;CHTS33@V#xgyJc4;CrCEm*9eAP?W8F8%s+3$PX0
z!n_GIES-jhhpRp6(l#iPv;CjOJ!lr2oAG$zVef&3ho#+@mk$dVS5GuXH4hE$
z4U}p>gJeVh2fB3CT}^c95m_GM+BEzTa6DQ90>=yu+?**KjT+YxCbIot@dR9I$`npj
zLzmVbFsl0-aS?uB72ygH#FvH+m7vhU`cQX=TlUo~aW)78+lv;nXaP|=uo>&L^jo3kp-;vpZ4z9zW$d^nW$Hh
zY5yoewM!Y;tM^oMc6h+arzi5ZoowW+ejC`!(}5d)7z9c3bQamv@)Qm#P432x%)7}6
z-7~CBE#^9=b|0EMxOR=hWt*3)9au`n!u*LMXxJtMGIyKEQjfXxh_B$?{kiG}fW;-;eJ``@S0@&?9U~e~Pi07%<8ABaCy(||mzmAl>hvDEE+&K2x
z53u{V9A+#E0Rui&i9Tb03oLFSPIL0`?MT{lXvmFeTn=0J-IeoQK`D=TOoBl>6Uhi{
zDQl-fpaT!CrP^JEcO6$~(4jSMzLR?P7GJ>qkgBbLr>=A|uR+);w!Z#B^y6s=yxhsd
zr*m)7g<)+yoa*gp(R%ghS_0TtWFuC)6*}cxA!OFru5m*BBn>)aYGh)1mWXU+xB71W
z#C^=nhVFw6H^6C}ZyWkf*JSGQD8uR~*+=AL4r_DiwwLF)0@O#6s17cpHblYhh*?DS
z+pR%|Tzb6J<*v4mr*ea&n;iugL~UIYS6x;wMcSp*xQG3k8;wQMV=VlCj*o3
z-jA6J*!V{pbZDG|tJfWj;;-n&ovrZUa?kwELiz1zHe3XOxLI*+>n#8g0x|e87o9n@5Hq
icJAS$a+cbB6z@M$R8b1H?{9_b%TCJA20Ll_UP+LfXqODpT
zb*7yP;))A|-K{RI({^e*Z7nW1rDLt^0RhjP`=FDmc?d})&UnA?|Do|c&*PVK&Rx!Z
zmwHGV2c)PZIy`X5rWccau0;n!n
z2p2w#gw=BggUp@ZhS%s(E_SlVLe1lg#LZI{u7E$6T!8&w-h_i+)xbxmFG2L$P2dxt
zAfW#GFhF{o#iFjpPk$C#PAmgB69;f&X}dm-0XVlDO0p({pG-_1c(I*qj&gS4)h*R+
z1LLJzaQK^ggi}o`@1M0`yxamC@=k+1NJVU}awHrUYRhx|70`HW3BXANgg@`mr^{i}
z(ow)+vo7KF!8Y1-MjaYCVG87b-$X+>aN*`XB9NA(zYlB<=NfI(LCufLVSSgAHXc1C
z&N3Vn@uu2>ML_Zroi}W2p?rbxhqN7ea1;R{42wGWbq!>ntAwD?Cy31`M*;e+%w14@
zF((S(6zx6C!f=}r-p3v;KS<{5-}sl~-;!`*2GkL5L&i-aHn%wnP+u>Ju=-NY91O4f
z1Df@G7FwLFz3gi^^v}A^0ihQS9P=Wvxyez0f}Nc>l?9nEV{(pVhI4!=
z+$z&Rzuvy~aCfB(k6)?Xv>Wm(ni&BR@A(_{Xnw(JVsnZ^=+tBcFB}@;VtQ?KA80!r
zOF&o#g!$=6#!J9=cDjMLg;{M-TjC^2ELz1<^=}z4ax5JBww`#2MeiX=`VFlfSnXpX
zdC$YqDWh+1R5#_l;R~*OC)l14PIu{WD&~&lOyGRKXAblY^#Z(Yz10K8>}-xOp
zW2OqyCrCkrkm9EHgNocJ1ha%r+VzEtAUE}S=o3u$UI$PfRvC;s#}y_PrHhhEK$K7j
zB5f(SOwt0I?+U}hC&1eu8X5)E;2FRPUkbeWJK9_`K6}P0gOf;D6|QZEQ%K+t
znIWw#$DjGlyr|8@BBp)i^#V;ynAr8Y+-ysnrLNd
zt2wO9BG3`cK59w6P!wPI9{&9fd+2pN2dLJdT8y4^tIh%(3^%CLDNmU6!Sq}Q-Tnic
z0by97$0VZXv{??TG7uyb?i0lwmXXVa@y2Zq0i@MZ>{^{-aYLrMg~@a3GgYNOuTj#A
zQ+5G_VI@o`T8+I_8-wQ{oT6MRHcvt>cPJo)64%t;m0N^Ut5X%-SgZCY*V+jXOO#NM
zDoP@73N43KLeVZW90vgcpjfqf#gYbts-=!G=P1j~aBK%e27#DM5-j&tC=ymlMY(Qf
zIF18Uo1u)M2Z0vg+*+?jIOsX+%y4W61T2KI65+Hm!NG9bWrpKGK=nH1qDBjFs%g(r
zlZ0IOlg{6dTx%CV*jowWi&iiv_e`%3!q7KSS7c6j*%(n?5E=PNXg|60|eMxRqIr#=s9hc6S5i*T3*#VDlc-qy#R?4
zjoQulP%44@M2P^TKbGN~THAOwqWaO7O@qe0P?TYR);10Yq|6jX@FL
zXi&8=C1e~y7n^%4TLBq|QrL*+keq{`Sx(4_#d&7WaS$LNBV+@~ISih&jt;j2KcQ&!{;7Op5*h9l$_CeINk6&(_54|-DA90mwVFz4u0DI_7+FnNwnnR8X^Z`In3
zD53ZRaq1~R5cK#3y@fn*n>gNh1b;SJ%sI(r1ma$?w#3sKo4Am+O|o}9S`aMG>2y7a)dA$Jmm9xnV3;2a
zdNKgyo}#wLeYlVuE`b~AN*veRJ-1REsZ8^eQr5STl-TQASBX3H3z5RmFmDKuiGc0l
z2kfDdAX<9v4MYZ+NWtZy>Di@4&;$7bth1Mv7u<=ql`8
zjf-04>BeuJtM>@NB?=Nw1P<|>qaqtTheQU}
z=NlrX%z<~Y4!`&F>#+aA&#}`OYIZRSEK#;UDZhx==}K-J~e>DVc*a#
z91d_c7T|PDd-=y~6QNB5wYLCR&%O$nqlhOJ3YQ-8u>sCtj+0Z({FMf*&o|SR4Z22;
zI`mB)7_YQ~F1r|Hz5xVM9Exr}7+c?EE&gLWoZ}2dJp8whRz-lfD;G{J^@p|%>hrkp
zWki*BM>zc`ZQZCY>L28MX~M9_poNrsPB7KQmc#Cpap3Ikg=@we4+srkc-sJni#jlT
z{HqAYL~8Jin-?^=4TjBTU&ZT#Xg62L-ELRq&F{PnjNfiksRo|vC5O}q31DrDKrl~l(y*9?-Os8yXY93#3EqUu+$Yh&X
z0~hs9#6bLIe+j8$o#<>F{OP$cnBHGV>RKdGcUuj3U-4UV2$TunyX>eg)#hi8qc<<4
z+6ZW%%*U^B$FXnjzj@*7S{O8TBC)x}F@U1G2Pm=~P?{qEbvwkKeq0W^iBf>~tPioT
zk^({D$%VaL4Y3fq{Ophr>sFG^NqqsNLT*!;#_#y;chx1`P0*;~ruC|ldV{h)yblk?
z59vaZMw>2NP8B}qV<^f2NxEy@{HHsnLx{fwNJxIR#9Ij3U|x5+_X=`7cJI{&Wej>!
zQwfHdM96`+7Yt+U=Fg)|wZA*DnT%pt0mY_n-qJv^RXgJuxR^7G-j~x-u7PX&=E6qJ
za0v1ek(;)n#FUi{JtrD-S5u9S3^Yky-V0p$9GLxlnB{?@x0u-6!LZ}B2M3DgsYWCv
z_O6miU12~kPZ-o&2EI};uq1L5_HCPf~6UBB~LZ%uFWfb7xByO+E%niUEqXG7F(cnBK9R!-a
zmjzp|%dLikn-@rZ-qIQpWCg+0ByAfteY1J8Iynt(=79L^e+-}=P!q%)c>kWss%Ccu
znXGoYWdv94_K8wYnwJ4^MlD=<>@qL*NU&8qI}EBhjR*(JK9)Bx==_Y2YjX;DDR(Y+
z;Ger(S?#&y4gx5#cpu(io;@cO7Va-*u+9o
zsjLcdYsg5ZjXDG^UWT*njwT~R2n|kF;OvolC&uPH0x|yz^Cw-3`pz4g^
zIhb?m>zKRpa^YAXpz3r*6ei?Gi#u4+a}e6cH#>H)
zJ~DuumzVVUWmay&uAC{Xurz(loO2!#Ksb{AnbLd}3VQjh2I4tPdx9{ms^1AxP}u%|
z0j(_CE>8XREVmq7lFF~|TJxf=Ngrr2A!E*=$2qj;SkZ7G`oSGGwWSW4%@^Mv5Kc_D
z@)mvwP7}4jiHHTx6a#o@K5RX&9}Kq)K^Ea)&N)Lo$A)inC;!b4fjcn?oFZbtWttvv
zLj#D@za03W03rO%yahYE`!b8u2udvf%neu9Lj2sIx4#(VK2mV@^oRK)y`eHK7%;@{
zO312n)%s8+Wqo@VS24d3cm;xQ0C_b@3GO}tK*3WHTH@O4rUfzlpUdgUjz>A}4y>svUB
z#roHfu`j}!9S5=8as_h#UIm+vo`csHtpIna>~_b=3p_i*8P8^O{ypsZN%%tD(JsGG
z_mYsuZQPkKmYjfqifu2&97mm6Mwef%VcqPRumBjMcA9>Wy@}1KHriCU
zxbUx9^IEuOK$ssilxXho9wsl!PKh8ler{tqrmvesTK&H9GxBXRJ}ioM{gE$Du}f{<
z(?@RA!2(N%{5Aj@%en?=PwETg#;;HU%KG*cCg7TF#s44`%}xQ4>gVW5(}>Nrjyjqm
zTrL&0UfDbM{yQx&Strf>1GzER#y5i%TxaLYDO>lEjRc)O>>jLqhJ-x@q?dKn;U*ra
zFYrJkavV*k+fc6Tn+Kr*5_>$X6Do&%ONX&H$z$3`aH$32H{hU^>vA2h@9oIraiU0F
z{;=*P^X7$)jRe@;)1g&^Icm}{dP~Sjl$5f)4dObx)GS<;1qGLyG1r(6J0ide@Iki}
z{2c<-y@<^W6w8qZEIFalq^`WSRdWWxB|H+sRK5gS5K?X7Tl7g#qxuDto6e)2r0mxs
zanDZUd>7)82|tP07*qoM6N<$f=m`ex&QzG

literal 0
HcmV?d00001

diff --git a/content/images/structuremap-logo.ico b/content/images/structuremap-logo.ico
new file mode 100644
index 0000000000000000000000000000000000000000..0f2e36ff7ecaaaeeabe4d9fff7feb2e8c20c98ef
GIT binary patch
literal 41567
zcmeFZ1z1%}_b`6wEm2|L>jW8TQ^YYgWz7nptb+0E3~x&|$>HF!0F$W5(Xg^(cxL_?6TZ#IAs4Xy25>E{JnUUB4uw3zlJWDjA#DRjdJ~c|!m-yP)tf
zoCFW2Xh&HhFxdDQxFmP}@^LvC85v8}lZf59uIGTZnzSRk%=IhAIRm@88T|m2Nw&{1
zoFESacV%wG+M5?KJ2DdIC6CKVNJwZ4lLDr?DwFoFDoYqb<@b#7%dPCS2dSbEoAgl&
z*2l0>#`r0*CWKYT-^b5LLu}7DQ=<0c?h7;Y%ih#tO)qzU^CN3}OvT(t*g
z*)iPlv&skEvC0Fh>G-?G3!|de8zU0>rVd}SfN9VWA7+T}6Kj6rJqVA&BByO=_G|*Fo!GKUV^@|)2j6%|
zAGIDs>-=Wo#^V9NAbV(sgkMYi7&j#)F@14H==`U;^aCwrakDcD1{SwU768NS&j5{6
z;}`mf^-Q|xwLE(JvV6Vt-fio`allNQEBLtm$&-XkuXDmzhgHQwlVz&`t`e+c$C(M2x%(%;)c;0FWhO`fpmfA|edhtebmprt5oM@2#G+K<{oWu&yH1#E5*f@L`0
zmjA!_4%tZtFiV3OvY$r@w6TAY&VzMYVCMb{m~X2f9V>!a70f5Tt@w*~2CxpA0}^09
zw#n!u)U2`cE=fp()K);o{@yM=IgRf(_2BED5`~-yZ^QFsf8cd?7;sHRx*vq#`V-VQ
z1!!on%XT-f%-0q~11V9?02dp523U;=PE{qfpr?RW7XY}n0!L37hxkLVj{lqH-@P)N
zA`SXbl??2UR|2~u<-lCmGeCs@%(L%+zW>10R+Z`79W4j8KbHZAlhpvkI|c@-4mv)e
zr^T}`fJ+MiI5mPiv;lxYN(TTo*ZdyEzrLhI&pn6c$!gy#VC7R0us2o#7+shD2tuI#
z3+lT!>L3^6js5YeBlz`!VqoY^CO}F`m<&Qm$~!*-JUaov?JWR!v;%;IbrgW7|3St9ofaHiffP&Npo*^gX#VbKp(xa
z`!gOgOkf;veH3K8F$VD13TFN1
zM5Zl_@VE}5U+#|8(G-Xel)GcRfXb=E=e3S`VElm|Ao}I**vQ5Ju+2AX;4#i0JG>eC-R6hu{0+KS|%5ABOST
z4Z8=TU*>_8_bvUedib3Os4vJOkk`g-VNCxq{cFL{YCX}rTLUnGI$!jxKhlT3za0!t?IddBCiU+Ag@;3&}UQ7da^#_1%N+)oVOZ>&j+l}1hcbCtS-<|!MNrR`@8Sf(k$gN6|
z!Z!l}tMYZ=Rt*BU=$x{TflHwOR}9colZQP|2?7>A76XG#xqz;!+z1FyjgC#=Y@F41
zWP2g|@A)186g|=bGOIEqee@=hK4SU1Oc%AWL#^U*XkWGjxHJQR^PAu7HnWUYGl=ha
zP5mP)q>dJv3x^Zc;F?hc>Te|*jIM~>D$h`vV$04RHB0u+|70Oq)T
z0J1^f=F>3*
zcR>1%;JT?4TnboS!ry52!}!^Hfx^kkklI`n4{Uy}0Oos&0Ba+)C6G4j?>q`p^U6Ix
zt7h_+T-Ndnjqf19cz^c*+_%SlBg1#E^rYxkimEb)mozT}4ywdJwHG!}?Sr#h>W2L@
z9tfqliC(xENdQL5tZSfyAp0G{-#$=IM(r@4hHrmhirEF2KwZ;?FQvk?K7#v{?^9nG
zjIGQG1zF*S4%GQzmVvfltVt-w`|0#V4ANAb{n%{Up9Pz*yv6>Gv9K~*NfpPrI{vY!I^+nY;E1E{RJNoTbXusm|{r&@@@pp;L
zW9$@t_-ZTE7Ys2-Kr*zlBlRY1_pt>GC~|YZCw=EA>7!R$86uVeI#oA7!7c>2>>3L&@d?#|@Dx941MyJni?f|(g#nnV
zvI7zB#=vc3h20Z`Shhcc|GP5kyIV9w@^0Naadm(PxK_A>_S)k4BtXV^F7an=pW4H&
z8!5Bx47V15`}Hc&Z>a*pJk1V3_^4d(A+$v7IY;qBD2536W{wtG{|+ubF80%_o#l_d
z;@Sj#Jh-1V6yq!anSyl7!zgljA6l=E{YGf-0KL039|F`oQrjTRu|M{Aa$uY|LGbQl
zP3loR72+Gp>tK8liZP1vvu}b3PX8T}<9c*-^gJkze5?Zq7Zh8CzID`PA$>@L*w(>i|cja35f
zw{#&~sy}D>yBaKJI;y@|FowSNdp!FX7Xplzr-HG15E?pz!F@IEs55%K*jA
z@6>Jsr}*RnT&-Bc?=b)T1C0n5x8ZHcgQNKUF}+Q2Z@Ab~2=JU?S^=BV{Ji=1H7F=3
zDNhsqj?M#)aY5q{inA!o2|;HGLcg~N;JsoCSc9<}S1{HNWvf>+0Otj5fasDp7<1TL
zKLy6PzQ_L4FX{8#EL-hmkAQ8E4%FA9ZBGEbtMZV(oPXNt#}%v$G~`nixskx;P#FN7
zQ_OZ30&c(cBeX|{Y!8&6rvoz!!#0=vHGu1aCcwqU3D2if|n7%LV-ntXds*a
zH34BTg6FqUrxJ`&fJb0Xbz)dyfv>KgzPAOOj#>to;2Zx)h9XDI*U9GSzYrrzoB2@YhFt;0S}MJ8p>v4;
zG5?TGk8pYZI{%60zpeMs9f9v;xcB>5`U@HUZ{i>7q(8~C8${Y7+{+5F0hTx?EFr5A8^vAJu`gkmT
z(+~f<`7gGHQG#}25#s-Mo7enj&i_^NM;VxY?+4n@Wi<%u{{;V_{a=K5Z}10gwmVkK
zzqtMJ8%@w3?9%W3Kyr6i89c*#1;x;7d_ep8AF%&#f(VarRs6*M1FF4oV%b7a7ifuO!P#vAbS^n%J?@G-^u`;sZm-LAMKyG
zB;Ub7&kS5g$4@&5q#^{2J>FE1FT9H
z0T=MDi!-=)Hp==0P;rSuz87>C<8Kpn=!`65%DFWUDYd^x{0{V3pMKb{V
zg&WZR)Anx>eGkA$bBc8IWm*X6zm**AXD8YV0DDtS2-m&eLC?|(T-<|vMd;k~c>fRG
zSuxKa25{;57H9%SE5P$oFfaWygZram@Jwxz;Or&9Fsbc3e-66;bGv36AZ6lS1Zn<$
z`}BK8fAochf|8IE?*-n6sRCAyeNpg^4RqH>L0SL_wt-^9o{H{iM`xVJydOUy8CWmq
z0;lf00hr^F;CbuL&vPso>-PKr(2J>kr-x%)kS`}{>wxR;cb<;%Ku?H&af{G@!awN$(hkml__6<+8RG%riU+d{DmfX;tM{j=q_|`3mP-W{6nz}XK-w?3CjQ$
zQb!>*knGSeL+J(M}H#klyF27iv2*@p>hS_
zkktf8G{OMJn7s+|kXaEJct&~B_apw#GHKWXXl5|
z(4aHr^%7^aU-d%jdu!9dm`UYP++_RnYarq7Z7}|W0iDYn$HNH0_aty0Z-|=)
z0D^ih041*?Ky*3qH~$g3?-aE%Oc5}{`S)5of-pVBa%P!d*98#1=?}1+mjpEUQGrr-
zoMRtk^B>5d%t%8rW}&A7c-k8Pm*vibyu+Z_73mLnVFAma`6WkURqDzZi#UY*-y{DK
zlz}dKb(B0{_LuyqG;`GQuxl{DM-2ufo1h%j`rsTueo+PJ&s2kJGU!Kb7X4yBWLTnv
zgzKULZYn6CKZ0f&C2%f(H>chIY+L_R{6lorWQd0B((nBMUz?)6JNMn0
z|KITs;W`>ikPLsYOMjdX|4IJ8li|p={w4!s^x8a4==9g$&HM`g5U#KN@E0=tr};mU
z;Vw9q;NOm=EdY{%Hf&x3s{d8~A=s}n{BbP(zCQe~;2)w(AHHY=j-}nN^8t*Ng7aaX
zAbd}x-W^s1*}Px%AHUA&Kg!?+lYi}w?b8U}532@!b8rp$NA@4$^RE(3_<}BUcNU64
z9L)z%2Ab&InG_$sv8T2$Aj=9J@*m|ivSlh*&YcDX7(!tza2|Z-#xp74QL9X0TSF4
zfUMAIK$HXLkQ57M^((mk3CvMH#O&=**;WB3+0Fwx4;qi|5kdQA)2CwqqnHMCUSj?$
zI3XEoym3|wop1qOCR`xQ+ZGsqn-460d_*;_X3L3YU3c%XhtO0O)?~@$WjeK;Ll*ltYMz9rDfp7>D>L
z?EVP$1P!<3;_+`zj{TQo|4Z1=3-XzMDINeJr#VI5Iq~kv5%0(T3-pA}GGl}6AY5J$
z+lE3#C%s_W0px9j)m?8fbx=-`p^j{79R|Egmz<)LHUk&_M1OL^)
z|C1UBQ&&|Wz@>tIvr2GD@dCJ?hK{UJVAz=8L+?%=feP!`GVuz*hqn?a*@`vJr9JhMVe}B(V#>%o5bAGEPsWktEZ>uE3sElqKY9_
zChPiQa@F74-`wa#7mN#|!k?w?%bp_*vl9wNq?-jM4_*T5N0jntacPQs3!w{h*e@E>
z=Nt(60xff;?a3TaS5J)bFbF;Mm$uVZ@uxmHAv5OdKMI4Ruv~b6+ScmBw|aBT(&*g1
zU?*jDKWa}uF@JmTn%;t6z6>s`mw7>u2w&lnJ;t3(s`NPB!k(D!be5=Va*5TprUG+w
z4jLyhkQWRJ(>@!d#l*qQ>RkN+qSu7%j8$YtGG3&sxD07{Jd_<-Jqzqip0LDcg1G3Y
zS#sW5*W#|aUm|h;Y`5-St+WnP6-2oX18}&oN~yD8mO@V|R2pdFHZAI?{j2@r$n0|l
zNcX$n7@rdG*2J7LXO0=T#gJ*BtQ!@QOh;e-neGhNv&=$Q^6rq77R#kiOipCA3-$gJ
zLv<~FLkop%a%%qMnvspb|Q`OvUSi8S+)x`%!Q!}_Nato0BPMrKLU!T6!ODMC|#(=6?0Sck3SQk
z?%zhV5M9c?F&&jHa@CQ84X@FA^GuLIDpDGAS&TC7nxBDuR{g+UW)U6>cU6ze1Rv+E4T2GwOkO%xtc_>@aLI~3dyVlU+
zlo~jK&I48%O>+eDcRu!h=tlFLedYR~`;qH)jk&csvU)bx
z@8m_(<|=|b+PK6EJ0m>t&l4n)Z>{C5B-Uu$u-=I6YE5^&Qa6$9S|hFq=R$-CE{i-D
z-=nT2igOmFE=2zm&x1Ai1DJk5kew<@DH%70K?m)dXB*93
z%C(jE%rC!XWZIeiJb_ht!a1$2a~C=5Bp~2qbVgsolXAd_d)GsO(cRmhv2{_8VMpK=
z+r2JPjQ%2kW>rYK@lE2ZIU%)bMgD0$C67#vyw%SWp{PFME!%!US*DM~H^iw#tf**5
zUIm^}f)Cvr6*oHRAgAoEjM8<&tfIx){P4OzMM9LvUZa}%2NNlY*e}m!w|Jl1Kb3Hq
zb!5Pfl&9?oQa=^jlO#Fn5of)WDlq9zzIxTjJ#>9#fQTP{K+uY*^T_wW)@g>xH+#gJ
z&$!+3$^04u@xTwme{?0Y=D^Wv{i%qin6W~B=5vl`JPYiki`z+4w<9CTLleojZKGTU3Fxv}TZ^g{6b_Wi{5-A*W?
zIGhlv=pYg#c*Qt}`ASAXc{xe$VQPdIgQjNaFyxNg1G{TWE3P*fW?>*T55VavhsUl$9JP=pwOL3BBuv2!7hJk1R
zmwJW?L)ygJDQyG6eunzMiD>i==5PhfM>3@ziR-P6ZMyZi{uIvU_Fy0n|8D3P@*&hu
zoR=mw+84O7Xuot;S)vTr>{=N|gb8eLIuS{Cy&$IKH)GAgt@Tq$?~n8}@w0~w6sY@=
z!EjkBI`3CEyM0c(O@QyHHsVZZr85Qh`!ssy5)Tcfq;Sfj^SQk{Nwb~%X2{v#bdnDvYtU~uGwD1i|lheaH
zVwiC8_mXglt#gQOT2r3Hiez+g{w}d++$ptVnAu!?V?m)Y%ou*MF|$%d{B6N{?VO#b
zl)U#JAMy~c+>s{1*S_vB@wr<`<9%b;s{QqIZ~E6xcojO=z0eS_8%(@8t}5VF+qaOD
z=*XSxCXA1=hi0)FMh3eayo?g4-fmSDv$C!uSF!q~lNVySOVPmX1>t=<{oy=q=JPme*R>wWevOOu2ABZp>@hHC1Ep{Ntt
zusk+(A>qq2e9^OM0rAWaTHW@8mC%=`#_kE2xmCoVRmI#aa`fk9O>_()3{_s1=2{Mm
zEK8F$Em0_Jk;`OFiH;A#^l_qmQA-B1e$sz_ZXoxDL*L{$PwB-lUH20lJov)iP7m&K
z`z?r%w)X_Q#Jq|K^vvGO2r{V7R6-lO^OEA`6{RyQtPweHCeCxf5_pDT{dZ!YHO<%D
z7tzQ$EbSpa7ue&E=Ad&KkG;%flD$UcJW~PVJq1l~AyLB20a>&VV@wWgxh%}|
zd#5YlxAcncXy?T-=K|h6n&q}V}B-FXyt*@Xbs-e(*6JejIM<-6
z>;0mbp0gnE@u^@5e2;3XO1w2i^wBhFcN1P|>@%V4K%LzO>r97?v-7RN&NvE$%i}ls
zXda+4DBiUM45Lu#X0&RPw&NLarO9w%*x3gdY{cB^>}L?{_EyED=TWDII^73t@>}O#
za1siUxT#p`+$p%tXk@98%Fb#L!;K+rS-iNI`}&4NGxxAdy0EAPijk^rY2#8`p%SQT&Vg{cAwXV;w5ooX@^xDrZT)-2sB4u#`T24DU;c#$zo
zQ@OTB?#A|cr@bMKkJ`m3tFC?VwA^GeB8lUVaW*}eymzM9!U_CZP!zIYcXOz$tGR3(
zD$Uu@>zb>@@$Wv)m($svj_=viZ$aR>;jf-cd&A&ROuM#ZSXFsCKLn<`$fJ2xOGZr4
z>xt$&A>lOz4bCfXS>R{Y{X$`e4rLXavHCY3CXjz{J~ZoR9x?Fr%byRjE~m!m|AYv>
z8!lAjet>3V^iC-4>TTni{$eI7rDp28H2vkl+ja*JA{rye9<2X92|vHShI(MnNIa8z
z(1rQ}mirE++Sgs@Z1t|BO)ct3gRe0`AwX*ry0cavERJtQ_(Ss`~1eU+N7cQO2JbU7%lj?5*HFB>mF<0FT7;`cCU>
z)Fv_kx0#ZeC!3U!{&xxbr7m=9bHFu7Rx%%dbI^^E{08l2CvNQ8t+>wUNW>gAvz*
zDSlB66x&KpBx?FK4{@K0h0Zi%>f7TRjV3^?6Vny>=Xr4Zh`to>*jC^m8+cqO=@lEv
zYCzwMsEhC&@mkXvEcH2CTSfjFyPqK{3$xC2j#VA0yY#B!saa4XK_)RFHtRVvj>15ZD3l{_Bd?$a0TYmB6X9>PJg7+bn`jiCN+P9Ve!K%
z7DTacOPRo4@u|3g0~mGrxP0rYLyw}ei)GGK!5h&`oXVsz_-a_8wfKgp#3h%_L
zLkgN8&pi8dFY$g}CVFg$2hf*I0m(%~FQV_LIZ<(te1w60X(g_KM{Rmz61fFEKgngcr-c?}QAy
z=vQjO=JSKRr>}k_S>YHb5R4o1J>o&BGZFDDWLHZ*vj$F`DM!KJv_x4nJ6hd{+
ze1ar{!8!YHs
z{fMr1!z2F;_e9@|M=rE4>aRv{^C_YbXUTm$lsZ)0(~M{;eVf&1!LuP0q9b=!^V&k@
zO0+cgqOg1@ZvO03oP*XAaBZ4#LHwIoI(UgxkEGISh){D
zq|ZwI^6KJ&ROURXIHQdCn(xU~V!#sj3QQndk?i1{hk#i?(=8pVkJNlgd{Pmp%ZnC7
zWj77GVBU`X93g0ic4yO3tZ)QiV!Pq!GAAWA3mdf4Hbn<33KM*`TY&D3m0P3)6sOkX
zCRL>Zdw&G=!&6KC
zmpuq<&pPzL4aHn;*<=XO?v%8xnTvYfl&Tm7VW1q^F&sM3)((oAMb`*s3+zflY@F*1o+Z5M>pGpeDWRXzS1vg@N)wtNBIux(IfgIwO*DiW8M1+O4ul0|E@6$Y0cr`7xO_U4%B&-Un-9
z#cL7pyy97Qi>4P8yV$GFMvYGN?~^b%V2@ao`}8&6A(bw55W{?G?GG~U?3ZNHbDRoW
zs6|ahA#+YnN@PBb3qKWi+GT?_EqcM_lW5-a5<>Q=kq4gE`@F1DfhX$lzb`!AjYS;pRU>u%(`xaxVe=l4TRR
zqx9!YLu?6ooaGYtUfJtrJbOmDQpmwnTP>Op?Mm6OdO6TbfZWoq6#avFG`sWj!y&T#
ze9?dlHPd{zI?pe&Fgx*LDAB8)vVNic(0HP=JKw{Hrxvf>-nD|8{>7}D4`-Ujt3DrY)^)@APLLty|dqWn=L;!
zdB*F@Q!uFHU1yC)^`LIi6#bPDDv2#+h|DwUfO-QqLAZ^RSgG1TTZ`!pD@(r4QF4s{
z>)M&1mW9evf@%BKw<|8_xu|1u#D2k2*iZAYhA^pVoPD?>!_?cirS2BfqH(}P7F}O#O!4@Ia^h0Z@EJ2@S44(Wyr;pkD1D4Rr^x2miN-pcXIuEJwS$j=<9;T`8+AQ^{FPI$WrDv1D
zQuGMgk@CCS)c6%7*7!b;XI%HUhiJEhb%^3_Elu8R`Lr;f;uU!&*(*W%>2{?=Dpjq5
zYg8HdBm0LsxUd{qHkrVBA`_pj_7w?B*G~q?ThfSS)iZXtYH~)#u-MXEJa>6B0x)aq
za8iaGs~6ffZoJx7IH{ivo6VYM52)|7zIy{BaMU3emyLcIAwk!9sFXYNC3&A^L!r2$
ze=JvMJ->!Hp?0KgrY%C2XZPY}fo_K$uHUsb($u8INfTb(2h;?jz3tr1NWz(hWGp4q
zPWse&OGyfs^)R8cLh~K@iH5=mx6gf{=1cZ9!YR&LxPI7I_lTR3Z4T?*1y1W$Ji8)`
z>ibg(QjdFscxy%8SG1?k7}4dPo3ou8zS+J)q`7B9Yb$~%j=T8K@F6NgfL5K!p=qow
zMuK5{ESzW8y$WlQum!aZN%EB8eMNm+i^CNjxZr4bumoM<40=FT@lacChj=A}KN*bV
zv?w?lLWJGm^<%jWZ3;ZKeV*z0rPE&yBRGYtih~q2{H|}wNQV~X6TKu>bCWm>9@bd0
zzpQ$+|G7L9mE!eLcYk~+ZDw1PTydJ{s#$Sdl*4)$-f&yXa>cp96ffPq&E`I_Mdi=J
z{O-|t5mhhP-mm8jptI4R{N&@ZVistaGJN~eo;@V1Z5V-1j_~fy1lD}ojaT(*!U*y6
zp%0Z@J?~LTQx?2nQkC4I^Z77F(Y$9V$oX{sRe#Kb`KbBpTjkZM)@gmgya3XUzjKs}
zfJ#3OHJyZ4^p1xc@3k$Rm-+A(&sZHVO
z{Dwg{X){vAiWx)tYIq(pr3_nD^4hyQu^PFL5IRdcyIJ*WEN#7PMDpu8A&Qb2B8b-#
zea@~nzRDM3QPWx87Ee?Z<#(EPJqe#|l&F0-)$vM<_F=30p$l;Z(Q52{#Hafn*GMWIS6AF$czFRZ^@&6kXCU%Bl`bglOiTN*1f0noX^
zgvh(Hj{}aa-7~Gxijr!;q*}YX#~NZaXx|1@}8D=1m|P}UA)uv
zc$#+mB{QAu9%}i5l$o7fuPN2aowuo$t2WUg;5JVop8WY*16>5Kok%kh9Q4oUZT$1b
zYq-Epd9bi456+O&h>zuka?ELVC0S)m%wV^rd^8D6!@2LZ$p~thuU4!d&5ecCrtzrh1WIcOhPkhv@qvTgmYH6Nzjjzc3f$O;Oxp*(r>z*i
zuP8~ND!Fk}9vtO1&?wJrD?iZ|3XbzPOB5T(s{GDn?XK(c>sGS8JV4a~?XA9SqVBd(
z;)p(*XWB81;^E18vo}jF804zRnk(qu=Rr2oS#GQ)5TsH1`
zjeM#Qls)YAUTas&*Hd)0j8-Qe;wMi7I!BV&R<=(zDA5UaKYhC#qTC
z)y!yaRW*Lyc4ea_`pi#*+~EAT)-|q)=B;I+QUbIv6j8y;
z4GX7NQ5H(PT$qTz_ryBUuzf?BEzO~%>A}WadMvzW+-zqg!ExOxF@1D2%nC)lNVo)E
zPr37GAWvdwe9c!aUhsVYrc}`K^ZNyRgA7_N_MuH}Y!zj*%fk0%I~mO}>JB~Gwd`M2
zn+jTK@=Jv-Kab6*l(TnU@;;GKslu8GT3haFSw)IiRKFG^X2FzJ#3k3~R3(Nu!%?)J
zrp#%?R7v>?%Lbyv)CECg(5!EC(SJERR2bf@NaKh)1{!VoSOh_YhU){}=@votY}M;$
zlfB-WZW@%FRZ;N(SGWW%g>@3oE%$2d;iaWdL(WeawG?`q<6y#(yuLAQ$ov6I*hZOe
zd#8jHl~&?AW5X_2je#;+mI|+$lej^%la1{wYoG;Z0X3Pi%u#kz9yU3g6my@_BDh|y
zFdE@ZwZ8A&q#AkFk8T&63fK
zo5paI_LU9ycb`>fN@5UNrCcR#VxVAXZ1j~*>l(_ASu1O(W4kw%_^BKXFgMZ)LJ(0#
zKJY%zhJ`x@@plYgZqngp+%DNCi9~eV{$z%kvZp8sTAyJ}J3(VOIcRjy0_i{c42$IB
z`xyCf!x8$aHXm3vgoYd%Twac}wGe-B(N86%v+pDtrWMo`iq(Lhgf)Q0JC81A#}e%z
zC4JLBPL*&g)~ZD#lC1d0E8k#B#cKBoU31-XD7>#gT+qcWJX(RXinz8!Y1
z;p|!A)*Y6qc-wL#6V{B(+3hM_z!gRGgA>ALQ|or20*;^D&P`*rWCTGZqE`grhcI5{
z+^EpIp8eU7E79;G+Le^J6t6G6VBe}r(y2v_W=52E4d+`u{o+r@1nY0hy-p*BnC(^D
z!a&Woi$wHHCKz7q!C~ZRM$RIDOqaqMOg8#lK-6R2t300@{X^NNBAgi3Fh*hFJ)9MT
z7-;NVA&3*EO%1-2TAR&!B4?p0pS$}tpTP9a!&q8XNwqdDZ{z%^kXseiu>Q(~D^9ls
zQ)jOCZs6JYcD2nsD!$nCp|LRI(uJ`}3VX8~kq@RkVl}kzrIrx`V>27C3*o_0qD;~V
z!B>l)P^E-(;wnc
zhp)lFHN@oef_dijt@Emq?MSfmt@!VD*$eI_-r^+i2+Vi)i5{O>>lH&NPQ%rw&|fV*
zK=mW=VSPH!U*D$CkzX?=UQ2{2C6(+Io;66{mcs&S|D<{R2C^M_=vUjYux&W*`9*dv
zfVNFkc4Sx;MpK!qb|z=@x1I~G__EK$zh$8(G0siQN&v2ZL^$sKU13mJsJ!6}^QZ+gZ@c{x9Gr>MTu
z@SUn8Mcb1a#g8id?k?0Qb@#o}w?iiE~y(RnNId&A;(#!{?ch4EO+rPX$YnN#~
z?dmDf>r;7M6cJP?I2eDm4C*-x!CG_PJlFNLhO*I>RXwJMo23O3L8*C?F>r&agj#S4
zqp;DRst|M93*9yShzB!Xm7BGTmC>KILreBTby&acj>PN9s^@+)-Tl4=+}j$hUX|!v
zSpx^yeO1XNW*4{EizP62(8+4E_S9L*muzZlF?Kab@&UUI$3E67Ch6{^iLTwpBrSd^
z?#0_fv_eJ^cA!<3{q%nCR0*o|tv<6?RSg-Hy%*L=HjqB{!7Wow`H~{jQrV1F0!49$$fxjVjN{CoMTI
zBeX;i(n~EhD`p02WAkyIxFAq70b53yLS_?2SzxP<92Gp4J^g}wGgsKi1=BFLD3liT
zq};X4j?`DNYNy2zlv*lV9N@|W2iHa#{Sr}chIIaWgs7qnXBHkew4hB{qo?=fNOR)#=m;r^B8*(H8qR
z$FImy7f@hrJwcz~KU*GcfJq)fEoH#l|0w3g6$_ro5c}ZQA5(pAExBT$nw_hp$f)cz
z98R^k$xN_dW&vK*&qZZJMd(teZ)G&sTsZwabEO`n-rsri&B9HlW#t0jORbhoSAJ58toa
zyX`(1e9k#Lg2zUWHH|QXspW8yreSOp`epi|HWMmk-xuK!uv4T`p-h(djxrsgJG2xMPUu#c;vc5weWf)t#2NU^nfleeF?n@w1%7d
z69*Hw$k|T>YzYtr?cz9y-oq&M`)r)~#MJ{+XM$8iK}M(U{8Vt=vw|mCkE`UIkd_8K
zw^x1769QumcIr&95BC>_>yrG#kRcjqS7x7v4HP?kQm49?sOTL#p=cwsKe2of
z#ZJzSyZ4jmoZ@W)TM2d9Lhq`ingOi~C$&^rdP8arQlD0vT`RmqcNb%2hd`}-bn$-T
zXrrnm;SA_)1zh;-DUKqZgJchmqxYR&RDW;!=ClzMMGGW?7mpT4SLh6>_UTCH%}gynQlFw4BeX>0M!Hg0udk^xV&jX>7Q}v;tB<&nrxx%)Z-kW~
z&hRs~TYG20UKRH6@P5td2R<+Hxo-R7Ps+#N;-{YdgfN-?q}<&7!e9NvYt=_4dk@%~
zo!`jPv@l_?&Gr(xcK5ui$>hVv6#Q~3M^Cl+m5(%vAk7}NK*iNNSChSxU4%{}+TDRT
z^p~zE=$W2=wXkOX2{oyen~yw~o(Z^pbmOB`>8e07JR#DW#!7vQ#zkB_#uRmpEqYtm
zDIdJTVqd%N3Z7d$b0c@BK=Z}(!f~@^eVqrhu26YR%Hcy)Y??c0*$vO>A)tt4enl|)
zWy)Bw08y4)PDcY5EZuPsIap3J{7|H}bGMkZsAF@d;Hs5V&dZC8b&#i|L~||@;Y+=d
zQK>WKi{E-is)H&`rMA|VRpnGtuwfqcNl%9Lja(QW>c?I?OFN>P7Y`oDFd20bh@@~)
zjH>u3%f6D8<^i{)F7Ab^l8j6UKhvi&0Gb=lz2;=e2)oxdBvA=GCrc@p+r>Nh#B*&4
z-0u2m<4rnOS`O!~^l&T_M)d2yxB0Nbfp|JDe=F4izRtBuc!;FtrczNR*H=VyjH%zHC4Qfrh`Kc>cV>R3
zC{Zq*(sH(7DR}a%gltWbI3Hp1WfZ33I{E5&zG>Iqfx;arksTA30!qp4#HoK9<
zWzXqhO3vh?C%)WrfyBgDy&cwHR#so%ET8Gm?J%Q|>wCRShjrMV*Z0BxxkOYdqSg^x
zUQ_UKP#XT$mecg)p#VG6eaVpowf7Ums4VWLlrET>s1hTm7dY1FX2
zC1zx6)NpF%9!7%^-Xa=GZJI@3dQMnkK&(MeGRz2%g<{ZSsl0KHyB#UYd^K5K)kC~p
zisz}KvRZmuLcWJhhm5H1_~QU2B7H%+S9mCAoZY5UmLqQAX>=9|Dt;3K1Swt3t
z~zv(Errdy($dHTZjpbI?HJ7@Hrhgqag#N{oCHCyO`+`po{h|W(6c&Z9wocVE
z+oK_gEl!ntpO|BN7`;?vkewmWg?dHfff)D9_;bIcHL1))@oPlazchxv3>{s1=#R(<
zaTTefn0!0XXr<_Kf`SFZP5I%&CpLI~y!;1bc`4@sCE?x6e%+nJ*(_gn(s*aCP>JiV
zp0HtC9BM?Zl!3jOKvLDzjhM_OOp~OVcx7;+@T2vm3PozOqwK+ET+D7)><)WW`7)}%
zTdtN%rwuDVJa;Z`b;_@LdfI(fAi#l_@b+6crFd$vJ>A2ExXX@(VlN-Gp
zv^?CBx)$Ex^@hqf5GL&^%hW&SI?(Pvdytu7BNLX6k(I^LRdtH}D)G4{|5J?Q{xh)_
zFFMipw_Pi`3(to)X4o8V`p22_JLYH9VOn(!nn-MpVC6K
z>u;U8>^K#~a%T18O{L9K#2W3HVJECytS_Nqs?_DKZJn;=eQzXKto{B%iV)A#T#Ta-
z{aSNWGwRbz+Wn+j&OzIJS-yNKw23nGcEatAZzKE+Q}&u94smThAeWrpv-II&m02Qg
z8W`S-xqopYH%*0}>p+OYhHllJ942m_h@Hhh7L|K`JceI1i~M02^`3*k^NhNb(6{YG
z+=~YzpL-^(Ej$BFDDUUANxkrbRjANZF%#VU@U-n94}nu?9w<)=ANl;@QE-3Zc`VE=
zL2X8urKTM&3mD0~-bWe#D4Q1hS^b%=+j3WQU=Ak)1=c8EUCd|>^I*Vl5F)s%cKNYC
zQ}atSRZZ{H`lXtM@i@bY%kJEI--VrIZ~R~WK}VE
z0Tw$d!#lr|hB{VVMxsL*SrYWP=O|HU7(yN^35nDp>H0ZzDNvT$g!g)kTGggXe7sy=
zw1DRUx7;E`r7KUN*OH)lp}p9-N%$6v)2tl_R+?=bCazY=a*xzzClg1T$@t-S^ajmKC90?b<#Wb&)JMqDyMp)y(LVu|2P{wr%ihF0XFUV0?o1-vXKJ5Pd
ziia_NossVD-81CXZwP$bvQ79{pwx?x_
z)Ud=&w1Ug%j1=3O$pC-r0#0htr^Fj!{U$VyU2}O?*C|lbDQl6Ta4n2PE-Gq@FR8Y2
z#2O(Zf@cRV_qU!=GK*(7r37AzCf@4R7-e?p!|o!y9DI6Ro^q5p=c$p@TQP&+eivEv
zNyh7T*I#0uMAo;!X~GA$=VZP7klvMX9s?a$QS>yL=nA=+0Jrnm3KN1_XBM|T<3M$-iVIKib9cZX8kin~K`m*UdmR*Fk-DQ?A`wot6NLxLA8?h+{OF2VBU
z{r>LBo}JvB&Fs#7?j3fNkkTHGpMj%@OiPI%`sh;otU%G-gbGQYDt?O;n?7B+t%Vyq
z5eTRJD}&|SumAxecq1Yfmz%q^ecACi$tr>_hQ^MLCa2chqm!;MZWxu_8mNUKzH#xu
zXW%9(TSk9xXIRaxB%*rXMmrY^xBmD!*j_jZ+INsBns(u*S_RmmDm`%wW3
z-zj-^NN6H|w@Q+sPj8vS5;aTy^*Z6)sl$D|iTCceH0sX;RR;DbQ|~^86Jc8(+@m?O
z>ENyo$ZL)osu07rL_2$PecW5RQPk$$&Uva(V`$#(zw#Gtwc%^z=gnJBs;999LKGn`
z5OOGju7FyzV%t{jr|PV3R=#`>yR~ki2swK3(KJOTVu)k1oFyAZ?G!ADX4NRs9&T
z^dQbWof(ID?z8B*+@i;jNPjQ@)sfPSSWixdoOh6VST+
z!KPrDsw~Q*6wMZ#x@>nOiYPsswsQjmZ>0QR=^OXoa7dZQ&=oro83*+<#{%w2_5u!%
zX^bC+&3*aMhjLX$xWr2CxVfu|r|gbK&uOVT1lwgZ@#O;V9-kiIf%VZ?wTMfRAs4@N
zn9&$t%E(nIyBe{Wj`arIdq4{~DfcI9s;y@d?TaGJ-HNJ@=C!6$kWKR_HcSFbFaQ~*
zqp)5n=$gjB0GXRo_z&_h`#I9beLPzhfV0s9cVRzIXS^HtAMWa6L&=CPRtgk>TYBHU
zxaaE=*W#Bieg2YBN6}KxUpAU^DpdS~m%ydgqRBz_rWo%Zdg@8r0$;fyWfxMQ01DyA
zMxH3TA`@WDG-*R@!1c=~rn&2FN+_Ey8yt7XiR`0Cs12U);I5`LbY@g&3go;n_d^!Y
z*Wk#ZYx?wW0Yl?WyxH$!=UkgwbBf@4Y^j1xY>Uo2+GX5QO1HJSZixyY664
zsge^K)ARLmlRRFw*DG`JzcP`m)WFHXbk(|K@E!{QFmIvB9527{`EscQe1*G
zk>>ngu1XRy!EZF|MVauY7=o;8uXL+4oy4D1-Kau;eOfz%e5_~wqVl2J#96Bmc{Xz*
zpFN$G1soU#o0R%8zfkNvsIhuh(IkoI3A#TN^=G1g&-nuHXv%1&W+TOJ_3hwNP(S2f
zE=n}8UO-fbcSkV_TsV;ep(l-ZN_TOK8eU|+`aQ)#qG
zS|?5?ZaGKHmJ=`f*wbf{BepIBF_2|NXhj~#ICzm&@Nm29K@oRiUmOhJfoCpKovrd%z
z-;N^u{k>9^EN>Rnx~{tawX}^HMno?b{5q6mS$q3?*8okOHuKq>P*`}Re0w6Ea7H$~
zJ^=c&o(=zJOw*uKXf2hhy*#kyYZGJ!@2lO$ty^~yuy069s%qelUfS+WsKm>)<%>SI
zIAb&R@4`DcVuZt6zrtU=U13v|xZ!KW_Ho49TNqzQc(L$rXG
zi`^cA(~?Q&6zVTgeeX-UcK!!_BoA&t^ogE_mSs~9%l&r;g)olf{Su`VJVxi?BZK+I
zVo{Pb$`fKMvm|DJIPrv(g6c~nS#MOFv~%9G$ay;Jbp{GR>RKeZ)IINFZQXjg{&&Pr
zxa*|1HViZ*v;{_ZAk@+=b71j$w{c
zcZg;BsvpYs*+^9*^>|sQ-lFdoeuFHWS4EtUKfcT6MBECaniZ{mY+(HPm%~_(hrO-4
z$zVFbVF1YXWhKOG{L?}XV1wk2ycWrK_a%%l>JxlLZvU%2zu*rZqr);mSqDpd-CA>c
zqOXa!eT(;3c9K7$Gpgjuxr-@2|Ms9x&QG%@iKW$?5Xe;HYS9!o584bMxHe}!UV+p4dYEtBAv~XuhlUnh`r0Xq;
zEMkqZj3foCgTn*xL4>r~7n^_EDMte=LPcQ={x4g^vch#Nf#mm2bn~5qT(v#iKpRl0
z4Ex}di?%Gft=(nKs;L}qmxWC9NW?O8^U*)*fZamL@jJ1F$_fFHy?ABi!yX{s2
zh0juu>*&oD_(hbsKRFG^;*3Qn7IM?O^#=@K6ie1$Uu;NB9`uwtw}bdL%&F+wnjwa`
zx6uI4y!AP*AeUU!NFgB$)2shx%qEcY@ar>n>kt%`aZBv?Q+T)8mDG=gy{4->
zBnv<@R-Q!w(AM^W>D+*>mBs|~M)haI+ndtSzf>xWQ;^hu<62IWe>6N8dZR5vwG;Z}
zhUzNLt~gPz{~AW`H*muGYldzhhi?eq?v|yfkd(cCH#ksj&yAp){0#On8e0+jktdTpvmOXMCK8G=g9->9OmVu63yh8T`q(|IW0&chxXHOUvICjl&|NdMs
zY1AC`-PYM_^HjK)bm+|au^i+ogu;7{pw|2~Jh?Y%c?F88U>vMk89cK`Or`w0huKFgXr-nk#!zm^RcKY4z^gmqt{UyW
zUI`Y|m!HM+Z2&(=QfQURV50;Yl-4yQJfXJuiEM~3qy*&YzN$QNtRy0*q+@IVw^ReJ
zZu53G)R5G)MFPE}ddNk1ziy#l3t`z>Rhva5MG?)sOq4uYqtM|3|MxQ-oVeDf>
zmNv^|8~T=CNKgoQC2ck*N%ZJ@{5OOk3!#spCuai5S;dS6T$
zu+b#TIZ2_KB2O&)oA1iCXAA!3d3Lqb#z4r-4j678q7D8J#e
zmyV+!9e!D5IR})aV2RY9pC4=|nz9)W`Ln`!t_LR5ZeDZ&-T(|FAve8(6fZkRJ&pNS-k3DEoU31OTA14zrBVkTviE$02-&~xecEZ&D#{adc
z+m)`gM;%{FUtmxLo=3gq(kKPe!UB7;^LEY4w`#XG+ICNWb&=2ji*BpmNz|n!^*9>Y
zzB|(61!Fpbu^oeP{9iy7Sr!ClIvaXeh!Q+Dbp}x69;}*#2P`8cX>9EC$qG{5iM
zUGiNA|;|eDc+vzZmw4f!`_EmM6k0AHvC8La6<9}Yb$=+Xh8JTBEgHc{MRg&;PA
z%M-dm2$Qr~kue4pci5T3(3Zvu;lVfHI1cTZ7(@6m|NFL$?Jci4u4IYeEH*jY8CR_L
zN=4pj6+01QPiXAXrv_)+;kDz@PWiX6U(?IbccDA^G1}6O0O~gYpxtZ%T7DqMXgu1pZ&UX(mr&KStHZgj>X&TE
zPNHPF5WEBOkD#$D${Rv`UMcJQHUv%@exgq`mn2cddXGbgVvRVvimJszp9k0b?B>49
z?~oA|q4gdX^Ickug$`9(EM``Cm_FiEaQ_;?sZPYDG;fCAOD6nco#@Cx6qJ^i12?yA
z5IKG>1S1Gh+5W0aR1nYg3p}&il7r3~wmul6S
z!_N+D=+L6uwF52=50wl3)}tI${d}2X)!DA9o4Mnhh{RhBWT|`@EB3!1o?IJmV)d)0
z)TVR(rzV2f)J*fgUI4bJ0Jnu7(P>FbD0k*_2o-}Mn%u|CLWjqS>SiQOB3S+30eF=U
zYUk(J2n}&?OY$Eo*j-NToX26s`|=+|F>+y-TP~sOeqO9}D~?}Z!7*v)@Ms{4VFgZZ
zY?m66b{Wbe)Z8e-#WmCW)lurw*`kEFU-D9BGPuHxnm#`wq^@=c;ffb0+sb^xkueG4
z?}rGhzn|Z7lW};7q!eH5cAvT86Uh7Wm-jMvnj@UmMag_0NVI=J0Z4+m7>w#L_WJ(%
zguqTF`?!+>G22&WxaCeT%v7W@tsTBfR(CS}3;h;&iY*~x!p0SRbf|OK=_EV6GV)6r>i$!7QTwPw%8w)yd
zDGLEasQ!8QwZ8ZWmD1^ei3kimg05*Nn1Iw)i1xMr8<;wR@;TywI?XZ>sIhU)`eQ7O
z!hgufcg(GE(I8@b6FuC*g?jL5x&^Ex;0oh)(JfNK0GQ9&@hpZFcXWj|gWDxhmCkPb
zyP`E`MYx8|Od0Y6m(@kGYY|^-1sk#5&I%yB5Ln!y&m(2>I6$(-^+?=SzjwxZ@&OdB
zg5~MNScI|WB2cuqkYqUe)Tv!2r+BHoWcu;4Krz&{5{STN=x9;}hiRu>64fH3XWFWv
zuB?Cv1fn*r!oRDm(zt(1-WcOV&
zv7G+@Mxvp##^f;uwOOfqs>NfS=6r$(Of>?bqnhI&Y$@867RK`ZqBHepq??;r
zVG}B@XK9LlD1h*2hr>^rRXT}T`98&j1!QV#Iu5mB1+d(@6O
z_yavEl|IqAs0{Da?E7$8r>d{tzaFXQq`w%5UV8Xuk<
z`fuN-5u3n|yTQPF?ma$Mk}~M6sM49f*zTSmC^K)*&Y#VlL<96X52x``!6cAj2T?NA
zr8DyjUbH#uHmNo382)bM>~5xbZROX-If#v$t3)oKIb~(oI4{Kb$pZCB%ss!A0UjBS
zB$qOr6uN-ih8#)pvsi|4P)kKo@Q2+^86r16OhKBYE$vPQ@oMlHZPELnt>X9St@Vlg
z3JfqHoJU3o9qdIdKVdiGS&WdYlo>{da-I#Mp8s#*yO0`5JC+3UJe3azU&+KuWatx{
zr8W8?I@0LZsO6ni8MoBGiau4|O-3JG*>nFrqKEr@NecuEGm99O%_XBdtRN$lQ8?@*
z6-MlV(>ok4O){<6)gvu8r1A3$S6h^#S{56{H%>_zeiqw@!J@gIu<-VZUsXjVPvMP0
z&&Cf=`8%GLdnAjl^2X@XaLRj@bE7T0oi;Ws_p^K54ek(!r;mshAUV8y9yz|dZRrA*
z7)&=B#9o_MrD>#Nv>$bAX!A8R-5pE+g$0VXeqpZ$J>o1k!6;`^utoCmrsg-#oD3nbCv3K865Aq2c7%Vz0l?Ch%
zF9=PB_F8UE&^i=Lndhj4>)_00kkAc2A!wekqlo8S3n!_R?I}lp<_mdN@sy*(Zr03?a@D!X{$xFW=d(E(HlQ&pWqX}wpq8=Tljj+nO>-p5Z{<@dqXW)zgbNqvDt)%s6wXy0ChLjpn{
zj#sTbpW&P(GZVS!ih{`tTdrF4BE=LNQG>mGJGIy@8wp@38AO(1m*W^>fduc7deaz(
zBu-_5G{&DZ?zy80QopJ}WGQbC)oEH(r|Or#Y0t>}hijWI!%hsZ2caO%-1!=V)XpeE
z8rw$uF_&@o%mnmIpqM}_PB8-i-QnHLk`)M!3Oc@)Y0HAGmrcuS0CJBCjq&+BSQ2?IU)bT^`oOO
zFjP?^XAmj%soNkjxPxU=j>gy?Rc@$2k#Isd`V#jz^dWm_Q2vyt)qB2?y>wB-Q$!N3
zZ)xm(s`W5%1_z!TD`MDFqck#q1Xd@f3!n|ggWC8{R{hF-XiwH|Ir*{RWZ%hApD-4y
z%!-(R$r0%5fWIn8;oZJxsGdi}gvz5^Dejv1apK7Q&i10?6uAl(ZsGV9tr;&ZLmGT&
z#;n*Bp_eL=FzOn|gB995N`EphPa&=Aw?2}WhOw$@48L;|?l(~j7sBftDAc9gB#CLq
zOP`)Qi~_{5|3u~CYzCPmjU@cHvi5zG@aJU7-a4K)dCTaM)u5XSlWidKu_U2g0rr*^
zQk^0I$VYS#1@N0cNvA0m0TwCAHjhp06~O19<3CjGaFu>1+2t<$N#TDLQq!$jDBr%(
zNcC{t5jetLQ!4OC&F_=`E!Ek0`YLO7G$qiHJJSXvb4GaqPYN8Y*iIsq0QRLAybt~?
zgamKRYRaVL-!!mk$grh2h0TVnXHwjz-x=k8RR
zry4hd_Md;_YMW<=Cl;JfhFx52U%@V&OcC#~BmEYF
z`<_H3O8g~&z`@uRk6i87L~4;S>cMPCODMBwPB5;20eND;i}o`bPN_n0K=}0IyQ^pm
zF{eb^Dx6p3e4+eVhimPp*c$KfeF3fc|K}yI`VyF=M<=*wHNh`EdMr3(XN7P0(v=uJ
zBk=zGQ7h@rvJG?^2Q3FtRg`7N+HOyVZ9|FNVkb>HberE2-C97j!xa-tJK)#cy|yg)
zC$La4)(PEuovvFO#rK1Z5^L^eAy5?
ziV?O$`@YkyT6E!2nwRoh%+7-9iMrPdp#U(yG%@@}7hdubu9S=$_5Cl}EzbV8R1MYx
z^6MM;%cy~~pkNSsx*V{irwAF_VMRddk#oH5P*Lrdpi{V9>Yp%;-=$VtWs^dMopMcc
z-<(&r9D;67i6A;MK!YtVUdo&6{puN3t{#RwpY+^(|7}T>Zq&Oqo^SQx=8?$mJGUB~
za-Q8BuLmB8NnK8xgl4i>`9!-69n?r#MrCv-x?+A72J>3jmTq)O&udvzgOHHE*GCDS
zwXd`{CI)8Vs36w94A;F|+__}iK!EMd5P$;U{Ni=d=eHae4VtuMRCnkzp5wvxzyltv
zmsc7}H|~6i!wAM9;jxpTrlwKcW(a-N1RkbxAjON!kJ^Qv>(*P7AqnI7Dw7g1=9n+h
zMz$3MvGj`vdz`%}nl$jSx{0=0d)hEFCR6v5G^9JjsVQACxzR9j+0r?GpSxKg@y#%A`hsK_Q
z(TuIdEbC1D$@6!UJwOrn{g2RE
zbbv3%q$LDHV#XErJ$dmtIuX*Fl3wm)+V%KRhbyCg9@)vU4ukJvDkG1cv9`jE2WAx#
z#}@Ka5cIGV%bOf9CqEA`V%~S_)mfiHE+&@`wK{lHB15UHnNZsE?0@lzi<>gX8fUSd
zYtXrrxp3;&mzNW!#@9!vzR&&=?wVwAJdskOOpK}=2h|pe)B>Ix2mk2Ll_rn;zRT8L
z>sr{dxEd`x^L*&kUxiGtgaJmZr*##vCPFar{C{3DDkh2_4}Zk%R6G4p^8VRyesdC=C)=Of-gi0iTW4fs7ap;`r8mwlWDgIIuEq9|xJIB2
z`DPC$wxq0LVI!>{MAcNxG&|Aais-1Vd%r6yLl4mAJ%Mf%U1|anZ%3MA~t}9u_UZQ$1^SWXrQQm72_O
zv6h~KpL;XqNX_&jCti9w=@UEuE;DKY!dO*R<=)y>4xA{`>B@j|_+Q6z&Ye|Eti_tV
z{>hZcb!~HKm)({B^g-$G&!5AgHzy0RXb_}Pa=Dw*z(aFMRx$Gs=?X9HGSu1>Fbh1H
zAbndn);}H<5Em}tit=LAg;_?0OqT;N7?o4_)_9}Eni)G+)ikBoslkSAVm~1I7_=fp
z-`T=kK|xyC@j8H$dSH;@rdC1ZYu(n~y}8AD=$f8s7Oj^tVk3H?;Ae6~`DlJ!Et@3}
z5`MHMZQRgA*NVrI(+Eg+?>n{8vm^DEqN$0Y$IcWQ+>m=&@9XfSNDm=h`s0GTRUmveY1gu5dLm#O)zJ6ey
ze1)gT!UpI|ar2=nO$hL9We_9|VrCne6Nud4O}00s=I);S2Jm?KG+$oeX<|p3
zq0niZlpo&xa!)PVs@ljr|JVHR@SWGiqv6)GSY_?dKP9*yD_az>Q#@M;gdi9{upCVkG
zAcKr^S@*g_%ZyX7U%csYXJoOCVaU|SV$Ry9E3RHZ#xyQ)Dc3-Hrbki}nrGwVS1))f
zs)22X^EQrnx{_}J^ZXUcE_?7z=G=ARME@9R2d5csgnTLht2Rv?={#N{cRr4(bqP6|
zO;;>mk*;At(Mifk0shj*z$Cc&>I&PdYCCYy{
zc=zV!dXb%y&Zl2BIBubv_`uMo;R!6`H*xN}D$*fTU3yVgsL(b2;Axx(C>?&~bZL0K
zy(Yvs-)U6ZL$SOjU0mbEXRKJ!>i1_6Mf?jiQGK!X3!voE+nhy+=Fae2=5!$_sFEzI
zh^lJyixS%)P#DX;0(h>V@rSKfVFmY_L+oa#klnKMG!{Lc3@c-@r3W`YFKO#{Q
zVA40C>}(YLkg?u0m38NxRmA%@O>sQZ;Pp&FA$Fs7n4m6tm@m$t$cX5))*<9pG<4ef
zx+^v-eR<87$44ejU?@l_}
z{thM2@uzj)G4UP=vN3X^NXiP|qX>W}6)*Fw$6ULmI7jcl+
zcsF2mrBUa>LnH!8iN=eVeSNoX2!+yT!H>+GR|vYEEk1W5|A|OL&;}!nDxk)BYhKVo
z@Pp*e$&$vw2ay={1=<88{a04i%`H~wv<6IVi7nL@s=-}wjR*H7upiiuYszuMOWNvX
z51YXF2cTugCxjgG8Qt5pIKfHsr!NLTaKqzw0)>v55=Wk2)kHTLkKpvErj)#D!Bc)#
z&OpG%0@Pz7DF8{U>m+RW{SCjnXcGg4}dTb`GT>!wBTTA%O1uA9*OLEw35^^xgETWRa^TChQ#%6?8
zJ2>K(#_=~Kr!JFYX1WL&U7Xi9eK@gZihfO2pFUtV!`Efcx^Fd)dEue;Veypju=k@w
zyreM?Ss>J>nxS!s#isrJ8QaMLsV7z(O0jGmeD$oOs1xC1L;R`|v?v1c{uRhog(S(}
z*Y~%y61CBi0e0Evmp0=iG`=HGnUL_2$c)4jV!)Gldth+}9BD|c+ft5bvtj72>|jxS
zKks4*F(c&8p=es;d<;wUjV#6$L`L7ejH{bDTXu(<@1(Ndta|vkH(9Q1H@WD*=YS{pVbd%!
zp3I*WY3an{tAo7x#DuE9pFZ^EgwkQ9om<lIRfxVsFg$osh_T@sN02uiy8ZrzfX#^!k2&Q%JzUciUP#90WeV
zsKjtzBld1E{Jc%x=`F{CBt4v$uRVzT8zm9&8Xc<%ZD=>-x!(sF7nptFw>ly#ExXME
ziJ$P|qxBVa$8e{sWwONVBK5^CLNm!jUU-0jA3;V
zbrmxZ`HyZL4x7N=6&z}OK!QatPBm?E0u={}Q8hWr$8QBpI!v`FS-7u$75Qq&4zWUR
zW=I#&|7fsr;F(I-kcuUvUg8&3n4=v07oD$vV*OaD|KxMf1|Z)7KQL~IT8|-nlf6ha
Yq}jxdoa_BX^xOt0D`?2q$XbT|4?PS8ssI20

literal 0
HcmV?d00001

diff --git a/content/images/structuremap-logo.svg b/content/images/structuremap-logo.svg
new file mode 100644
index 0000000..5abc631
--- /dev/null
+++ b/content/images/structuremap-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/diagnostics/build-plans/index.html b/diagnostics/build-plans/index.html
index b7648e9..d736e6c 100644
--- a/diagnostics/build-plans/index.html
+++ b/diagnostics/build-plans/index.html
@@ -1,96 +1,94 @@
 
 
     
-         
+        
         
         
         
-		StructureMap - Build Plans
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Build Plans
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Build Plans
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Using the Container Model
-		        	Previous
Environment Tests
-
-		        

-		      

-		      
-		      
-		      
-			      	Build Plans  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
Build Plans
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Using the Container Model
+                    Previous
Environment Tests
+                
+
+              

+
+              
+              
+                      Build Plans  Edit on GitHub
+
+                      
+
+                      
+                          
 
 StructureMap 3.0 introduced the concept of the "Build Plan." The build plan is a textual representation of exactly how StructureMap will build a given Instance, including:
 
@@ -107,7 +105,7 @@ Build Plans You can find many more examples of finding the build plan description from Container.Model from the unit tests in the StructureMap codebase.
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Environment Tests
+                      
+                        
+                            Previous: Environment Tests
 
-				        
-				        
+                        
+                        
 
-				        	Next: Using the Container Model
+                            Next: Using the Container Model
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -185,7 +183,7 @@ Build Plans 
     
-         
+        
         
         
         
-		StructureMap - Environment Tests
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Environment Tests
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Environment Tests
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Build Plans
-		        	Previous
Validating Container Configuration
-
-		        

-		      

-		      
-		      
-		      
-			      	Environment Tests  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
Environment Tests
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Build Plans
+                    Previous
Validating Container Configuration
+                
+
+              

+
+              
+              
+                      Environment Tests  Edit on GitHub
+
+                      
+
+                      
+                          
 
 Years ago I worked with a legacy system that was particularly fragile in its deployment. While my team at the time and I made some serious improvements in the reliability of the automated deployment, the best thing we did was to add a set of environment tests to the deployment that verified that basic elements of the system were working like:
 
@@ -117,25 +115,25 @@ Environment Tests StructureMap's ability to validate a container, you can use this technique to quickly support environment tests embedded into your system code.
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Validating Container Configuration
+                      
+                        
+                            Previous: Validating Container Configuration
 
-				        
-				        
+                        
+                        
 
-				        	Next: Build Plans
+                            Next: Build Plans
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -169,7 +167,7 @@ Environment Tests 
     
-         
+        
         
         
         
-		StructureMap - Diagnostics
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Diagnostics
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
WhatDoIHave()
-		        	Previous
Interpreting Exceptions
-
-		        

-		      

-		      
-		      
-		      
-			      	Diagnostics  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
WhatDoIHave()
+                    Previous
Interpreting Exceptions
+                
+
+              

+
+              
+              
+                      Diagnostics  Edit on GitHub
+
+                      
+
+                      
+                          
 Improving StructureMap's ability to diagnose and explain both configuration and runtime problems was a very big goal
 for the big 3.0 release and improved with additional type scanning diagnostics for 4.0.
 WhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Interpreting Exceptions
+                      
+                        
+                            Previous: Interpreting Exceptions
 
-				        
-				        
+                        
+                        
 
-				        	Next: WhatDoIHave()
+                            Next: WhatDoIHave()
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -148,7 +146,7 @@ Diagnostics 
     
-         
+        
         
         
         
-		StructureMap - Type Scanning Diagnostics
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Type Scanning Diagnostics
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Type Scanning Diagnostics
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Best Practices
-		        	Previous
Using the Container Model
-
-		        

-		      

-		      
-		      
-		      
-			      	Type Scanning Diagnostics  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
Type Scanning Diagnostics
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Best Practices
+                    Previous
Using the Container Model
+                
+
+              

+
+              
+              
+                      Type Scanning Diagnostics  Edit on GitHub
+
+                      
+
+                      
+                          
 This functionality was introduced in StructureMap 4.0.
 Type scanning and conventional auto-registration is a very powerful feature in StructureMap, but it has been frequently troublesome to users when things go wrong. To try to alleviate problems, StructureMap 4.0 introduces some new functionality for detecting and diagnosing problems with type scanning, mostly related to Assembly's being missing.
 Assert for Assembly Loading Failures
@@ -131,37 +129,36 @@ What did StructureMap scan?
 The resulting textual report is shown below:
 Sorry for the formatting and color of the text, but the markdown engine does not like the textual report
 
-/*
-All Scanners
-================================================================
-Scanner #1
-Assemblies
-----------
-* StructureMap.Testing, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-
-Conventions
---------
-* Default I[Name]/[Name] registration convention
-* Register all concrete types against the first interface (if any) that they implement
-* Register any single implementation of any interface against that interface
-
-
-Second Scanner
-Assemblies
-----------
-* StructureMap.Testing.GenericWidgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
-* StructureMap.Testing.Widget, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-* StructureMap.Testing.Widget2, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-* StructureMap.Testing.Widget3, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-* StructureMap.Testing.Widget4, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-* StructureMap.Testing.Widget5, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
-
-Conventions
---------
-* Connect all implementations of open generic type IService<T>
-* Find and register all types implementing StructureMap.Testing.Widget.IWidget
-
-*/
+    /*
+    All Scanners
+    ================================================================
+    Scanner #1
+    Assemblies
+    ----------
+    * StructureMap.Testing, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
+
+    Conventions
+    --------
+    * Default I[Name]/[Name] registration convention
+    * Register all concrete types against the first interface (if any) that they implement
+    * Register any single implementation of any interface against that interface
+
+    Second Scanner
+    Assemblies
+    ----------
+    * StructureMap.Testing.GenericWidgets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
+    * StructureMap.Testing.Widget, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
+    * StructureMap.Testing.Widget2, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
+    * StructureMap.Testing.Widget3, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
+    * StructureMap.Testing.Widget4, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
+    * StructureMap.Testing.Widget5, Version=4.0.0.51243, Culture=neutral, PublicKeyToken=null
+
+    Conventions
+    --------
+    * Connect all implementations of open generic type IService<T>
+    * Find and register all types implementing StructureMap.Testing.Widget.IWidget
+
+    */
 
 The textual report will show:
 
@@ -173,25 +170,25 @@ What did StructureMap scan?
 See also: Auto-Registration and Conventions
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Using the Container Model
+                      
+                        
+                            Previous: Using the Container Model
 
-				        
-				        
+                        
+                        
 
-				        	Next: Best Practices
+                            Next: Best Practices
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -225,7 +222,7 @@ What did StructureMap scan?
 
 
 
-}); 
+});
 
 
     
diff --git a/diagnostics/using-the-container-model/index.html b/diagnostics/using-the-container-model/index.html
index 2703607..0f4876e 100644
--- a/diagnostics/using-the-container-model/index.html
+++ b/diagnostics/using-the-container-model/index.html
@@ -1,96 +1,94 @@
 
 
     
-         
+        
         
         
         
-		StructureMap - Using the Container Model
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Using the Container Model
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Using the Container Model
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Type Scanning Diagnostics
-		        	Previous
Build Plans
-
-		        

-		      

-		      
-		      
-		      
-			      	Using the Container Model  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
Using the Container Model
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Type Scanning Diagnostics
+                    Previous
Build Plans
+                
+
+              

+
+              
+              
+                      Using the Container Model  Edit on GitHub
+
+                      
+
+                      
+                          
 
 The queryable Container.Model is a power facility to look into your StructureMap Container and even to eject previously built services from the Container. The Container.Model represents a static view of what a Container already has, and does not account for policies that may allow StructureMap to validly discover types that it may encounter later at runtime.
 Querying for Plugin Types
@@ -108,12 +106,12 @@ Finding the Default for a Plugin Type
             // Finding the concrete type of the default
             // IDevice service
             container.Model.DefaultTypeFor<IDevice>()
-                .ShouldBe(typeof (DefaultDevice));
+                .ShouldBe(typeof(DefaultDevice));
 
             // Find the configuration model for the default
             // IDevice service
             container.Model.For<IDevice>().Default
-                .ReturnedType.ShouldBe(typeof (DefaultDevice));
+                .ReturnedType.ShouldBe(typeof(DefaultDevice));
 
 Finding an Instance by Type and Name
 Use this syntax to find information about an Instance in a given plugin type and name:
@@ -138,7 +136,7 @@ Ejecting Services and/or Configuration
 
 To completely eject any singletons and permanently remove all related configuration, use this code:
 
-            // Removes all configurations and objects already built as singletons 
+            // Removes all configurations and objects already built as singletons
             // related to types in the current Assembly
             container.Model.EjectAndRemoveTypes(type => type.Assembly == Assembly.GetExecutingAssembly());
 
@@ -164,8 +162,10 @@ Finding all Possible Implementors of an Interface
     public interface IStartable
     {
         bool WasStarted { get; }
+
         void Start();
     }
+
 
 We could walk through the entire StructureMap model and find every registered instance that implements this interface, create each, and call the Start() method like in this code below:
 
@@ -208,25 +208,25 @@ Working with Individual Instances
 
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Build Plans
+                      
+                        
+                            Previous: Build Plans
 
-				        
-				        
+                        
+                        
 
-				        	Next: Type Scanning Diagnostics
+                            Next: Type Scanning Diagnostics
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -260,7 +260,7 @@ Working with Individual Instances
 
 
 
-}); 
+});
 
 
     
diff --git a/diagnostics/validating-container-configuration/index.html b/diagnostics/validating-container-configuration/index.html
index dffcb01..d03df20 100644
--- a/diagnostics/validating-container-configuration/index.html
+++ b/diagnostics/validating-container-configuration/index.html
@@ -1,96 +1,94 @@
 
 
     
-         
+        
         
         
         
-		StructureMap - Validating Container Configuration
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Validating Container Configuration
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
Validating Container Configuration
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Environment Tests
-		        	Previous
WhatDoIHave()
-
-		        

-		      

-		      
-		      
-		      
-			      	Validating Container Configuration  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
Validating Container Configuration
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Environment Tests
+                    Previous
WhatDoIHave()
+                
+
+              

+
+              
+              
+                      Validating Container Configuration  Edit on GitHub
+
+                      
+
+                      
+                          
 
 To find any potential holes in your StructureMap configuration like missing dependencies, unclear defaults of plugin types, validation errors, or just plain build errors, you can use this method below:
 
@@ -122,25 +120,25 @@ Standin Dependencies for Runtime Dependencies
 If you take advantage of StructureMap's ability to supply arguments at runtime, you may need to add fake or stubbed stand in services to StructureMap just to satisfy dependencies while calling Container.AssertConfigurationIsValid(). For example, in FubuMVC we supply several services representing an HTTP request as explicit arguments. In order to use the container validation, we have to register stand in services in the main container.
 
 
-			      	

+                      

 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: WhatDoIHave()
+                      
+                        
+                            Previous: WhatDoIHave()
 
-				        
-				        
+                        
+                        
 
-				        	Next: Environment Tests
+                            Next: Environment Tests
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -174,7 +172,7 @@ Standin Dependencies for Runtime Dependencies
 
 
 
-}); 
+});
 
 
     
diff --git a/diagnostics/whatdoihave/index.html b/diagnostics/whatdoihave/index.html
index 9a02c00..fce8225 100644
--- a/diagnostics/whatdoihave/index.html
+++ b/diagnostics/whatdoihave/index.html
@@ -1,96 +1,94 @@
 
 
     
-         
+        
         
         
         
-		StructureMap - WhatDoIHave()
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - WhatDoIHave()
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Diagnostics
WhatDoIHave()
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Validating Container Configuration
-		        	Previous
Diagnostics
-
-		        

-		      

-		      
-		      
-		      
-			      	WhatDoIHave()  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Diagnostics
WhatDoIHave()
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Validating Container Configuration
+                    Previous
Diagnostics
+                
+
+              

+
+              
+              
+                      WhatDoIHave()  Edit on GitHub
+
+                      
+
+                      
+                          
 
 The IContainer.WhatDoIHave() method can give you a quick textual report of the current configuration of a running Container:
 
@@ -132,10 +130,10 @@ Filtering WhatDoIHave()
             var container = new Container();
 
             // Filter by the Assembly of the Plugin Type
-            var byAssembly = container.WhatDoIHave(assembly: typeof (IWidget).Assembly);
+            var byAssembly = container.WhatDoIHave(assembly: typeof(IWidget).GetAssembly());
 
             // Only report on the specified Plugin Type
-            var byPluginType = container.WhatDoIHave(typeof (IWidget));
+            var byPluginType = container.WhatDoIHave(typeof(IWidget));
 
             // Filter to Plugin Type's in the named namespace
             // The 'IsInNamespace' test will include child namespaces
@@ -147,25 +145,25 @@ Filtering WhatDoIHave()
 
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: Diagnostics
+                      
+                        
+                            Previous: Diagnostics
 
-				        
-				        
+                        
+                        
 
-				        	Next: Validating Container Configuration
+                            Next: Validating Container Configuration
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+        

 
 
     
@@ -199,7 +197,7 @@ Filtering WhatDoIHave()
 
 
 
-}); 
+});
 
 
     
diff --git a/documentation/index.html b/documentation/index.html
index d8b47f9..5443b9f 100644
--- a/documentation/index.html
+++ b/documentation/index.html
@@ -1,118 +1,116 @@
 
 
     
-         
+        
         
         
         
-		StructureMap - Documentation
-		
-		
-		
-
-		
-        
-        
-        
-
+        StructureMap - Documentation
+        
+        
+        
+
+        
+        
+        
+        
+        
+        
+        
 
         
         
     
-    
+
     
-    
+
     
 
 
-        
+
         
-		  
-		    
-		      StructureMap
-		    
-		    
-		      
+          
+            
+              StructureMap
+            
+            
+              
             
               A Gentle Quickstart
             
-		        
-		          Documentation
-		        
+                
+                  Documentation
+                
             
               Google Group
             
-		        
+                

 
-		        
-		      	Previous
-		      	Next
-		      
+                
+                  Previous
+                  Next
+              
       
         
           
         
       
 
-		    
-
-		  
-		
-
-		  
-		  	
-		  		StructureMap
Documentation
-		  	
-		  
-
-		
-		
-			
-		      
-		      
-		      
-		      	StructureMap 4.1.0
-		      	

-
-				
-
-		        
-		        	Next
Roadmap
-		        	Previous
StructureMap
-
-		        

-		      

-		      
-		      
-		      
-			      	Documentation  Edit on GitHub
-			      
-			      	
-
-			      	
-			      		The documentation may never be exhaustive, but here are the major sections so far:
+            
+
+          
+        
+
+          
+              
+                  StructureMap
Documentation
+              
+          
+
+        
+        
+            
+              
+
+              
+                
+                    
+                    Next
Roadmap
+                    Previous
StructureMap
+                
+
+              

+
+              
+              
+                      Documentation  Edit on GitHub
+
+                      
+
+                      
+                          The documentation may never be exhaustive, but here are the major sections so far:
 Documentation
Roadmap
A Gentle Quickstart
Glossary
Get StructureMap
Features
Software Design Concepts
Setter Injection
RegistrationRegistry DSL
Inline Dependencies
Auto-Registration and Conventions
Working with IConfiguredInstance
Construction Policies
Changing Configuration at Runtime
On Missing Family Policies
Constructor Selection
Fallback Services
Registering Existing Objects
Replace or Clear Out Previous Registrations
Using Attributes for Configuration
Resolving ServicesGet a Service by PluginType
Get a Service by Plugin Type and Name
Get all Services by Plugin Type
Try Getting an Optional Service by Plugin Type
Try Geting an Optional Service by Plugin Type and Name
Passing Arguments at Runtime
Auto Resolving Concrete Types
The ContainerAuto Wiring
Building Objects with Lambdas
Working with the IContext at Build Time
Registering a Single Instance Against Multiple PluginType's
Profiles and Child Containers
Nested Containers (Per Request/Transaction)
Working with Enumerable Types
Handling Missing Named Instances
Lazy Resolution
StructureMap and IDisposable
Working with Primitive Types
Object LifecyclesSupported Lifecycles
Configuring Lifecycles
Custom Lifecycles
Generic Types
Interception and Decorators
Interpreting Exceptions
DiagnosticsWhatDoIHave()
Validating Container Configuration
Environment Tests
Build Plans
Using the Container Model
Type Scanning Diagnostics
Best Practices
History
Release Notes
Custom Instance Types
Integrating StructureMap into Common .Net Frameworks
 
 
-			      	
+                      
 
-			      	
+                      
 
-			      	
-				        
-				        	Previous: StructureMap
+                      
+                        
+                            Previous: StructureMap
 
-				        
-				        
+                        
+                        
 
-				        	Next: Roadmap
+                            Next: Roadmap
 
-				        
-			      	
+                        
+                      
 
-		      

-		  	

-		

+              

+              

+

Internals and Architecture

Best Practices

Build Plans

Environment Tests

Diagnostics

Using the Container Model

Validating Container Configuration

Filtering WhatDoIHave()

Documentation

Documentation

FAQ

Things StructureMap does not have

Source

Auto wiring

History

Integrations

Integrating StructureMap into Common .Net Frameworks

Interception and Decorators

Interception and Decorators

Interpreting Exceptions

Configuring Lifecycles

Custom Lifecycles

Motivation for Container Managed Scope

Legacy ASP.Net Lifecycles

Need Help?

Custom Registration Conventions

Best Practices

Configuring the Raw Model

Custom Constructor Selection Rule

Fallback Services

Registration

Programmatic Configuration outside of the Registry DSL

Using a Custom IFamilyPolicy" id="custom">

Named Instances

Setter Injection Policies

Release Notes 3.0

Get a Service by Plugin Type and Name

Get a Service by PluginType

Get all Services by Plugin Type

Resolving Services

Using the ExplicitArguments object

Auto Resolving Concrete Types

Try Geting an Optional Service by Plugin Type and Name

Optional Generic Types

Future Plans

Service Locator

Auto Wiring

Forwarding Requests for a Type to Another Type

Multi-Tenancy

The Container

Disposing Services

Profiles and Child Containers

StructureMap Assumptions

Working with Enumerable Types

Working with Generic Types

Working with the IContext at Build Time

Build Plans

Environment Tests

Diagnostics

StructureMap 3.1.6

Next

Previous

Type Scanning Diagnostics

Assert for Assembly Loading Failures

What did StructureMap scan?

StructureMap 3.1.6

Next

Next

Previous

Using the Container Model

Querying for Plugin Types

Working with a Plugin Type

Finding the Default for a Plugin Type

Finding an Instance by Type and Name

All Instances for a Plugin Type

Ejecting Services and/or Configuration

Testing for Registrations

Finding all Possible Implementors of an Interface

Working with Individual Instances

Using the Container Model