Downgrade 7.0.0 Microsoft extensions packages to 6.0.0

[asimmon]

The Microsoft.Bcl.AsyncInterfaces package is not required for .NET 6 and later. By multi-targeting both netstandard2.0 and net6.0, we can add the dependency to Microsoft.Bcl.AsyncInterfaces only for netstandard2.0, while removing an unnecessary dependency on .NET 6 and later. Microsoft does the same for the DependencyInjection.Abstractions extensions package and many others (see dependencies tab).

Also, targeting a Microsoft extension library with version 7.x can be quite annoying for several projects that are using version 6.x of these extensions libraries. Usually, these extensions packages are initially released on the same day than a major version of the framework. So 6.0.0 packages came out for .NET 6, and 7.0.0 packages came out for .NET 7. Also, the end-of-life (EOL) of these packages is bound to the EOL of the corresponding .NET framework. We saw that with .NET 5. So 6.x Microsoft extension libraries will have a longer lifetime than 7.x that will be deprecated sooner.

I believe that many consumer applications are still using these 6.x packages, and right now they are kind of "forced" to upgrade to the 7.x version, which doesn't bring any actual value. So my suggestion is the following:

• Target version 6.0.0 for this extension library, so consumers applications are not forced to upgrade to 7.0.0
• Consumer applications that already use version 7.0.0 already won't be impacted at all, we just define the minimum version and the public APIs are completely compatibles

[jbogard]

I don't want to multi-target anymore. It was too annoying to deal with. So if netstandard2.0 is annoying then I'll just switch to net6.0.

[asimmon]

I removed the multi-target, only keeping dependencies downgrade from 7.0.0 to 6.0.0. Errors in build are gone, they were introduced by net6.0 built-in analyzers.

So as I said earlier:

• People targeting pre-net6.0 will now use LTS associated extension packages
• People targeting net6.0 are probably already referencing this LTS DI package
• People targeting net7.0 can override the dependencies by explicitely reference the 7.0.0 version. This is actually done by defaut in ASP.NET Core 7 projects (or any Host-based projects)

I also changed the title.

[asimmon]

If you don't mind I'd like to talk more about multi-targeting. Please help me understand what the pain you experienced in the past.

Because here it was not a matter of dealing with preprocessor directives such as #if NET6_0_OR_GREATER or more complex logic based on the targeted framework, but only to not reference "shim-packages" that are unnecessary on more recent frameworks.

[jbogard]

Ah that was the annoyance. Compiler directives. If it's just the package reference, I'm fine multi-targeting.

[asimmon]

Ah that was the annoyance. Compiler directives. If it's just the package reference, I'm fine multi-targeting.

🙏Yeah it requires some discipline and a great test coverage. So to keep things simple I will create a separate PR for that multi-targeting / conditional package reference.

For this current PR though, I just fixed the csproj conflict with your latest #856 changes on master branch.