Open omajid opened 1 year ago
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.
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 https://github.com/dotnet/sdk/issues/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 https://github.com/dotnet/source-build/issues/3145 should cover this?
Question: are the version numbers on the assemblies produced by source-build expected to match with those on Microsoft build?
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. If source-build overrides them, then that relationship is gone.
The trigger for my question was to use version numbers as a way of checking the same sources were used. If source-build overrides them, then that relationship is gone.
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: https://github.com/dotnet/source-build/issues/3145#issuecomment-1466272911.
The existing issue I was thinking of was https://github.com/NuGet/Home/issues/11059, which I've added a comment about the broader versioning aspect to.
This requires NuGet to onboard onto arcade which is tracked with https://github.com/NuGet/Home/issues/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
.