-
Notifications
You must be signed in to change notification settings - Fork 133
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
[6.0] Different versions of NuGet.Commands.dll
s between source-build and Microsoft build
#3249
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Looks like it's set from https://github.com/NuGet/NuGet.Client/blob/55728432057dc57733661fe01e9c8493ab5034f2/build/common.project.props#L117-L119: <PropertyGroup Condition=" '$(PreReleaseVersion)' == '' ">
<PreReleaseVersion>32767</PreReleaseVersion>
</PropertyGroup> |
[Triage] NuGet is a non-arcade repo which may be the source of the version number differences. |
NuGet.Commands.dll
s between source-build and Microsoft buildNuGet.Commands.dll
s between source-build and Microsoft build
I am focusing this issue on the version number mismatch only. The too-many-NuGet.Command-dlls is a general issue related to the source-build-vs-microsoft baselines that's being handled elsewhere. |
Bringing this one up to triage again. One possibility is that we should focus on fixing this in 8.0, possibly by pushing NuGet to adopt Arcade so their versioning works the same way as everything else. |
[Triage] @crummel, Can you link this to the NuGet issue regarding getting them onboarded onto Arcade? |
[Triage] The priority of fixing this in servicing would be higher if the nuget vulnerabilities caused from the version diff becomes the only vulnerability being reported. Right now there are numerous vulnerabilities because of dotnet/sdk#30659. Once that issue is resolved, we should re-assess the situation. |
Question: are the version numbers on the assemblies produced by source-build expected to match with those on Microsoft build? If so, can we add a test to source-build that verifies they do? |
Sounds like #3145 should cover this? |
It is desirable. One reason for this is related to vulnerabilities. Security scanners can associate vulnerabilities with particular versions. If the source-build versions don't align with Microsoft, this can cause mis-information. |
Does source-build 'fake' version numbers? The trigger for my question was to use version numbers as a way of checking the same sources were used. |
Maybe we could check commit sha's (instead of version numbers) for this? |
I've added a comment to the version check issue to check shas as well: #3145 (comment). |
The existing issue I was thinking of was NuGet/Home#11059, which I've added a comment about the broader versioning aspect to. |
This requires NuGet to onboard onto arcade which is tracked with NuGet/Home#12731. |
Describe the Bug
Sourcebuild has 3 copies of
NuGet.Commands.dll
, compared to just 1 copy in the Microsoft-built SDK. The version numbers are also different:6.0.3-rc.32767+c60eee85ec0109bdda894806b167bb4d55f75183
vs6.0.3-rc.1+c60eee85ec0109bdda894806b167bb4d55f75183.c60eee85ec0109bdda894806b167bb4d55f75183
, though the commit sha is the same.source-build .NET 6.0.113:
Microsoft's build of .NET 6.0.113:
32767 is
Int16.MaxValue
.The text was updated successfully, but these errors were encountered: