Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net8 packages (e.g. Microsoft.Extensions.Http.Polly 8.0.0) target netstandard2.0 (and other various frameworks), but according to Microsoft they can only be used on net8 #52332

Closed
1 task done
jjanuszkiewicz opened this issue Nov 23, 2023 · 3 comments
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework

Comments

@jjanuszkiewicz
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

Package Microsoft.Extensions.Http.Polly, version 8.0.0, targets netstandard2.0. However, Microsoft has stated multiple times (example1, example2, example3) that MS package versions must match the app runtime version where they are used.

As is, this package can be installed in apps targeting any framework and may result in an invalid runtime behaviour, but based on the above linked comments I think it should target net8 (and 9.* should target net9 and so on).

Is this something that can be done for this and other similar packages? Right now all the burden of ensuring correct dependency versions is shifted onto app developers, but it seems it could be solved with a stricter framework targeting.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Nov 23, 2023
@wtgodbe
Copy link
Member

wtgodbe commented Nov 29, 2023

@joperezr @eerhardt who owns Polly these days? Can you please move it to the appropriate area path?

@eerhardt
Copy link
Member

However, Microsoft has stated multiple times (#45278 (comment), #45149 (comment), NLog/NLog.Extensions.Logging#642 (comment)) that MS package versions must match the app runtime version where they are used.

I believe this only applies to Microsoft.AspNetCore.* packages, and not to Microsoft.Extensions.* packages. Microsoft.Extensions packages are intended to support netstandard2.0.

See aspnet/Announcements#324. I don't believe our stance has changed on that.

As for the HealthChecks package (example1, I think that is a bug (note the issue is still open). If HealthChecks supports netstandard2.0, it should work on any platform that supports netstandard2.0.

@jjanuszkiewicz
Copy link
Author

I believe this only applies to Microsoft.AspNetCore.* packages, and not to Microsoft.Extensions.* packages. Microsoft.Extensions packages are intended to support netstandard2.0.

Ah, this is great. I reported this issue after some confusion within our team after reading this comment and other similar ones in related issues, but if it's just a bug in Microsoft.Extensions.Diagnostics.HealthChecks, and Microsoft.Extensions.* are safe to use anywhere as long as their target frameworks allow, we're golden.

I have to say the messaging in various comments on github is very confusing, e.g.:

  • Using 7.0.x packages isn't supported with .NET 6
  • But yes, you can't use 7.0 nuget packages against the 6.0 runtime, or vice versa. Everything must match.
  • I don't think using the 7.0.* packages in a 6.0.* app is supported.

None of these mention that it's only about Microsoft.AspNetCore.*.

Feel free to close this issue, it seems there's nothing to do here.

@wtgodbe wtgodbe closed this as completed Dec 7, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Feb 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

No branches or pull requests

3 participants