An addictive .NET IoC container
netcoreapp3.1
support/testing (#1401).ResolveRequest
into a readonly struct
(#1397 - thanks @SergeiPavlov!).net8.0
target (#1401).Full Changelog: https://github.com/autofac/Autofac/compare/v7.1.0...v8.0.0
RegsiterTypes
filtering. This was an accidental behavior regression where the RegisterTypes
method wouldn't filter out non-registerable types.RegisterType<T>
and RegisterType(Type t)
will now throw when non-registerable types are provided, for example containerBuilder.RegisterType<IInterface>()
(you can't register interfaces - you can register things As<IInterface>
). This used to throw at container build time; now it throws at RegisterType
time and it has a more precise error message so you can handle these issues more proactively.Full Changelog: https://github.com/autofac/Autofac/compare/v7.0.1...v7.1.0
LifetimeScope.CreateSharedInstance
(thanks @botinko)Autofac.Features.OpenGenerics.OpenGenericServiceBinder.TryBindOpenGenericTypedService
(thanks @SergeiPavlov)Full Changelog: https://github.com/autofac/Autofac/compare/v7.0.0...v7.0.1
Version 7.0.0 is a major increment due to some changes in the target frameworks and some behavioral changes. We summarize these in the documentation, but included here as well:
required
will now be injected by default. As part of this, the default property injector using PropertiesAutowired()
will not inject properties marked required
. The documentation has more explanation with examples.
AssemblyLoadContext
by lifetime scope. A new method, BeginLoadContextLifetimeScope
, has been added that allows you to create a lifetime scope tied to a specific AssemblyLoadContext
. When the scope is disposed, Autofac will perform a best-effort release of all references to types from that context so the assemblies can be unloaded. The documentation explains this in greater detail.
Full Changelog: https://github.com/autofac/Autofac/compare/v6.5.0...v7.0.0
net50
no longer targeted. Autofac will still work with .NET 5 via the netstandard2.1
target, but we recommend you upgrade to a later, supported version of .NET.required
will now be injected by default. As noted above, required
properties will be injected. This is a behavioral change from Autofac 6.0.required
properties. Using PropertiesAutowired()
will ignore required
properties because it's assumed they must be set during construction rather than post-object-creation.RegisterGeneratedFactory
is obsolete. This feature has been replaced by the Func<X, Y, B>
built-in relationship and delegate factories.ILifetimeScope
has a new BeginLoadContextLifetimeScope
method. If you have mocks of ILifetimeScope
this method must now be implemented.Autofac.Core.ReflectionCacheSet
(#1341). This is part of an effort to support unloading AssemblyLoadContexts
associated with child scopes and enable better plugin support (#1324).IDecoratorContext
now extends IComponentContext
so decorator decisions can be made based on the constructed container (#1338, #1352).Full Changelog: https://github.com/autofac/Autofac/compare/v6.4.0...v6.5.0
WithMetadata
and generate metadata (#1299 - thanks @romerod!)IConstructorSelector
invocation is skipped (#1325)The new feature to be aware of here is the generic delegates for making lambda registrations easier (#1320, #1321). It makes resolving dependencies in lambdas more straightforward.
The old way meant injecting an IComponentContext
and resolving the dependencies manually.
builder.Register(
ctx =>
{
var dep1 = ctx.Resolve<IDependency1>();
var dep2 = ctx.Resolve<IDependency2>();
return new Component(dep1, dep2, "configuration-value");
});
That old way still works and is not deprecated. You can keep doing that.
However, you can now skip the manual resolutions and just provide the dependencies as the parameters to the lambda:
builder.Register(
(IDependency dep1, IDependency dep2) =>
new Component(dep1, dep2, "configuration-value"));
If you need both the context and dependencies for advanced cases, you can do that, too.
builder.Register(
(IComponentContext ctx, IDependency dep1) =>
{
var dep2 = ctx.Resolve<IDependency2>(new NamedParameter("p", "someValue"));
new Component(dep1, dep2, "configuration-value");
});
OnlyIf
clause. (#1235, #1272)value
to inject by name as that's a reserved word in property setter methods. (#1275)IAsyncDisposable
instances that have not been activated are correctly disposed when the scope is disposed. (#1285)TryResolveNamed
and TryResolveKeyed
. (#1263, #1287 - thanks @v0idzz!)Resolved issues / PRs:
RegisterAssemblyOpenGenericTypes
to do assembly scanning and register open generics! (#1232 / #1246)ConfigurePipeline
to IComponentRegistration
to allow easier registration pipeline modification (related to #1211)ConcurrentBag
on different platforms resulted in a memory leak in OnActivated
usage; we now flush the ConcurrentBag
of registrations on disposal of a lifetime scope (#1257)ref
parameters.Version 6.0.0 represents a major update in the Autofac internals. While every effort has been made to ensure code using version 5.x will continue to work exactly as you expect, you should be aware of the breaking changes and test things out. For the majority case, things should just continue to work; breaking changes are primarily in more rare advanced usage scenarios.
Check out the release blog post! Also, the documentation has been updated and is ready!
:warning: Starting with Autofac 6.0, we now only target
netstandard20
andnetstandard21
; we have removed the explicit target fornet461
.The impact to you is that, while Autofac will still work on .NET Framework 4.6.1 as it did before, we strongly encourage you to upgrade to .NET Framework 4.7.2 or higher, as per the .NET Standard Documentation, to avoid any of the known dependency issues when using .NET Standard packages in .NET Framework 4.6.1.
There are a lot of new features, but the big ones are here. Other features and fixes will be outlined in the Issues section, below.
DiagnosticSource
diagnostics. The core Autofac package ships with a default text-based diagnostic tracer and the new Autofac.Diagnostics.DotGraph
package adds graphic tracing using DOT and Graphviz.The following issues have been addressed in v6:
Lazy<T>
should now work.Autofac.Diagnostics.DotGraph
package.ILifetimeScope.LifetimeScopeEnding
event is raised and completes before the scope is disposed.ContainerBuilder
is now sealed
.DiagnosticSource
.Autofac.Pooling
package.We'll do our best to keep an upgrade guide with breaking changes available and up to date. We're pretty sure we caught them all, but if you find a gotcha, let us know on the Documentation repo.
A summary of the breaking changes is as follows:
net461
is no longer targeted; Autofac now targets netstandard2.0
and netstandard2.1
.log4net
module example is shown in the documentation, this now needs to happen through middleware. The log4net
module example has been updated to show you the new way it works.
RegistrationBuilder.RegistrationData
no longer exposes activation handlers. The CoreEventMiddleware
is the source of events now.IComponentRegistration
no longer exposes activation events. The CoreEventMiddleware
is the source of events now.IConstructorSelector
implementations need to switch to use BoundConstructor
instead of ConstructorParameterBinding
.IRegistrationSource
implementations need to update the RegistrationsFor
method signature.IInstanceActivator
implementations no longer have an ActivateInstance
method and instead have a ConfigurePipeline
method.IComponentRegistry
no longer supplies a DecoratorsFor
method to check decorators. Use IComponentRegistry.ServiceMiddlewareFor
instead.ResolveRequest
constructor now takes a ServiceRegistration
instead of an IComponentRegistration
.ContainerBuilder
is now sealed
.
DiagnosticSource
and related entities we (and ASP.NET Core, and others) use for diagnostics is not CLS compliant so Autofac can't be, either.We're working hard to get all of the ~25 integration packages pushed to NuGet as quickly as we can, so please bear with us while we get these sorted.
Some of this is sitting in branches ready to go, other things need to be done now that we have this core package out there.
If your favorite integration isn’t ready yet, we’re doing our best. Rather than filing "When will this be ready?" issues, consider pull requests with the required updates.