Make Environment.Version return the actual runtime version

[davidfowl]

Today on a .NET Core 2.1.0 project printing Environment.Version prints out 4.0.30319.42000 which is a hard coded constant in the runtime https://github.com/dotnet/coreclr/blob/ce0a2617d40bc217b8e0a2137e340afe585afcb1/src/System.Private.CoreLib/src/System/Environment.cs#L277. This should print out the actual runtime version based on the policy applied by the host (like 2.1.1 if that's what runtime version is actually being used).

This also needs to be used as the version logged into the event log when there's an unhandled exception reported by the runtime. Today is a bogus version which isn't very useful.

[weshaggard]

Today we don't have the "marketing version" (i.e. 2.1.1) embedded anywhere that we can consume so the best we could really do would be to return the file version of corelib.

[jkotas]

The host knows this version - it can pass it to the runtime as key-value pair.

[weshaggard]

The host knows this version - it can pass it to the runtime as key-value pair.

I assume it only knows it for applications running on the shared framework correct? What should we return for standalone applications?

[jkotas]

All applications have it in .deps.json file.

[weshaggard]

I assume you are referring to the package version for Microsoft.NETCore.App (or runtime.[rid].Microsoft.NETCore.App) then? If so yes that may work for now but that may not be in the deps file in the future but we could probably ensure some version remains for this purposes.

[abbotware]

I've been looking for away to get the RuntimeFrameworkVersion, so I tried all the API's that I could find (#31249) and none seemed to return anything useful - Any programmatic way to get the 'marketing version' would be good enough for me.

@weshaggard is there is a 1:1 mapping for 'corelib version' to 'marketing version' ? If yes, then could a lookup table be constructed?

Regarding versions returned from API calls, I am kinda curious though why the difference in System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription: .NET Core 4.6.26614.01 and Environment.Version: 4.0.30319.42000

If one of those could be used to map back to the RuntimeFrameworkVersion, then there is at least a workaround for now?

[davidfowl]

The host needs to pass the value to the runtime, the property would then read an AppContext property (or something similar) to get the actual version.

The host already does this for the deps file path in order to pass it to the DependencyModel API. https://github.com/dotnet/core-setup/blob/84fa44f892b42ad9235e4ecb756975d8c8f46f1f/src/corehost/cli/hostpolicy.cpp#L104

We just need to do this for the version as well.

[weshaggard]

@weshaggard is there is a 1:1 mapping for 'corelib version' to 'marketing version' ? If yes, then could a lookup table be constructed?

Yes the corelib version is 1:1 with the marketing version but doesn't exactly match it. If you workaround this for now you can get the version of corelib the same way we do for FrameworkDescription https://github.com/dotnet/corefx/blob/master/src/System.Runtime.InteropServices.RuntimeInformation/src/System/Runtime/InteropServices/RuntimeInformation/RuntimeInformation.cs#L28.

@davidfowl I agree the host can pass the value to the runtime it is just a matter of how it gets it in the various cases as well as what this API would do for custom hosts. We have to cover all the cases.

[davidfowl]

We have to cover all the cases.

Sure, just make it a contract. We look at a specific AppContext variable which is controlled by the host. In absence of that, we show something that doesn't mean much to you (the CLR file version or something).

[steveharter]

Talked to @davidfowl a bit. I think the most straightforward way to do this is for the hostpolicy to add a couple AppContext\AppDomain variables like "FRAMEWORK_NAMES" and "FRAMEWORK_VERSIONS". They would list each framework and found\actual version (not requested version) separated by a delimiter.

We already do similar things with "FX_DEPS_FILE" that is picked up later by the CLI.

This information could we wrapped by a managed class in the future (Environment or otherwise).

[steveharter]

Adding a "FRAMEWORK_NAMES" and "FRAMEWORK_VERSIONS" would not work for standalone; we would need a mapping from deps.json version as explained earlier or some other mechanism depending on what info we want

[steveharter]

Overlaps a bit with https://github.com/dotnet/core-setup/issues/4112 for logging this information

[abbotware]

@steveharter does 'standalone' = 'self contained deployment' (SCD) ? (In my case I am using an Ubuntu SNAP to deploy .Net Core + my App + Native libs on Linux)

[davidfowl]

@weshaggard @jkotas If we change this property to be useful does that count as a breaking change? Specifically because it would go backwards?

[weshaggard]

@weshaggard @jkotas If we change this property to be useful does that count as a breaking change? Specifically because it would go backwards?

Every change is a breaking change :) however if we don't have any evidence that it will break people then we will assume it is not a breaking change. If enough folks get broken then we may change our mind about how we fix it.

[steveharter]

does 'standalone' = 'self contained deployment' (SCD) ? (In my case I am using an Ubuntu SNAP to deploy .Net Core + my App + Native libs on Linux)

Yes.

From the host perspective, the easiest implementation for both self-contained and framework-dependent would be to simply add a "FX_DEPS_FILES" context variable, similar to existing "FX_DEPS_FILE", but lists the path to the app's deps.json, every framework deps.json and perhaps those specified by additional-deps as well. For self-contained, there would only be one deps.json.

Then the managed layer would need to read each deps file and use a json parser (probably just use DependencyModel like this) to obtain the desired framework(s) by name and report back on the version.

Besides being simpler for the host, an advantage would also allow the managed layer to report on any types of other dependencies, including non-frameworks, assembly versions, etc if those were useful for logging.

The disadvantage is that it creates a dependency on the deps.json for the managed layer, which can change over time.

When we decide on a plan, I'll move this issue over to core-setup.

[jkotas]

Then the managed layer would need to read each deps file and use a json parser (probably just use DependencyModel like this)

I do not think we would want to create dependency from Environment.Version (very low-level API) to DepenendencyModel.

[davidfowl]

I'd prefer we just set the version data direction in the host properties instead of using the deps file. Agree with @jkotas, we can't take a dependency in mscorlib on deps.json. It should be host agnostic.

[steveharter]

Issue moved to dotnet/core-setup dotnet/runtime#15683 via ZenHub

[davidfowl]

Work needs to be done in coreclr and core-setup. Do we track both in core-setup?

[steveharter]

re-opening to track any corefx work (in Environment)

[steveharter]

The core-setup part has been implemented (in master branch). The current version of the framework can be obtained via:

System.AppDomain.CurrentDomain.GetData("FX_PRODUCT_VERSION") as string;

Keeping this corefx issue open to determine if we can to add a new method to Environment (or elsewhere) to wrap this.