Bump Autofac.Extensions.DependencyInjection from 7.2.0 to 8.0.0

[dependabot[bot]]

Bumps Autofac.Extensions.DependencyInjection from 7.2.0 to 8.0.0.

Release notes

Sourced from Autofac.Extensions.DependencyInjection's releases.

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

... (truncated)

Commits

• c715e5f Merge branch 'develop'
• 9cc5053 Upgrade dependencies - Autofac 6.4.0
• bf61f92 Merge pull request #104 from autofac/feature/compat-test
• 468a5c8 Minor cleanup on registration.
• 65e1afc Always register as IServiceProvierIsService.
• 4473558 Integration tests for different framework versions.
• e63250d Remove conditional compilation, target M.E.DI 6.
• af98634 Switch to file-scoped namespaces.
• 48ff016 Merge pull request #102 from autofac/issue-83
• 1c83d66 Fix #83: IServiceScopeFactory is singleton, scopes are flat.
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)