Add recommendation to pin .NET SDK version#3571
Conversation
Added a note about pinning the .NET SDK version to ensure consistency in the dependency graph.
PoliCheck Scan ReportThe following report lists PoliCheck issues in PR files. Before you merge the PR, you must fix all severity-1 and severity-2 issues. The AI Review Details column lists suggestions for either removing or replacing the terms. If you find a false positive result, mention it in a PR comment and include this text: #policheck-false-positive. This feedback helps reduce false positives in future scans. ✅ No issues foundMore information about PoliCheckInformation: PoliCheck | Severity Guidance | Term |
|
Learn Build status updates of commit 5a381eb:
|
| File | Status | Preview URL | Details |
|---|---|---|---|
| docs/consume-packages/Package-References-in-Project-Files.md | View | Details |
docs/consume-packages/Package-References-in-Project-Files.md
- Line 344, Column 134: [Warning: hard-coded-locale - See documentation]
Link 'https://learn.microsoft.com/en-us/dotnet/core/tools/global-json' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. - Line 344, Column 279: [Warning: hard-coded-locale - See documentation]
Link 'https://learn.microsoft.com/en-us/dotnet/core/tools/global-json' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. - Line 344, Column 134: [Suggestion: docs-link-absolute - See documentation]
Absolute link 'https://learn.microsoft.com/en-us/dotnet/core/tools/global-json' will be broken in isolated environments. Replace with a relative link. - Line 344, Column 279: [Suggestion: docs-link-absolute - See documentation]
Absolute link 'https://learn.microsoft.com/en-us/dotnet/core/tools/global-json' will be broken in isolated environments. Replace with a relative link.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
|
@dotnet-policy-service agree |
|
The links by the bot comment above https://learn.microsoft.com/en-us/help/platform/validation-ref/docs-link-absolute , https://learn.microsoft.com/en-us/help/platform/validation-ref/hard-coded-locale, https://learn.microsoft.com/en-us/help/platform/faq?tabs=pr-validation-error-solution%2Cpr-merge-conflict-error-solution#build--publish gives me a 404 And the preview URL asks me to login |
|
Learn Build status updates of commit 31e441b: ✅ Validation status: passed
For more details, please refer to the build report. |
PoliCheck Scan ReportThe following report lists PoliCheck issues in PR files. Before you merge the PR, you must fix all severity-1 and severity-2 issues. The AI Review Details column lists suggestions for either removing or replacing the terms. If you find a false positive result, mention it in a PR comment and include this text: #policheck-false-positive. This feedback helps reduce false positives in future scans. ✅ No issues foundMore information about PoliCheckInformation: PoliCheck | Severity Guidance | Term |
| - A given package version is removed from the repository. Though nuget.org does not allow package deletions, not all package repositories have this constraint. This results in NuGet finding the best match when it cannot resolve to the deleted version. | ||
|
|
||
| > [!Note] | ||
| > It's also recommended to pin the version of the .NET SDK that's used so the SDK version and dependency graph stay in lockstep. See [global.json](/dotnet/core/tools/global-json) and especially the `rollForward` section with the `disable` value [global.json rollForward Policy](/dotnet/core/tools/global-json). For related issues when not pinning, see [ASP.NET Core GitHub issue](https://github.com/dotnet/aspnetcore/issues/65061) and [.NET Core SDK GitHub issue](https://github.com/dotnet/sdk/issues/48795) |
There was a problem hiding this comment.
Not sure how to validate the relative links as they give me a 404 but the validation bot says everything is green, I'd still like to verify for myself
PoliCheck Scan ReportThe following report lists PoliCheck issues in PR files. Before you merge the PR, you must fix all severity-1 and severity-2 issues. The AI Review Details column lists suggestions for either removing or replacing the terms. If you find a false positive result, mention it in a PR comment and include this text: #policheck-false-positive. This feedback helps reduce false positives in future scans. ✅ No issues foundMore information about PoliCheckInformation: PoliCheck | Severity Guidance | Term |
|
Learn Build status updates of commit f85e84a: ✅ Validation status: passed
For more details, please refer to the build report. |
| - A given package version is removed from the repository. Though nuget.org does not allow package deletions, not all package repositories have this constraint. This results in NuGet finding the best match when it cannot resolve to the deleted version. | ||
|
|
||
| > [!Note] | ||
| > It's also recommended to pin the version of the .NET SDK that's used so the SDK version and dependency graph stay in lockstep. See [global.json](/dotnet/core/tools/global-json) and especially the `rollForward` section with the `disable` value [global.json rollForward Policy](/dotnet/core/tools/global-json#rollforward). For related issues when not pinning, see [ASP.NET Core GitHub issue](https://github.com/dotnet/aspnetcore/issues/65061) and [.NET Core SDK GitHub issue](https://github.com/dotnet/sdk/issues/48795) |
There was a problem hiding this comment.
I think we have too many notes, so let's have this content as just a regular paragraph.
Let's do one sentence per line.
My take on this is that I think we should provide some explanation on the motivation. The SDK version pinning is something customers may need, but I don't necessarily want customers using lock file to be tying themselves to potentially older versions of the SDK unless they absolutely needed.
So in there I'd basically talk about the fact that .NET SDK wills ometimes automatically reference packages and those package versions may change as the .NET SDK tooling changes and when customers see these issues, then they should pin.
cc @baronfel for a gut check.
There was a problem hiding this comment.
I can reformat.
More explanations are always good, for lock files specifically it might be the current (see below) recommendation but for things like reproducible build (outside of this document but somewhat related?) it would still make sense to pin the version used. Yes for those not using tools like Depandbot or Renovate it might be more easily missed but with knowledgeable/skilled devs you would always check global.json when first starting to check out a new repo. (Maybe something should be built(built-in) that warns when the SDK contains known vulns or is just outdated? Both CLI and IDE (Visual Studio(/Rider)) (and VS Code))
It's based on this comment from Chet ~1 year ago dotnet/sdk#48795 (comment)
It's the recommended way today, but it is a gap in the overall NuGet lockfile story. Our current recommendation for users that use lock files is to also lock their SDK versions via global.json with no rollforward, so they(sic) their entire toolchain stays in lockstep.
But yeah very interested in hearing Chet's updated takes here, will give it some time before making any adjustments
2 participants
Fix NuGet/Home#14867
Added a note about pinning the .NET SDK version to ensure consistency in the dependency graph.