Repository navigation
Invoke-Command -Session $s -Command {$PSVersionTable} Fails Due to SemanticVersion #1819
Description
Steps to reproduce
- Install PowerShell 6.0.0-alpha.8
- Register its remoting endpoint
- Create a session to that endpoint and run Invoke-Command -Session $s -Command {$PSVersionTable}
This is another aspect of #1589 that was not fixed when addressing the original issue. The repro also shows that it works through Enter-PSSession, but not Invoke-Command.
This issue appears to be limited to the serialization & deserialization of SemanticVersion during Invoke-Command calls.
Expected behavior
The value of $PSVersionTable should be returned.
Actual behavior
PS F:\GitRepos\PowerShell> $sxs = nsn . -ConfigurationName powershell.6.0.0-alpha.8
PS F:\GitRepos\PowerShell> Invoke-Command -Session $sxs -Command {1+1}
2
PS F:\GitRepos\PowerShell> Invoke-Command -Session $sxs -Command {$psversiontable}
SemanticVersion XML tag is not recognized. Line 1, position 1046.
+ CategoryInfo : OperationStopped: (localhost:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : JobFailure
+ PSComputerName : localhost
PS F:\GitRepos\PowerShell> enter-pssession $sxs
[localhost]: PS C:\Users\mirichmo\Documents> $psversiontable
Name Value
---- -----
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
CLRVersion
GitCommitId v6.0.0-alpha.8-44-ga35d6adc631309319fa9f85f142feb9b77e2b5ed
BuildVersion 3.0.0.0
PSRemotingProtocolVersion 2.3
PSVersion 6.0.0-alphaEnvironment data
Name Value
---- -----
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
CLRVersion
GitCommitId v6.0.0-alpha.8-44-ga35d6adc631309319fa9f85f142feb9b77e2b5ed
BuildVersion 3.0.0.0
PSRemotingProtocolVersion 2.3
PSVersion 6.0.0-alpha
Activity
mirichmo commentedon Aug 15, 2016
Initially reported by Aleksandar Nikolić (@alexandair) over email.
JamesWTruher commentedon Mar 30, 2017
my real concern about this would be other types which exist in PSCore that don't exist in full - are there more of these lurking about?
iSazonov commentedon Mar 31, 2017
How can we catch it in our tests?
SteveL-MSFT commentedon Mar 31, 2017
Ilya (@iSazonov) I don't think we can repro this on a single machine test, it needs to be across machines that have different representations of the same type. James Truher (@JamesWTruher) is working on bring up cross platform and cross PS version tests, this should catch it there.
JamesWTruher commentedon Mar 31, 2017
it can be caught on Windows as follows:
from PSCore
$psversiontable | export-clixml versiontable.clixml
from Full PowerShell
import-clixml versiontable.clixml
-- error will happen --
the problem isn't the remote connection, but the serializer
iSazonov commentedon Apr 1, 2017
James Truher (@JamesWTruher) Great!
It looks that we can make a test in the same way as for monitoring approved aliases:
for every build type (Win FullCRL, Win CoreCLR, Unix CoreCLR) create
approvedTypes-<Build>.clixmlwith list of approved types and 1. trying import them in CI test time and 2. comparing with the current runtime generated (export-clixml) list.SteveL-MSFT commentedon Apr 11, 2017
Mike Richmond (@mirichmo) this is remoting only from Windows PowerShell to PSCore6?
4 remaining items
[-]Invoke-Command -Session $s -Command {$PSVerionTable} Fails Due to SemanticVersion[/-][+]Invoke-Command -Session $s -Command {$PSVersionTable} Fails Due to SemanticVersion[/+]joeyaiello commentedon May 24, 2017
This is still relevant. Steve Lee (@SteveL-MSFT): yes.
SteveL-MSFT commentedon Nov 13, 2017
I believe this is a change we'll have to make in Windows PowerShell 5.1
iSazonov commentedon Nov 14, 2017
We still haven't tests for serializer as mentioned above. I believe it is blocking issue.
Also we merged #5037 to get SemVer 2.0 - should it be added to PS 5.1 too?