tl;dr: StructureMap 3 introduces some cool new diagnostics, improves the old diagnostics, and makes the exception messages a lot better. If nothing else scroll to the very bottom to see the new “Build Plan” visualization that I’m going to claim is unmatched in any other IoC container.
I’ve had several goals in mind with the work on the shortly forthcoming StructureMap 3.0 release. Make it run FubuMVC/FubuTransportation applications faster, remove some clumsy limitations, make the registration DSL consistent, and make the StructureMap exception messages and diagnostic tools completely awesome so I don’t have to do so much work answering questions in the user list users will have a much better experience. To that last end, I’ve invested a lot of energy into improving the diagnostic abilities that StructureMap exposes and adding a lot more explanatory information to exceptions when they do happen.
First, let’s say that we have these simple classes and interfaces that we want to configure in a StructureMap Container:
public interface IDevice{}
public class ADevice : IDevice{}
public class BDevice : IDevice{}
public class CDevice : IDevice{}
public class DefaultDevice : IDevice{}
public class DeviceUser
{
// Depends on IDevice
public DeviceUser(IDevice device)
{
}
}
public class DeviceUserUser
{
// Depends on DeviceUser, which depends
// on IDevice
public DeviceUserUser(DeviceUser user)
{
}
}
public class BadDecorator : IDevice
{
public BadDecorator(IDevice inner)
{
throw new DivideByZeroException("No can do!");
}
}
Contextual Exceptions
Originally, StructureMap used the System.Reflection.Emit classes to create dynamic assemblies on the fly to call constructor functions and setter properties for better performance over reflection alone. Almost by accident, having those generated classes made for a decently revealing stack trace when things went wrong. When I switched StructureMap to using dynamically generated Expression‘s, I got a much easier model to work with for me inside of StructureMap code, but the stack trace on runtime exceptions became effectively worthless because it was nothing but a huge series of nonsensical Lambda classes.
As part of the effort for StructureMap 3, we’ve made the Expression building much, much more sophisticated to create a contextual stack trace as part of the StructureMapException message to explain what the container was trying to do when it blew up and how it got there. The contextual stack can tell you, from inner to outer steps like:
- The signature of any constructor function running
- Setter properties being called
- Lambda expressions or Func’s getting called (you have to supply the description yourself for the Func, but SM can use an Expression to generate a description)
- Decorators
- Activation interceptors
- Which Instance is being constructed including the description and any explicit name
- The lifecycle (scoping like Singleton/Transient/etc.) being used to retrieve a dependency or the root Instance
So now, let’s say that we have this container configuration that experienced StructureMap users know is going to fail when we try to fetch the DeviceUserUser object:
[Test]
public void no_configuration_at_all()
{
var container = new Container(x => {
// Notice that there's no default
// for IDevice
});
// Gonna blow up
container.GetInstance<DeviceUserUser>();
}
will give you this exception message telling you that there is no configuration at all for IDevice.
One of the things that trips up StructureMap users is that in the case of having multiple registrations for the same plugin type (what you’re asking for), StructureMap has to be explicitly told which one is the default (where other containers will give you the first one and others will give you the last one in). In this case:
[Test]
public void no_configuration_at_all()
{
var container = new Container(x => {
// Notice that there's no default
// for IDevice
});
// Gonna blow up
container.GetInstance<DeviceUserUser>();
}
Running the NUnit test will give you an exception with this exception message (in Gist).
One last example, say you get a runtime exception in the constructor function of a decorating type. That’s way out of the obvious way, so let’s see what StructureMap will tell us now. Running this test:
[Test]
public void decorator_blows_up()
{
var container = new Container(x => {
x.For<IDevice>().DecorateAllWith<BadDecorator>();
x.For<IDevice>().Use<ADevice>();
});
// Gonna blow up because the decorator
// on IDevice blows up
container.GetInstance<DeviceUserUser>();
}
generates this exception.
Container.WhatDoIHave()
StructureMap has had a textual report of its configuration for quite a while, but the WhatDoIHave() feature gets some better formatting and the ability to filter the results by plugin type, assembly, or namespace to get you to the configuration that you want when you want it.
This unit test:
[Test]
public void what_do_I_have()
{
var container = new Container(x => {
x.For<IDevice>().AddInstances(o => {
o.Type<ADevice>().Named("A");
o.Type<BDevice>().Named("B").LifecycleIs<ThreadLocalStorageLifecycle>();
o.Type<CDevice>().Named("C").Singleton();
});
x.For<IDevice>().UseIfNone<DefaultDevice>();
});
Debug.WriteLine(container.WhatDoIHave());
Debug.WriteLine(container.WhatDoIHave(pluginType:typeof(IDevice)));
}
will generate this output.
The WhatDoIHave() report will list each PluginType matching the filter, all the Instance’s for that PluginType including a description, the lifecycle, and any explicit name. This report will also tell you about the “on missing named Instance” and the new “fallback” Instance for a PluginType if one exists.
It’s not shown in this blog post, but all of the information that feeds the WhatDoIHave() report is query able from the Container.Model property.
Container.AssertConfigurationIsValid()
At application startup time, you can verify that your StructureMap container is not missing any required configuration and generally run environment tests with the Container.AssertConfigurationIsValid() method. If anything is wrong, this method throws an exception with a report of all the problems it found (build exceptions, missing primitive arguments, undeterminable service dependencies, etc.).
For an example, this unit test with a missing IDevice configuration…
[Test]
public void assert_container_is_valid()
{
var container = new Container(x => {
x.ForConcreteType<DeviceUserUser>()
.Configure.Singleton();
});
// Gonna blow up
container.AssertConfigurationIsValid();
}
…will blow up with this report.
Show me the Build Plan!
I saved the best for last. At any time, you can interrogate a StructureMap container to see what the entire “build plan” for an Instance is going to be. The build plan is going to tell you every single thing that StructureMap is going to do in order to build that particular Instance. You can generate the build plan as either a shallow representation showing the immediate Instance and any inline dependencies, or a deep representation that recursively shows all of its dependencies and their dependencies.
This unit test:
[Test]
public void show_me_the_build_plan()
{
var container = new Container(x =>
{
x.For<IDevice>().DecorateAllWith<BadDecorator>();
x.For<IDevice>().Use<ADevice>();
});
var shallow = container.Model
.For<DeviceUserUser>()
.Default
.DescribeBuildPlan();
Debug.WriteLine("This is the shallow representation");
Debug.WriteLine(shallow);
var deep = container.Model
.For<DeviceUserUser>()
.Default
.DescribeBuildPlan(3);
Debug.WriteLine("This is the recursive representation");
Debug.WriteLine(deep);
}
generates this representation.
