-
Notifications
You must be signed in to change notification settings - Fork 315
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
Remove nuget frameworks dependency #2544
Conversation
@vritant24 this is what I need to do to replace Nuget.Frameworks. Are you able to validate that this would fix the LUT issue? Maybe we should add additional logic that will create a netcoreapp like Framework object from any net* string as a fallback? that way when net5.1 or net6.0 are finally added we don't have to update the class as long as they are in the form of net. I think something similar is happening in the SDK because setting the TFM to |
Version = "4.6.2.0", | ||
ShortName = "net462", | ||
}, | ||
[".NETFramework,Version=v4.6.3"] = new Framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, missing .NETFramework 47*?
I'm not sure of the entire information that the testplatform has access to, but it looks like currently it is operating on This project system doc elaborates on that reasoning. For instance in the .NET 5 upgrade, the |
@vritant24 thanks for the tip, but imho that is relevant only to msbuild and project properties, we don't use any of those. We look at TFM attribute in the assembly, because vstest console handles only built dlls. |
Looks like too stale to revive, I'm going to close(lot of conflicts and we bumped a lot of versions in these time frame). |
@MarcoRossignoli that merge does not look that bad, might have a look on it when I am back. |
Yep doesn't look so bad and we should catch issue with new tfm really soon in the dogfooding/insertion process. cc: @sharwell |
Description
Translate short and long framework names ourselves instead of depending on Nuget.Frameworks