Releases: autofac/Autofac
v7.0.0
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:
New Features
- Properties marked
requiredwill now be injected by default. As part of this, the default property injector usingPropertiesAutowired()will not inject properties markedrequired. The documentation has more explanation with examples. - Ability to isolate
AssemblyLoadContextby lifetime scope. A new method,BeginLoadContextLifetimeScope, has been added that allows you to create a lifetime scope tied to a specificAssemblyLoadContext. 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. - Documentation links in exception messages. Common Autofac exceptions now include links to our online documentation to help you understand what the exceptions mean and how to troubleshoot them.
Issues and PRs
- Add documentation links to common exceptions by @tillig in #1359
- Fix #1360: Unify the "no constructors found" reporting by @tillig in #1362
- Add support for required properties by @alistairjevans in #1364
- Mark RegisterGeneratedFactory obsolete by @tillig in #1366
- Isolate service information computed in child scopes from the parent scope by @alistairjevans in #1350
Full Changelog: v6.5.0...v7.0.0
Breaking Changes
net50no longer targeted. Autofac will still work with .NET 5 via thenetstandard2.1target, but we recommend you upgrade to a later, supported version of .NET.- Properties marked
requiredwill now be injected by default. As noted above,requiredproperties will be injected. This is a behavioral change from Autofac 6.0. - Default property injection ignores
requiredproperties. UsingPropertiesAutowired()will ignorerequiredproperties because it's assumed they must be set during construction rather than post-object-creation. RegisterGeneratedFactoryis obsolete. This feature has been replaced by theFunc<X, Y, B>built-in relationship and delegate factories.ILifetimeScopehas a newBeginLoadContextLifetimeScopemethod. If you have mocks ofILifetimeScopethis method must now be implemented.
v6.5.0
- Reflection caches have moved to a central location
Autofac.Core.ReflectionCacheSet(#1341). This is part of an effort to support unloadingAssemblyLoadContextsassociated with child scopes and enable better plugin support (#1324). IDecoratorContextnow extendsIComponentContextso decorator decisions can be made based on the constructed container (#1338, #1352).- Fix memory leak regression (#1353 - Thanks @botinko!)
Full Changelog: v6.4.0...v6.5.0
v6.4.0
- Fix typos in exception messages (#1301, #1302, #1323)
- Enable open generic assembly scanning to use
WithMetadataand generate metadata (#1299 - thanks @romerod!) - Package targets .NET 6 TFM (#1306)
- README included in NuGet package (#1295, #1308)
- Symbols published in .snupkg format (#995, #1309)
- Fix issue where changing type parameter names caused generic resolution to fail (#1315, #1316)
- Added generic delegates to make registering lambda components easier (#1320, #1321)
- Optimization of reflection activation for components that only have one constructor - specifically, if there is only one constructor on a component, that constructor is cached as the one for activation and
IConstructorSelectorinvocation 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");
});v6.3.0
- Modules can now be registered conditionally using an
OnlyIfclause. (#1235, #1272) - Delegate factories will no longer allow parameters with the name
valueto inject by name as that's a reserved word in property setter methods. (#1275) IAsyncDisposableinstances that have not been activated are correctly disposed when the scope is disposed. (#1285)- There are now generic overloads for
TryResolveNamedandTryResolveKeyed. (#1263, #1287 - thanks @v0idzz!) - Fixed performance regression in assembly scanning with respect to compiler generated types. (#1289 - thanks @RogerKratz!)
v6.2.0
Resolved issues / PRs:
- #215: You can now use
RegisterAssemblyOpenGenericTypesto do assembly scanning and register open generics! (#1232 / #1246) - #1211: Added
ConfigurePipelinetoIComponentRegistrationto allow easier registration pipeline modification (related to #1211) - #1238: Static and constructors are no longer considered for reflection (#1239)
- #1252: Behavior of
ConcurrentBagon different platforms resulted in a memory leak inOnActivatedusage; we now flush theConcurrentBagof registrations on disposal of a lifetime scope (#1257)
v6.1.0
- Added direct support for .NET 5.
- Internals update to allow more dynamic reconfiguration of resolve pipelines.
- Fix #1204: Decorated instances marked with AllowCircularDependencies should now get properties injected correctly.
- Fix #1226: Constructor binders correctly detect
refparameters.
v6.0.0
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!
⚠️ Starting with Autofac 6.0, we now only targetnetstandard20andnetstandard21; 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.
New Features
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.
- Pipelines: This is the major change in Autofac v6 - all resolution activities internally now flow through pipelines, similar to how ASP.NET Core requests flow through pipelines. This allows for better customization in how things get resolved as well as enabling support for more new features.
- Composites: The composite pattern allows a collection of objects to be treated as though it's a single object.
- Diagnostics: Autofac v6 adds support for
DiagnosticSourcediagnostics. The core Autofac package ships with a default text-based diagnostic tracer and the newAutofac.Diagnostics.DotGraphpackage adds graphic tracing using DOT and Graphviz. - Generic Delegate Registrations: You can now register an open generic associated with a delegate/lambda expression, allowing you to provide a custom factory to resolve generics just like you do with non-generic types.
- Concurrency Performance Improvements: We focused a lot on performance and have removed a lot of locking. In some highly-concurrent cases, we've seen a 4x speed increase.
Issues and PRs
The following issues have been addressed in v6:
- #718: Circular dependency support using property injection and relationships like
Lazy<T>should now work. - #788: DOT graph support has been added via the
Autofac.Diagnostics.DotGraphpackage. - #798 / #1148: Circular dependency handling uses the .NET runtime to check stack depth when checking for circular dependencies rather than using a fixed stack depth.
- #828: The
ILifetimeScope.LifetimeScopeEndingevent is raised and completes before the scope is disposed. - #970: The composite pattern is now supported.
- #1069 / #1172: Core Autofac events are now async-friendly.
- #1120 / #1128:
ContainerBuilderis nowsealed. - #1123: Explicitly injected properties can now be declared using an expression.
- #1126 / #1169: Diagnostics are handled via
DiagnosticSource. - #1162: A new "pooled" lifetime type has been added via the
Autofac.Poolingpackage.
Breaking Changes
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:
net461is no longer targeted; Autofac now targetsnetstandard2.0andnetstandard2.1.- Activation events are no longer exposed - this all happens through middleware now.
- If you were using an Autofac module to attach to activation events and inject parameters, similar to the way the
log4netmodule example is shown in the documentation, this now needs to happen through middleware. Thelog4netmodule example has been updated to show you the new way it works. RegistrationBuilder.RegistrationDatano longer exposes activation handlers. TheCoreEventMiddlewareis the source of events now.IComponentRegistrationno longer exposes activation events. TheCoreEventMiddlewareis the source of events now.
- If you were using an Autofac module to attach to activation events and inject parameters, similar to the way the
- Interface changes:
IConstructorSelectorimplementations need to switch to useBoundConstructorinstead ofConstructorParameterBinding.IRegistrationSourceimplementations need to update theRegistrationsFormethod signature.IInstanceActivatorimplementations no longer have anActivateInstancemethod and instead have aConfigurePipelinemethod.IComponentRegistryno longer supplies aDecoratorsFormethod to check decorators. UseIComponentRegistry.ServiceMiddlewareForinstead.- The
ResolveRequestconstructor now takes aServiceRegistrationinstead of anIComponentRegistration.
ContainerBuilderis nowsealed.- Autofac is no longer marked CLS compliant. The Microsoft
DiagnosticSourceand related entities we (and ASP.NET Core, and others) use for diagnostics is not CLS compliant so Autofac can't be, either.
Still Todo
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.
v5.2.0
Fixes:
- #1108:
OnActivating()andOnActivated()should now act more consistently with decorators than it previously did. - #1113: Lifetime scope discrepancies between different decorated implementations should no longer cause problems with
IEnumerable<T>resolutions.
Thanks to @VonOgre for a ton of great work on this one.
v5.1.4
v5.1.3
Issues resolved:
- #1089: Owned instances now allow for async disposal.
- #1094:
InstancePerOwnednow works correctly with keyed registrations. - #1099: ACTNARS can now resolve generic types with abstract type arguments.
- #1102: Provided instances should now have
OnReleasecalled when the container is disposed regardless of whether the instances themselves were resolved from the container. - #1107: The
new()generic type constraint should now be correctly handled in open generic registrations.