Seems we can remove the unused code after "else".

And if it gets removed, this method will just throw when given v2 and do nothing otherwise. I assume that's all the method should do for PowerShell 6?

Hmm, throwing that exception in #if CORECLR was a decision when porting the code to NanoServer targeting .NET Core 1.0. Back then, PSv2 was definitely not available on NanoServer, which was the only place that PowerShell Core edition was available, so throwing the exception had no problem. Now PowerShell Core is on the desktop, so I'm not sure if we should just throw the exception there (win 10 has removed PSv2, but downlevel OS still has it as an optional windows feature). Besides, if we decide to go with the exception, we probably need to change the error message.

I have updated #3565 to keep track of this cleanup work.

Is this the behaviour designed to support powershell.exe -version 2?

@rjmholt I didn't look into why the PSv2 is taken into consideration here, but possibly related to the scenario where the remote server is PSv2.

Yes that makes sense! Well I suppose the behaviour without the #ifdef makes sense then -- no-op unless trying to remote into v2, in which case, exception.

I believe we don't support PSv2 at all.

Yes -- so I'm guessing an exception makes sense then? Something that is red and tells the user we don't support this, but doesn't crash the shell

Seems the method is used to run jobs. I guess the remoting (with both local and remote hosts) with PSv2 doesn't work at all.
/cc @PaulHigin Could you please comment too?

I briefly examined the code that depends on this method.

• for the use in StartJob, it looks to me is possible to start a job running in PSv2 if it's available on the machine. However, in PowerShell Core, we can only start job using pwsh. So the whole -PSVersion parameter doesn't really make sense. It turns out this is a bug that should be fixed. (see PowerShell Core cannot start a job using Windows PowerShell #7059) That means we still need to check for PSv2 availability for Start-Job -PSEdition.

• for the use in CustomShellCommand, it allows to register a PSSessionConfiguration for PSv2. However, PowerShell Core remoting depends on WinRM features from WMF 4.0, so it won't be able to connect to PSv2 remoting endpoint. My comment about the remoting was not accurate. WMF 4.0 is required to create a PSCore endpoint (using PSCore as a server in remoting), however, it might not be required for PSCore to connect to a PSv2 server (using PSCore as a client). If PSCore is able to connect to PSv2 server, then the PSv2 related code is still relevant.

So, it looks to me is likely that we still need the PSv2 related code. As to this PR, I think it can be merged as is for now.

And if it gets removed, this method will just throw when given v2 and do nothing otherwise. I assume that's all the method should do for PowerShell 6?