Powershell: $PSVersionTable.CLRVersion property should be removed in PowerShell Core

[alexandair]

Steps to reproduce

I'm on Windows 10 with November update:

PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.0.10586.122
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.10586.122
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

When I install PowerShell 0.6.0 by using powershell-0.6.0-win81-x64.zip or PowerShell_0.6.0.0.msi, output of $PSVersionTable is not correct.

Expected behavior

PSEdition property should be Desktop, not Core.
CLRVersion property should not be empty.

Actual behavior

PS C:\Program Files\PowerShell\0.6.0.0> $PSVersionTable

Name                           Value
----                           -----
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
PSVersion                      5.1.10032.0
PSRemotingProtocolVersion      2.3
PSEdition                      Core
GitCommitId                    v0.6.0
CLRVersion
BuildVersion                   3.0.0.0

[vors]

In PSEdition Core is for CoreCLR, Desktop is for FullCLR, so there is no problems here.

[alexandair]

Shouldn't CLRVersion property be populated?

[joeyaiello]

Probably....

[andschwa]

This is purposefully not set because it is supposed to be [Environment]::Version, but that is not available in .NET Core (at least not in the current stable release; it _is coming back_ per https://github.com/dotnet/corefx/commit/fe5f4fbebc9e85c8e512a273567719dca15ac764, which will be available in the next stable release). So while it is not available, it is set to null.

Please note that the following will be confusing:

~/src/PowerShell |-/ [environment]::Version 

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      30319  42000   

This is due to Version being set in the environment extensions class for compatibility, and is not the actual CLR version.

So $PSVersionTable is currently correct; but should be updated with the next release of .NET Core.

Closing for now.

/cc @daxian-dbw

[lzybkr]

If the api is coming back, this issue should be left open so we remember to fix the code.

If the api never comes back, we should consider either removing the entry or fill it in explicitly. An empty value is useless.

[joeyaiello]

@lzybkr do you happen to know which API we depended upon here? I want to validate if it's coming back with 2.0

[lzybkr]

Looks like it's Environment.Version: https://github.com/PowerShell/PowerShell/blob/f0c0176aa21647668e2bb3235e65dee002d52c62/src/System.Management.Automation/engine/PSVersionInfo.cs#L70

[SteveL-MSFT]

@joeyaiello @lzybkr following Andy's link above to corefx, it appears Environment.Version is hardcoded to 4.0.30319.42000 for compat reasons. If the CLR version is useful (beyond this hardcoded string), it looks like we need to return the fileversion.

[iSazonov]

I believe too we should restore it for backward compatibility.

And the next question is whether we need something else useful here?

• NetCoreApp ? (Microsoft.Extensions.PlatformAbstractions.PlatformServices.Default.Application.RuntimeFramework.Version)
• real CLR runtime version? There is no native way to get it https://github.com/dotnet/coreclr/issues/8815
  Comment :

Starting with 4.6 we switched to a file versioning

So we would read the version from coreclr.dll - how to find it?

[joeyaiello]

@PowerShell/powershell-committee discussed a bunch of options today:

1. removing the property: given the type of $PSVersionTable, $PSVersionTable.CLRVersion will still just emit $null. A cursory search reveals a non-zero amount of instances of people using .Contains which would still break
2. using the hardcoded value of [Environment]::Version
3. using the .VersionInfo.FileVersion of coreclr.dll (4.6.somethingorother)

Ultimately, the value is meaningless other than supporting back-compat. Given CoreCLR's decision to hardcode the string, we should talk to @terrajobst about .NET's thinking on this problem so that we don't do anything dumb.

[joeyaiello]

Assigning to myself to ping @terrajobst about this.

[SteveL-MSFT]

@PowerShell/powershell-committee discussed this with dotnet team and agree that we should not be exposing ClrVersion property as guidance from dotnet is that users should not be taking dependency on this value as it's not providing intended value