Enable-PSRemoting and Install-PowerShellRemoting.ps1 create version specific endpoints with different names

[HemantMahawar]

Steps to reproduce

0. Run elevated pwsh.exe

1. Unregister any existing PowerShell Core remoting endpoint

Get-PSSessionConfiguration | Unregister-PSSessionConfiguration

2. Run Install-PowerShellRemoting.ps1 from $PSHome

& $PSHome\Install-PowerShellRemoting.ps1

3. List the remoting endpoints

Get-PSSessionConfiguration | ft name

4. Unregister any existing PowerShell Core remoting endpoint from step 2

Get-PSSessionConfiguration | Unregister-PSSessionConfiguration

5. Run Enable-PSRemoting cmdlet

Enable-PSRemoting

6. List the remoting endpoints

Get-PSSessionConfiguration | ft name

Expected behavior

After steps 3 and 5, the endpoint names should be same:

• PowerShell.6
• PowerShell.6.1.0-preview.3

Actual behavior

Endpoint names are different after steps 3 and 5

After Step 3

• PowerShell.6
• PowerShell.6.1.0-preview.3

After Step 5

• PowerShell.6
• PowerShell.v6.1.0-preview.3 (extra 'v' before version number)

[HemantMahawar]

FYI .. @SteveL-MSFT

[SteveL-MSFT]

Thought this was already fixed. I'll also fix it so that for Preview releases, it'll be PowerShell.6-Preview. I also wonder if we need to keep Install-PowerShellRemoting.ps1 as the only use different from Enable-PSRemoting is supporting specifying the location of PowerShell different than the running PowerShell, but I think you can just do:

pwsh -c enable-psremoting

Need to verify that works on Win10 IoT where you've had to use Install-PowerShellRemoting.ps1

[SteveL-MSFT]

@iSazonov brought up a good issue, currently if you run Enable-PSRemoting or Install-PowerShellRemoting.ps1 we setup the generic endpoint PowerShell.6 as well as the version specific endpoint PowerShell.v6.1.0-blah (using Enable-PSRemoting) or PowerShell.6.1.0-blah (using Install-PowerShellRemoting.ps1). Intent of this issue was to have Enable-PSRemoting and Install-PowerShellRemoting.ps1 standardize on the non v naming of the version specific endpoint to match the generic one.

However, the end result is that every script that wants to use the version specific one needs to apply the same formula:

"PowerShell." + $PSVersionTable.GitCommitId.ToString().SubString(1)

This strips the v. It seems we should simplify this to make it predictable for automation. Options:

1. Change PSVersionTable.GitCommitId to not start with a v (then we have to decide whether on pwsh start we emit "PowerShell v" or just "PowerShell "
2. Add a new ShellName or EndpointName property to PSVersionTable that is exactly the same as the version specific endpoint
3. Update Install-PowerShellRemoting.ps1 to put back the v so it's consistent with GitCommitId but inconsistent with PSVersion

Personally, I don't think we need the v at all so I'd go with option 1.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this and would prefer to drop the v from GitCommitId and have the version specific endpoint match GitCommitId. @TravisEz13 can you verify that there is no functional/packaging concern with removing the v?

[SteveL-MSFT]

I talked to @TravisEz13 and he's not aware of any reason the v is necessary. I'll update the PR to standardize on no v.