search

jbogard / MediatR

Simple, unambitious mediator implementation in .NET
Apache License 2.0
10.84k stars 1.15k forks source link

.NET 6 Target Dependencies #980

Closed wsugarman closed 7 months ago

wsugarman commented 7 months ago

I noticed that recently the Microsoft.Extensions.DependencyInjection.Abstractions package was updated as a dependency to 8.0.0 with the release of .NET 8. However, I do not think this is appropriate for the .NET 6 version of the assembly. Consumers of the .NET 6 target of MediatR are likely to be running in .NET 6 (or .NET 7) runtimes where the version of the Microsoft.Extensions.DependencyInjection.Abstractions assembly brought in (or compiled against for other dependencies) will be version 6.x or 7.x.

If it sounds reasonable, could MediatR instead pin to the 6.0.0 version of Microsoft.Extensions.DependencyInjection.Abstractions when targeting .NET 6, and a new target for .NET 8 could depend on version 8.0.0?

jbogard commented 7 months ago

So the 8.0 package of MS DI targets net6.0 as well as many other frameworks, and is intended to ship out-of-band with .NET. It also introduced breaking changes that I had to code around. I don't plan on supporting lots of different target frameworks so this is the best I can do.

CNBoland commented 7 months ago

I understand the support issues and appreciate the work done on Mediatr. I'd like to leave a note here for others in our situation.

We are using Mediatr in an Azure Functions app that targets .NET 6 and uses the in-process hosting model. The Azure Functions Host currently supports in-process hosting only on .NET 6 (see Supported Versions). Since .NET 7 was released, many of the Microsoft.Extensions.* packages versioned 7.x+ won't load in our Function Apps even though the packages target .NET 6. I still don't understand why this is, but it is. According to Microsoft, .NET 8 will eventually support in-process hosting (see August 2023 roadmap update), so until then, we (and others in our situation) will be locked in to Mediatr v12.1.1.

jbogard commented 7 months ago

That makes sense, just don't upgrade yet. And I am also alllll too aware of the limitations of the in-process hosting model and dependencies.

jmoerdyk commented 7 months ago

I'm also stuck at v12.1.1 now because of NSwag.AspNetCore (13.20.0) via NSwag.Generation.AspNetCore (v13.20.0) which locks Microsoft.Extensions.DependencyInjection.Abstractions at < 8.0.0 for both net6.0 and net7.0 targets. A version of NSwag that supports net8,0 is in preview, but definitely not ready for production use.