Changelog History
Page 1
-
v6.1.0 Changes
December 04, 2020- β 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
ref
parameters.
-
v6.0.0 Changes
September 28, 2020π 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 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.
π 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
DiagnosticSource
diagnostics. The core Autofac package ships with a default text-based diagnostic tracer and the newAutofac.Diagnostics.DotGraph
package 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.DotGraph
package. - π #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.LifetimeScopeEnding
event 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:
ContainerBuilder
is 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.Pooling
package.
π₯ 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:
net461
is no longer targeted ; Autofac now targetsnetstandard2.0
andnetstandard2.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
log4net
module example is shown in the document, this now needs to happen through middleware. Thelog4net
module example has been updated to show you the new way it works. RegistrationBuilder.RegistrationData
no longer exposes activation handlers. TheCoreEventMiddleware
is the source of events now.IComponentRegistration
no longer exposes activation events. TheCoreEventMiddleware
is 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 :
IConstructorSelector
implementations need to switch to useBoundConstructor
instead ofConstructorParameterBinding
.IRegistrationSource
implementations need to update theRegistrationsFor
method signature.IInstanceActivator
implementations no longer have anActivateInstance
method and instead have aConfigurePipeline
method.IComponentRegistry
no longer supplies aDecoratorsFor
method to check decorators. UseIComponentRegistry.ServiceMiddlewareFor
instead.- The
ResolveRequest
constructor now takes aServiceRegistration
instead of anIComponentRegistration
.
ContainerBuilder
is nowsealed
.
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 Changes
May 11, 2020π 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.
- #1108:
-
v5.1.4 Changes
April 27, 2020 -
v5.1.3 Changes
April 23, 2020Issues resolved:
- #1089: Owned instances now allow for async disposal.
- #1094:
InstancePerOwned
now works correctly with keyed registrations. - #1099: ACTNARS can now resolve generic types with abstract type arguments.
- π #1102: Provided instances should now have
OnRelease
called 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.
-
v5.1.2 Changes
February 16, 2020- π Fix #1085 - StackOverflowException thrown with circular property dependencies
-
v5.1.1 Changes
February 13, 2020Replaced missing constructor on
ResolveRequest
to fix accidental break in 5.1.0. -
v5.1.0 Changes
February 12, 2020- β‘οΈ Update NuGet package to use new icon
- Cache the implementations of a ServiceRegistrationInfo until the implementations change
- π Fix #963 - Partially decorating service implementing multiple interfaces throws
- π Fix #1073 - Always lock when getting an initialized ServiceRegistrationInfo
- π Fix #1077 - Keep raising 'Registered' and 'RegistrationSourceAdded' events after the 'ComponentRegistry' has been built
-
v5.0.0 Changes
January 27, 2020This is the first major-version release we've had in about three years (Autofac 4.0 was released in August 2016). There are some breaking changes and new features you should know about as you decide your upgrade strategy.
π₯ Breaking Changes
Framework Version Targeting Changes
π Starting with Autofac 5.0 there is no longer support for .NET 4.5.x. .NET 4.5.2, the last release in that line, follows the same support lifecycle as Windows Server 2012 R2 which ended mainstream support in September 2018.
Autofac 5.0 now targets:
netstandard2.0
netstandard2.1
net461
Containers are Immutable
β‘οΈ The container registry can no longer be updated after it has been built.
β‘οΈ The
ContainerBuilder.Update
method was marked obsolete in November 2016 and there has been a robust discussion to answer questions about how to get the container contents to adjust as needed at runtime.β‘οΈ
ContainerBuilder.Update
has now been removed entirely.π If you need to change registration behavior at runtime, there are several options available to you including the use of lambdas or child lifetime scopes. See this discussion issue for examples and ideas. We will work to add some documentation based on this issue.
Lifetime Scope Disposal Hierarchy Enforced
Resolving a service from a lifetime scope will now check all parent scopes to make sure none of them have been disposed.
If you dispose a lifetime scope, all children of that lifetime scope will stop resolving objects. In cases like this you'll start getting
ObjectDisposedException
instead.β If you have a custom application integration that involves creating/destroying lifetime scopes (e.g., custom per-request support) this may cause issues where proper disposal ordering is not occurring.
π [Fixes #1020; PR #1061 - thanks @alistairjevans!]
Prevent Auto-Injecting onto Static Properties
Autofac will no longer do property injection on static properties when auto-wiring of properties is enabled.
π If your application behavior depends on static property injection you will need to do some additional work like adding a build callback to populate the property.
π [Fixes #1013; PR #1021 - thanks @alistairjevans!]
π Features and Fixes
π Asynchronous Disposal Support
Autofac lifetime scopes now implement the
IAsyncDisposable
interface so they can be disposed asynchyronously.await using (var scope = container.BeginLifetimeScope()) { var service = scope.Resolve\<ServiceThatImplementsIAsyncDisposable\>(); // When the scope disposes, any services that implement IAsyncDisposable will be// Disposed of using DisposeAsync rather than Dispose.}
[PR #1037 - thanks @alistairjevans!]
Nullable Reference Type Annotations
π Autofac is now build using nullable reference type annotations. This allows developers to get sensible compiler warnings if they opt-in, thus avoiding
NullReferenceException
instances where possible.[PR #1037 - thanks @alistairjevans!]
π Build Callbacks in Lifetime Scopes
π One method of running code at container build time is by registering a build callback. Previously this only worked at the container level, but we've added the ability to register callbacks that run at lifetime scope creation as well.
var scope = container.BeginLifetimeScope(cfg =\>{ cfg.RegisterBuildCallback(scope =\> { /\* do something \*/ }); });
The callback will be invoked just prior to
BeginLifetimeScope
exiting, after any startable components are instantiated.π [Fixes #985; PR #1054 - thanks @alistairjevans!]
π Other Fixes
- π #1030:
ParameterFilterAttribute
now checks to see if it can resolve a parameter before doing it. (PR #1053 - thanks @RaymondHuy!) - #1040:
IsRegistered
no longer throws anIndexOutOfRangeException
when called on an open generic type. (PR #1045 - thanks @RaymondHuy!) - #1041:
PropertiesAutowired
now works with the new decorator syntax. (PR #1043 - thanks @RaymondHuy!) - π¦ #1057: NuGet package icon is now embedded in the package. (PR #1054 - thanks @alistairjevans!)
- π Performance improvements:
- Improved locking during component registration (PR #948 - thanks @weelink!)
IsGenericTypeDefinedBy
caching for generic type info (PR #1038 - thanks @alistairjevans!)
Still TODO
Now that Autofac 5.0 is out, there is still a lot to do. We'll be working on these things as fast as we can:
- β‘οΈ Updating integration packages we support so they ensure compatibility with Autofac 5.
- π Updating the documentation to reflect the above changes.
π¦ 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.
-
v4.9.4 Changes
August 15, 2019