Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
warning when dot is omitted from targetframework version in net5.0+ #3625
warning when dot is omitted from targetframework version in net5.0+ #3625
Changes from 5 commits
0954642
1815b11
f648027
5ef3780
7869d57
af6ee20
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Why are we checking the netstandard versions?
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.
NuGet/Home#9215 (comment)
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.
There'll be no new versions of netstandard.
The true risk here is what happens when we hit
net10.0
. The risk is not there with netstandard.Keep in mind that there are existing packages/projects with netstandard. I see no reason to raise an extra warning for something that won't really affect them.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
@JonDouglas do you have comments about this user-facing error message?
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.
@zkat & @zivkan
Dots in TargetFramework versions are required. The missing dot in '{0}' might cause future breakage.
->
or
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.
The framework is technically valid and understood...just might not work the way that customer intended it to.
In particular the problem is that
net50
is parses to version5.0
, and the eventual progression of NET will eventually lead to version 10.0, so if people still write frameworks with versions thennet10
, it'd get parsed to1.0
while they might expect it to parse to10.0
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.
Yep, and we want to change the behavior of the customer to promote the best practice.
This is similar with mobile TFMs such as monoandroid10 vs. monoandroid10.0. One is 1.0 & the other is 10.0.
So TargetFramework = monoandroid, TargetFrameworkVersion = v1.0
If anything, we should be promoting the separator across the board, it's the best practice is it not? Everything in the NET 5 spec suggests to use a period separator for all
TargetBlahVersion
properties.https://github.com/dotnet/designs/blob/master/accepted/2020/net5/net5.md#upgrading-the-os-bindings
https://github.com/dotnet/designs/blob/master/accepted/2020/net5/net5.md#lighting-up-on-later-os-versions
The bigger question is best practices for the
<TargetFramework>
element here. Is it period separator or not? Prior to .NET Core it looks like no, it doesn't matter. After .NET Core it seems that it should be included. Thoughts?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.
Separator across the board is the right approach.
Those are not user defined usually.
The idea is that the TargetFramework property can be anything.
NuGet doesn't parse it, which is why the check is only happening at pack time.
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.
Shouldn't we create an issue on the SDK team, or contribute a pull request ourselves, to do it in the SDK instead? It doesn't make much sense to me to do at pack time. It should be done at restore, but only when the monikers were not provided and the TargetFramework property was parsed, hence why it can only be done in the SDK and not in NuGet.
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.
@zivkan So what I'm hearing is that the suggestion is to drop this PR in favor of doing this SDK-side in a more general way?
As far as whether to warn always or warn only for certain frameworks -- I think the concern was that this could get very noisy, very quickly for people. I mean even for us, we'd need to change a bunch of
net45
/net472
items in our tests and projects?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.
yes, my opinion is close this PR, and someone should make a change in the SDK instead.
The key is, do not warn if my csproj has:
This csproj doesn't have a
.
in the TargetFramework value, but it doesn't need one because it correctly sets the 3 other properties needed to correctly define the canonical target framework. Only when the SDK parses the TargetFramework value to set the other properties itself, in that situation warn about missing dots.And yes, you're right about the noisy warnings. Just like this PR, we should only warn when the TFM ends up being TFI='.NETCoreApp' and TFV >= '5.0'. Or any TFI='.NETStandard' apparently.
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.
I think we should still do it on our side in pack because people can manually create packages. We should catch things like that in the nuspec and package folders.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.