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

Generic support for .NET 5+ TFM's #230

Closed
clairernovotny opened this issue Aug 3, 2020 · 7 comments
Closed

Generic support for .NET 5+ TFM's #230

clairernovotny opened this issue Aug 3, 2020 · 7 comments

Comments

@clairernovotny
Copy link
Member

Follow-up from #229, we need more than a quick-fix that enables .NET 6 and higher the right way.

@nohwnd @nkolev92 @ViktorHofer

@bradwilson
Copy link
Member

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 net5-style naming. I wonder what the motivation there is. Maybe @DamianEdwards can help us understand why this is.

@ViktorHofer
Copy link
Contributor

cc @dsplaisted

@dsplaisted
Copy link

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.

@ViktorHofer
Copy link
Contributor

@nohwnd based on this issue (we are still hardcoding net5.0), I'm surprised that net6.0 testing works for us in dotnet/runtime. Do you know why? Also do you know how to better fix this long-term?

@dsplaisted
Copy link

As I understand it, the NuGet API where this value was coming from (I think it was NuGetFramework.DotNetFrameworkName) was reverted to only return the TargetFramework. If you want to know the platform information you now have to look at a different property.

@nohwnd
Copy link
Contributor

nohwnd commented Oct 14, 2020

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.

@bradwilson
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants