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.