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
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?
@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.
RuntimeInformation.FrameworkDescription is probably the closest we have today (see also the discussion in https://github.com/dotnet/corefx/issues/9725 and https://github.com/dotnet/corefx/pull/9763).
cc @ericstj
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
Closing in favor of https://github.com/dotnet/corefx/issues/16629
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).
https://github.com/dotnet/corefx/issues/35573 explains behavior of the version APIs in 3.0
Most helpful comment
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/17452I've started looking at a lot of this stuff as part of the capabilities API investigation.
/cc @mellinoe