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
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.
- 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
ObjectFactoryfacade over the application
- 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(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.
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
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.*.
[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.,
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
ProfileManagerarchitecture is all gone. The new
PipelineGraphimplementations just wrap one or more
PluginGraphobjects, so there’s vastly less data structure shuffling gone on internally.