This is a minor patch release which adds SourceLink support to the three published packages, as well as removes the
net461 TFM from the Rezolver package (because it's not needed).
Also, the Asp.Net Core packages have been bumped to version v2.1 with dependencies on Asp.Net Core updated v2.1 (yes, we did run the integration tests before doing that!).
Bugfix release targeting three specific issues:
- #53 Contravariant Singletons not working quite as expected
- #72 Singletons matched covariantly don't honour singleton pattern
- #73 Nested generic with multiple parameters throws exception
#73, however, is a critical bug that prevents Rezolver from being able to work with complex multi-parameter generics where the outer type arguments are mapped to parameters that are nested inside a base or interface's generic parameters, eg:
class Foo<T, U> : IFoo<IBar<T, U>>
Single-parameter generics were not affected, nor were generics where the interfaces/bases had the same number of parameters.
In the above case, attempting to register the type
Foo<,> against the interface type
IFoo<IBar<,>> would result in an
This releases fixes that.
v1.3.2 is primarily a 'new feature' release. There were some bugs closed with this release, but they were just bugs that had been raised on the new stuff.
In many new features were added to this release. The documentation for these new features is already available on the documentation site - you'll find links below.
This release also updates the two (Asp).Net Core integration packages to 2.0.1
- #62 - Generic Covariance
- Mixed Variance
- #64 - Enumerable Projections
- #67 - Targeting specific constructors for open generics
- #66 - List/Collection Member Bindings
- Per-member bindings fluent API
- Issue #57 - Singletons in
IEnumerable<>created a second instance for objects which were also requested individually. So if the last-registered target for
Foowas a singleton, the single instance obtained when resolving
Foowas not the same as the last instance in an
- Issue #58 - Same as above, but for scoped objects in a scope.
New features & changes
- Issue #59 - All auto-generated enumerables will now return objects in registration order regardless of whether the original registration was against an open or closed generic. Could also call this a bug, although the original behaviour of returning enumerables in order of least generic to most generic was by-design.
- Issue #60 - All three packages now have
.netstandard2.0as a target platform. In the case of the Asp.Net Core extension packages, it's now the only platform they target.
- Test suites have all been updated to use xUnit 2.3 with its .Net Standard 2.0 support: tests now discover and run in approx 1/4 of the time they took before!
- Rezolver 1.3.1
- Rezolver.Microsoft.Extensions.DependencyInjection 2.0.0
- Rezolver.Microsoft.AspNetCore.Hosting 2.0.0
In future the idea is that we'll keep the DI and Hosting packages' major versions aligned with the .Net Core version numbers. Let's see if we can stick to it!
Bunch of new features have been added in this release, along with a few bugfixes.
Please note - When issues are linked, any implementation notes on those issues are likely to be draft only. Focus on the feature not the implementation
Where possible, links are included to the official documentation site so you can immediately get up and running with the new functionality.
.Net Core 2.0 and Asp.Net Core 2.0
Because the core library (Rezolver.dll) targets .Net Standard 1.1 - .Net Core 2.0 applications and libraries will also be able to use it without fuss.
However, the Asp.Net Core integration packages have not yet been tested with Asp.Net Core 2.0.
They might well work, but I need to try them out on test applications and get the specification tests project updated. Issue #56 is tracking that work. If changes need to be made to either the DependencyInjection extension package or AspNetCore Hosting Integration package, then they'll be published as v2.0 packages ASAP.
Here's a rundown of the new features that have been added in 1.3
- (#26) - Enumerables of generic types (backed either by open generic or closed generic registrations) are now more 'natural' - you can now mix registrations of
IFoo<Bar>and get an enumerable containing all objects which match the requested type.
- Lazy & Eager Enumerables are now supported. All enumerables are now lazy by default but you can enable eager enumerables either globally or per-service-type very easily.
- (#46) - Open generics with generic constraints are now supported - including in enumerables
- (#44) - Contravariant Type Parameters are now supported. For single-resolve operations, Rezolver will locate the least derived registration (i.e. closest match) for a requested type per contravariant rules.
- Nested contravariance is also supported - i.e. contravariance for
- Enumerables of contravariant types will include all registrations that match, in order of least derived to most derived.
- Contravariance can be disabled globally, per-generic or per-type (when passed as an argument to a contravariant parameter)
- Nested contravariance is also supported - i.e. contravariance for
- (#52) - Decorator Delegates supported for all types excluding open generics. Decorator delegates allow you decorate types which don't have constructors or which can't be subclassed - e.g. Arrays, Value Types, Delegates etc.
Rezolver can now inject arrays and common list and collection types. The functionality builds on the support for
IEnumerable<T> to produce collections with the same contents as an enumerable. Read the documentation for each, which includes also how to disable the behaviour, here:
- (#51) - Array Injection
- (#37) -
- (#37) -
- #42 - When using an
OverridingContainer, enumerables would replace the inherited container's enumerable. Now it extends it.
- #43 - Same as above, but at the
As mentioned above, verification of Asp.Net Core 2.0 integration is next on the list.
After that, we'll be looking at auto injection of
Func<[Tn, ]*, T> delegate types,
Lazy<T> injection and, possibly, auto-registration of concrete types - e.g. request
Bar and have the container automatically register it if it's non-abstract with a reachable constructor.
This release contains a few breaking changes; & a bunch of bugfixes, new APIs and performance improvements.
It's not the last release of 1.2, as I have more planned, but I feel the current 'Ready For Release' issue list has reached critical mass and it's time to get them out there :)
There are no binaries for this release - the packages are available on nuget:
- Rezolver IOC Package
- Rezolver MS DI Extensions Package
- Rezolver Asp.Net Core Hosting Extensions Package
- #25 - You could only call
RegisterDecoratoron an object which implemented
- #27 - Bug that prevented mixing of open and closed generic decorators
- #28 - Transient/Scoped disposable dependencies of Singletons are now guaranteed to have the same lifetime as the singleton.
- For #25 the
ITargetContainerOwnerinterface has been subsumed into
ITargetContainer, so now all target containers can contain other target containers via the
RegisterContainermethod. If you had any references to it, simply replace it with
- #33 -
ICompileContextProviderhas been subsumed into
CreateCompileContextAPI was moved into
ITargetCompilerunchanged - again, just replace references for one to another.
- #34 -
ChildTargetContainerhas been renamed to
OverridingTargetContainerbecause it matches more closely what it actually does. This was also in response to #25, since all
ITargetContainerobjects can now have others registered inside them (and therefore technically all target containers can be 'child' containers).
- (See #32 below) - Can no longer switch on/off auto-resolving
IEnumerable<>via a constructor parameter on
TargetContainer- this is now controlled by a Target Container Behaviour.
- #29 -
IResolveContextinterface added (implemented by
ResolveContext). Provides flexibility in factory methods and during compilation. Overhauled the way in which child contexts are created - adding a
Newmethod to the interface so it's easy to reuse an existing context to resolve a new type without needing to worry about flowing the current container/scope as the context will do that for you.
- #6 - Now fully complete.
Target.ForTypeet al is now the only static API for creating targets. All
Register*APIs match up, and the old generic extension methods have been obliterated as per 1.1s obsolete notices.
- #32 - Behaviours for conntainer and target containers. Similar to the
IConfigureOptions<>mechanism used by Asp.Net Core et al:
ITargetContainerBehaviourgets called when a new
TargetContainer(or derivative) is created. The idea is that the behaviour can add registrations to the behaviour which alter how types are resolved. The automatic resolving of
IEnumerable<T>has been reimplemented using this. In the future, Auto Func, Lazy plus more besides will also be implemented in this way.
IContainerBehavioursimilar to above, but specifically for new containers. This is currently used to control the compilation strategy (and will be extended in the next few sub releases and/or in 1.3) and the default member injection strategy used by a container. Again, much more is planned for this in the future.
- #7 - Default member injection behaviours are now controlled by container behaviours (see before) but in addition to this we now have a bunch of static singletons for common strategies, in the
MemberBindingBehaviourstatic class. For more, see the updated member injection documentation.
- #13 - This is an internal optimisation to speed up the process of compiling expressions from targets.
This will (should!) be the last 1.1 release, there will be more commits to the repository as I add more documentation, but there'll be no more package updates.
Issues closed in this release:
- #16 -
Resolve<>operations - might add
IContainerinterface to it in the future)
- #17 -
ExpressionTargetbreaking changes to Create/Register API - mainly stuff being moved or removed, some stuff soft-obsoleted and will become illegal in 1.2
- #10 - Documentation for
- #9 - Documentation for Objects as Services
Also have laid the groundwork for #6 - The suggestion to do away with the global generic extensions from @n-sidorov. The new
Target.For*** APIs are there, and the ITarget-related extensions have been moved there also.
1.2 will see all nasty extension methods being made compiler errors, with 1.3 seeing them removed.
25% speed bump from previous version after adding Rezolver to our fork of Daniel Palme's IOCPerformance benchmark and doing some perf analysis.
Still some way to go to reach optimum speed; but in most cases Rezolver holds its own, reaching around Top 10 for the basic tests. Advanced tests are scuppered primarily by child containers because of the dynamic compilation always executing. Have a plan for that. Also, singletons can be faster, as can the compilation itself.