Microsoft.AspNetCore.Mvc.NewtonsoftJson Net6.0 on Net5.0

[wahmedswl]

Description

Paket is not resolving Microsoft.AspNetCore.Mvc.NewtonsoftJson according to the target framework. Its resolving to Net6.0 which is wrong.

error NU1202: Package Microsoft.AspNetCore.Mvc.NewtonsoftJson 6.0.0 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package Microsoft.AspNetCore.Mvc.NewtonsoftJson 6.0.0 supports: net6.0 (.NETCoreApp,Version=v6.0)

Thanks

[nozzlegear]

I'm having the same issue, Paket is installing net6.0 versions of some packages and then my application fails to build because it targets net5.0. I've tried both framework: net5.0 and framework: auto-detect, same issue with both.

[Balinth]

I just ran into this same issue, with Microsoft.EntityFrameworkCore in our case. Did you find a workaound in the meantime?

[wahmedswl]

Pinned to nuget Microsoft.AspNetCore.Mvc.NewtonsoftJson == 5.0.11 as we are currently targeting net5.0 ony!

[nozzlegear]

Same here, I had to pin the version in paket.dependencies for any package that was pulling in the incorrect framework.

[triforcely]

My team is being haunted by this problem lately. I'm not sure whether this really is an issue but I don't want Paket to pull .net6 dependencies when my project is targeting .net5.

Pinning dependencies gets old quickly when we are talking about transitive dependencies.

[NightWatchman]

I'm having the same problem in one of my projects. framework: auto-detect is ignored, along with framework: 5.0. I also have a problem in this project where every time I run paket update it adds <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to my csproj file, even if I have redirects: off in my paket.dependencies. That makes me wonder if there's a deeper problem that's causing the "ignoring framework restrictions" behavior and other undesired behavior.

I've tried cleaning, rebuilding, deleting obj and bin folders, deleting and reinstalling paket. Nothing seems to work and it keeps installing framework 6 packages into the framework 5 project. The only thing that fixes is it restricting the package versions in packet.dependencies and it's a massive rabbit hole with the Microsoft packages trying to do all the transitive dependencies.

[ntwilson]

Kind of a lame workaround, but you could use strategy: min in paket.dependencies to use the default nuget resolution strategy instead of the default paket resolution strategy. Might be better than needing to pin all of the transitive dependencies (though you still need to pin the primary dependencies when you add them to get a .net5 compatible version)

[prosconi]

I would also like to say this is occurring to our team as well. So, bump!

[NightWatchman]

I would note that this is now happening again with the recent release of .NET 8.

I had thought that using framework: auto-detect in the paket.dependencies file would prevent this behavior, but it's trying to install .NET 8 packages that are incompatible with my net7 targeted project. Trying framework: net7 doesn't seem to prevent it either.

I'm using the dotnet tool version 8.0.0

[NightWatchman]

For the benefit of anybody coming across this page.

As suggested in another issue. This can be alleviated by using paket update --keep-major.

[ILikePizza555]

Bumping because I'm also encountering this issue. It seems that that transitive dependencies don't respect the framework restriction