Skip to content
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

.NET 8: New hash added to product version, can't find a workaround or find info about this change #36885

Closed
philfontaine opened this issue Nov 14, 2023 · 3 comments
Labels
Area-Workloads untriaged Request triage from a team member

Comments

@philfontaine
Copy link

Describe the bug

image

To Reproduce

image

Exceptions (if any)

Further technical details

  • Include the output of dotnet --info
  • The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.6c33ef20

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.100\

.NET workloads installed:
 Workload version: 8.0.100-manifests.6c33ef20
There are no installed workloads to display.

Host:
  Version:      8.0.0
  Architecture: x64
  Commit:       5535e31a71

.NET SDKs installed:
  6.0.308 [C:\Program Files\dotnet\sdk]
  7.0.113 [C:\Program Files\dotnet\sdk]
  8.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Nov 14, 2023
@reflectronic
Copy link

This is a result of the Source Link integration in the .NET 8 SDK. Source Link looks for version control data in your project's source tree to enhance debug information and assembly metadata. The .NET 8 SDK automatically enables Source Link for all projects (as documented in the release notes).

Source Link sets the SourceRevisionId property based on the discovered version control information. This property's value is appended to InformationalVersion automatically by the SDK:

If the $(SourceRevisionId) property is present, it's appended to InformationalVersion. You can disable this behavior using IncludeSourceRevisionInInformationalVersion.

So, the hash you're seeing is the current Git commit hash at the time the library was built. Setting <IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion> in your project file will prevent it from showing up in your assembly version.

@thedarkfalcon
Copy link

This is terrible behaviour to enable by default, especially when most .net8 documentation pages fail to mention it.
One of our newer projects is running .net8 which required .net8 to be installed on our Azure build agents, now to maintain functionality we now have to add <IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion> to hundreds (maybe even thousands) of csproj files.
Having this long version string breaks a lot of integrations with installer creators, deployment services, and artefact services.
User experience for looking at these long version strings is also really bad, not that I think users should even be getting commit IDs etc told to them about the software they have. If MS really wanted to force this behaviour, it really shouldn't be in the version string property IMO.

@KalleOlaviNiemitalo
Copy link
Contributor

KalleOlaviNiemitalo commented Oct 16, 2024

@thedarkfalcon can't you set it in Directory.Build.props, or in the MSBuild --property option, or as an environment variable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Workloads untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

4 participants