This builds on the Rezolver.Microsoft.Extensions.DependencyInjection package to enable the integration of Rezolver into your Asp.Net Core site somewhat earlier in its startup phase.
Rezolver integration is available for both Asp.Net Core 1.1 and 2.0, with the Asp.Net Core 2.0 integration offering more flexibility as it allows you to perform configuration on the container(s) that are created before any registrations are made.
Asp.Net Core 2.x
As of version 2 of this package, the major/minor version of the package indicates the minimum version of the Asp.Net Core packages that is supported.
The latest version is
2.2 - which therefore supports Asp.Net Core 2.2.
After adding the package, change your
program.cs file so it looks like this:
So, at the most basic level you just call the @Microsoft.AspNetCore.Hosting.RezolverServiceProviderWebHostBuilderExtensions.UseRezolver* method, and that's enough.
Now we need to tell the Asp.Net Core stack that you want an @Rezolver.IRootTargetContainer to be created in order to construct the @Rezolver.ScopedContainer that will be used as the DI container.
The simplest way to do this is to add a single method (it can be empty) called
accepts a single parameter of the type xref:Rezolver.IRootTargetContainer.
[!NOTE] The @Rezolver.IRootTargetContainer interface was added in Rezolver 1.3.2 to accommodate covariance and is now the interface used for 'top-level' target containers. You can still declare your method as
ConfigureContainer<ITargetContainer>without losing any functionality - so projects which are upgrading from v2.0.x of the Hosting package will still work without any code changes.
[!NOTE] Note the call to
ConfigureServicesmethod. As the comment in the code says, you need this if you intend to use configuration callbacks in your
UseRezolvermethod call in
By adding that
ConfigureContainer method, a new Rezolver @Rezolver.ScopedContainer will be created and populated
IServiceCollection that contains all the service registrations for the application.
As the comment states, inside that method you can also perform more configuration or registrations on the
@Rezolver.IRootTargetContainer, such as decorators, expressions etc which are not supported by Microsoft's DI
abstractions, before the target container is passed to a new @Rezolver.ScopedContainer that will then be
used as the application's
And that's it - your application is configured.
UseRezolver Configuration call-back
If you've been reading some of the topics on this site - say, about contravariance
or lazy and eager enumerables then you'll have seen how we can use options
to control complex behaviours in Rezolver containers. That's what is shown in the alternative call
UseRezolver in the commented code in the
Program.cs sample above. You can also pass a configuration callback
that will be called to modify the @Rezolver.RezolverOptions that will be used to create both the
@Rezolver.IRootTargetContainer that forms the basis of the registrations, and the @Rezolver.ScopedContainer
that will ultimately be the root container for the application.
[!NOTE] Please note that lazy enumerables are currently switched off in Rezolver's integration with Asp.Net Core because of a mis-specification of a test by the Dependency Injection team.
The specification test is something which a DI container should pass if it's intending to be used with Asp.Net Core - and unfortunately there was one test that failed when Rezolver was using lazy enumerables - which is its default behaviour. An issue was raised on the Git repo and was fixed, but I then found another issue which I've yet to report.
Asp.Net Core 1.1
1.3 is the latest version of the package that supports Asp.Net Core 1.1. The setup is fundamentally
identical, except the
UseRezolver method does not accept any callbacks.
startup.cs is similar to what's required for Asp.Net Core 2.0 - except your
method should accept an
ITargetContainer - i.e.
and then Rezolver will be used as the container for your application.