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

Need consistent way to get Runtime framework version #23160

Closed
clairernovotny opened this issue Aug 13, 2017 · 8 comments
Closed

Need consistent way to get Runtime framework version #23160

clairernovotny opened this issue Aug 13, 2017 · 8 comments
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Runtime
Milestone

Comments

@clairernovotny
Copy link
Member

For applications that may run on multiple versions, it can be useful diagnostic info to output (".NET Framework 4.7.1" or ".NET Core App 2.0.1", etc).

As far as I can see, there's no way to do this since TargetFrameworkAttribute is not present on either mscorlib or System.Private.CoreLib. Putting those on would be very helpful as well. At least mscorlib has an AssemblyFileVersion of 4.7.2542.1. I don't see any such thing on .NET Core app that maps to its "real" version. Instead, .NET Core App 1.0.5 has [assembly: AssemblyFileVersion("4.6.25211.02")].

The ask is to have a reliable way, at runtime, to get a value that says something like ".NET Framework v4.7.1", ".NET Core App 2.0.1" or "UWP ...".

Possibly related to https://github.com/dotnet/corefx/issues/23063

@clairernovotny clairernovotny changed the title Need way to get Runtime framework version Need consistent way to get Runtime framework version Aug 13, 2017
@karelz
Copy link
Member

karelz commented Aug 14, 2017

I thought we have something like this - at least without the version to distinguish .NET Framework vs. .NET Core.
@weshaggard @terrajobst @danmosemsft do you know more?

@clairernovotny
Copy link
Member Author

clairernovotny commented Aug 14, 2017

@karelz, it'd also need to support Mono, Xamarin iOS, Xamarin Android, etc. Basically, "what am I running on now?" TargetFrameworkAttribute would seem to be the natural fit, esp looking at the assembly that contains Object, but that attribute isn't consistently present.

@akoeplinger
Copy link
Member

akoeplinger commented Aug 14, 2017

RuntimeInformation.FrameworkDescription is probably the closest we have today (see also the discussion in https://github.com/dotnet/corefx/issues/9725 and dotnet/corefx#9763).

@weshaggard
Copy link
Member

cc @ericstj

@ericstj
Copy link
Member

ericstj commented Aug 14, 2017

I do think we're missing a good API for "running TFM". We have one for targeted TFM of application, AppContext.TargetFrameworkName, but not one for the executing framework. Related: https://github.com/dotnet/corefx/issues/17452

I've started looking at a lot of this stuff as part of the capabilities API investigation.
/cc @mellinoe

@ViktorHofer
Copy link
Member

Closing in favor of https://github.com/dotnet/corefx/issues/16629

@ygoe
Copy link

ygoe commented Nov 9, 2019

What's the current status of this? The last comment redirects me somewhere and then I got lost, so I came back to this place to ask. I cannot find the precise framework/CLR type and version anywhere today in a .NET Core 3.0 app (which would be the target milestone of this issue).

@jkotas
Copy link
Member

jkotas commented Nov 9, 2019

https://github.com/dotnet/corefx/issues/35573 explains behavior of the version APIs in 3.0

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 3.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Runtime
Projects
None yet
Development

No branches or pull requests

9 participants