Breaking Changes

• Drop .NET 6 and .NET 7 targeting.
• Add .NET 10 target.
• Change the AnyKey support to use the new native support for AnyKey in core Autofac - this removes some of the custom internals used to support keyed services and moves that to core Autofac.

Other Changes

• Updated benchmark suite to test more scenarios.
• Executed some targeted performance improvements in the "glue" that maps M.E.DI behaviors to Autofac.
• Updated Autofac dependency to v9.1.0.

Full Changelog: v10.0.0...v11.0.0

Breaking Changes

All instance dependencies are now considered ExternallyOwned which means if you register an object instance in the dependency injection container through this package, when you dispose of the container it will not dispose of the provided instance. This is different than default Autofac behavior. Autofac normally assumes control of registered instances, where the Microsoft DI container does not. This change only affects instances registered using the Microsoft syntax and then populated into Autofac; it does not change the underlying Autofac container.

public class Startup
{
  public void ConfigureServices(IServiceCollection services)
  {
      // The instance `item` here WILL NOT be disposed when the container is disposed
      // because it's registered using Microsoft syntax and will be imported into Autofac.
      var item = new MyDisposableItem();
      services.AddSingleton(item);
  }

  public void ConfigureContainer(ContainerBuilder builder)
  {
      // The instance `item` here WILL be disposed when the container is disposed
      // because it's registered using Autofac syntax directly with Autofac.
      var item = new MyDisposableItem();
      builder.RegisterInstance(item);
  }
}

Additional Changes

• Optimization for reflection-activated components to avoid adding a parameter in the resolve path if possible. (@alistairjevans #119)
• Updated Autofac dependency to 8.1.0.

Full Changelog: v9.0.0...v10.0.0

Breaking Changes

• Removed support for netcoreapp3.1 and net5.0
• Updated minimum core Autofac to 8.0.0, which includes similar target support updates. See release notes for core Autofac.

Additional Changes

• Added keyed service support (IKeyedServiceProvider, IServiceProviderIsKeyedService, support for AnyKey) to match Microsoft.Extensions.DependencyInjection feature updates for .NET 8. (#115)

Full Changelog: v8.0.0...v9.0.0

BREAKING CHANGE: IServiceScopeFactory is now a singleton and child scopes are flat, not hierarchical. Based on #83 and dotnet/runtime#67391, the IServiceScopeFactory is now registered as a singleton. Any scope you create from it is a peer, not a hierarchy like you might see in core Autofac. Even if you create a scope from a scope, it'll use the singleton factory under the covers and all scopes will be peers.

If you are using scopes to isolate units of work, be aware that this breaks the parent/child lifetime scope relationship.

// Based on an IServiceProvider...
IServiceProvider provider = CreateServiceProvider();

// You might want to create nested scopes to track work...
var unitOfWorkOutside = provider.CreateScope();

// And later have a sub-unit-of-work scope inside that...
var unitOfWorkInside = unitOfWorkOutside.ServiceProvider.CreateScope();

// But they're NOT RELATED! They don't share a resolution hierarchy
// so cached instances in the outer scope won't be seen in the inner
// scope. You can dispose that "outer scope" without affecting the
// "inner scope" at all because they're peers, not parent/child.
unitOfWorkOutside.Dispose();

// Still works because it's not a hierarchy!
unitOfWorkInside.ServiceProvider.GetRequiredService<MyService>();

If you need to create hierarchical scopes, you will need to use native Autofac constructs.

// Based on an IServiceProvider...
IServiceProvider provider = CreateServiceProvider();

// You'll need to get an Autofac lifetime scope.
var autofacScope = provider.GetService<ILifetimeScope>();

// Use the Autofac constructs to create hierarchical lifetimes.
var unitOfWorkOutside = autofacScope.BeginLifetimeScope();

// And later have a sub-unit-of-work scope inside that...
var unitOfWorkInside = unitOfWorkOutside.BeginLifetimeScope();

// Now they're related so they'll share a hierarchy. If you dispose the outer scope...
unitOfWorkOutside.Dispose();

// ...stuff in the inner scope will not resolve because you disposed its parent.
unitOfWorkInside.Resolve<MyService>();

BREAKING CHANGE: The Microsoft.Extensions.DependencyInjection dependency is now set at 6.0.0 for all target frameworks. M.E.DI v6 is compatible with all the frameworks Autofac.Extensions.DependencyInjection targets, so your application should be able to allow this through transitive dependencies. However, if you have a hard requirement to stay on an older version of M.E.DI for some reason, you won't be able to take this upgrade.

Autofac.AspNetCore.Multitenant has been updated to account for these changes. If you are using the multitenant ASP.NET Core support and update Autofac.Extensions.DependencyInjection, also be sure to take the latest Autofac.AspNetCore.Multitenant package.

The Autofac core version reference has also been updated to 6.4.0 to make sure fixes and features from the latest are included by default. This should not be a breaking change.

Full Changelog: v7.2.0...v8.0.0

What's Changed

• NET6 and IServiceProviderIsService support. by @alistairjevans in #91

Full Changelog: v7.1.0...v7.2.0

• Fixes #82 - Allow the ContainerBuilderOptions to be provided when using the AutofacServiceProviderFactory

Resolves #11: Assembly was incorrectly delay-signed for release. The assembly is now properly signed.

c247e60

This 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.

[ PR #948 - thanks @weelink !]

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 an IndexOutOfRangeException 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.