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

System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription for stable servicing releases includes the full build information in the version suffix #45812

Closed
Tracked by #64603
DamianEdwards opened this issue Dec 9, 2020 · 13 comments · Fixed by #93913

Comments

@DamianEdwards
Copy link
Member

Description
Using the just released 5.0.1 runtime, the System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription API is returning the string ".NET 5.0.1-servicing.20575.16". The issue reproduces on Windows during local dev on a framework-dependent app, and after deployment when running on Linux as a self-contained app.

Repro
Call the System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription API in an app targeting net5.0 on a machine with the .NET 5.0.1 runtime installed.

Expected
Calling the System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription API should return a description with stable versions for stable servicing releases, e.g. ".NET 5.0.1".

Actual
Using the just released 5.0.1 runtime, calling the System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription API is returning the string ".NET 5.0.1-servicing.20575.16", which includes an unstable/preview version suffix.

@jkotas
Copy link
Member

jkotas commented Dec 9, 2020

@Anipik @safern This API returns the product version string of System.Private.CoreLib. Is it expected that the product version string for 5.0.1 includes the unstable/preview version suffix?

@safern
Copy link
Member

safern commented Dec 9, 2020

It shouldn't. I can take a look tomorrow to see why the version was wrong.

@safern safern self-assigned this Dec 9, 2020
@safern safern added this to the 5.0.x milestone Dec 9, 2020
@safern safern removed the untriaged New issue has not been triaged by the area owner label Dec 9, 2020
@ghost ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Dec 10, 2020
@DamianEdwards
Copy link
Member Author

Is this fixed now?

@safern
Copy link
Member

safern commented Mar 9, 2021

Yeah this was fixed on: #45876. However I need to add tests for it to avoid regressing again.

@deeprobin
Copy link
Contributor

@safern What is the current status of this?

@safern
Copy link
Member

safern commented Sep 28, 2021

We are still missing tests for this.

@safern safern modified the milestones: 5.0.x, 7.0.0 Sep 28, 2021
@DamianEdwards
Copy link
Member Author

This seems to not be fixed as I'm getting the following string on the .NET 6.0 GA build:
image

Output of dotnet --info;

.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

.NET SDKs installed:
  6.0.100-rc.2.21505.57 [C:\Program Files\dotnet\sdk]
  6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0-rc.2.21480.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0-rc.2.21480.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.0-rc.2.21501.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

@DamianEdwards
Copy link
Member Author

Seems the AssemblyInformationalVersion in System.Private.CoreLib still has the full build info:

image

@DamianEdwards
Copy link
Member Author

FYI seems we meant to take this for GA but it slipped through the cracks #60572 (comment)

@safern
Copy link
Member

safern commented Nov 8, 2021

I will work on adding tests for this on 7.0 so that this doesn't happen again.

@mairaw
Copy link
Contributor

mairaw commented Nov 29, 2021

So is the fix going to make into 6.0.1? Just wondering if I need to have a workaround in place so we don't show an ugly version on the dot.net website as I reported on #61394. If it's just a few more days, I can wait.

@jeffhandley
Copy link
Member

So is the fix going to make into 6.0.1? Just wondering if I need to have a workaround in place so we don't show an ugly version on the dot.net website as I reported on #61394. If it's just a few more days, I can wait.

7 months later...

We don't have the work for this scheduled yet. Moving to Future. I don't know if a workaround is already in place though.

@jeffhandley jeffhandley modified the milestones: 7.0.0, Future Jul 10, 2022
@akoeplinger
Copy link
Member

akoeplinger commented Oct 24, 2023

This was fixed by #60572 and backported to 6.0. I verified that we return the correct stabilized version in net6.0, net7.0 and net8.0.

We also have indirect tests for this as was surfaced by #93807 but I think adding a simple unit test shouldn't be much work, I'll open a PR for that.

akoeplinger added a commit to akoeplinger/runtime that referenced this issue Oct 24, 2023
We need to make sure the string contains only the stabilized version in servicing, or a non-stabilized one otherwise.
This prevents issues like dotnet#45812 and what we hit in dotnet#93807.

Closes dotnet#45812
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Oct 24, 2023
akoeplinger added a commit that referenced this issue Oct 25, 2023
…93913)

We need to make sure the string contains only the stabilized version in servicing, or a non-stabilized one otherwise. This prevents issues like #45812 and what we hit in #93807.

Closes #45812
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Oct 25, 2023
liveans pushed a commit to liveans/dotnet-runtime that referenced this issue Nov 9, 2023
…otnet#93913)

We need to make sure the string contains only the stabilized version in servicing, or a non-stabilized one otherwise. This prevents issues like dotnet#45812 and what we hit in dotnet#93807.

Closes dotnet#45812
@ghost ghost locked as resolved and limited conversation to collaborators Nov 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants