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
Generic support for .NET 5+ TFM's #230
Comments
I found #229 very curious, because it seems like they went away from the more parsable version of the target framework name and instead just give you |
cc @dsplaisted |
The reason for the change is that the more parsable version of the target framework (.NETCoreApp, Version=v4.5) didn't have a way to represent the platform name / version which can now be part of the target framework in .NET 5 and above. So the NuGet API now returns the NuGet short framework name, which can represent the platform info, if the target framework is .NET 5 and higher. |
@nohwnd based on this issue (we are still hardcoding |
As I understand it, the NuGet API where this value was coming from (I think it was |
Daniel is right, the change was reverted somewhere in RC1 and my original fix can be reverted as well (Ideally when net5.0 is released). @ViktorHofer It works for you because of that, and because the code on nuget.frameworks takes net as a pattern and can convert that from the short framework name to .NETCoreApp,Version=v6.0 (or how exactly it is spelled in the DLL attributes), and vice versa. The adapters (e.g. mstest or xunit) will match on .NETCoreApp* to determine if this is a .NET Core dll. |
It's not clear to me from this thread whether this fix should be upgraded or removed, so I at least made it better. Making it go away would also be fine. a4e9f53#diff-85765f830c78860b59bc0674f13f37560b05936bf9b613255b6ebc13b0c9e295R121 |
Follow-up from #229, we need more than a quick-fix that enables .NET 6 and higher the right way.
@nohwnd @nkolev92 @ViktorHofer
The text was updated successfully, but these errors were encountered: