Repository navigation
Closed
Labels
Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aResolution-FixedThe issue is fixed.The issue is fixed.
Description
Ok! Heard me out. While I was playing around with PowerShell Studio to create a form to display results coming from $PSversionTable in PSCore6 psobjects exported to clixml to then import to a psobject in Windows PowerShell.
I found out the Import-CliXml will error out in Windows PowerShell with the following message:
Import-Clixml : SemanticVersion XML tag is not recognized. Line 81, position 8.
At line:1 char:10
+ $psobj = Import-Clixml -Path c:\Temp\pwshobject602.xml;
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Import-Clixml], XmlException
+ FullyQualifiedErrorId : System.Xml.XmlException,Microsoft.PowerShell.Commands.ImportClixmlCommand
Of course, this is not a Windows PowerShell issue as the workaround below works.
WorkAround
Via code I had to fix the xml tag;
:
$line.Replace('SemanticVersion', 'Version');
:
After fixing the xml tag then my application works. This only happens with the $PSVersionTable.
Steps to reproduce
## - Execute in PSCore 6.0.2:
(Get-Variable PSVersionTable).value.GetEnumerator()| Export-Clixml -Path c:\Temp\pwshobject602.xml;
## - Execute in Windows PowerShell:
$psobj = Import-Clixml -Path c:\Temp\pwshobject602.xml;
Import-Clixml : SemanticVersion XML tag is not recognized. Line 81, position 8.
At line:1 char:10
+ $psobj = Import-Clixml -Path c:\Temp\pwshobject602.xml;
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Import-Clixml], XmlException
+ FullyQualifiedErrorId : System.Xml.XmlException,Microsoft.PowerShell.Commands.ImportClixmlCommand
Expected behavior
To import the CliXml to a PSobject without any error.
Actual behavior
Error: "Import-Clixml : SemanticVersion XML tag is not recognized. Line 81, position 8."
Environment data
## - PSCore6:
PS [156] > $PSVersionTable
Name Value
---- -----
PSVersion 6.0.2
PSEdition Core
GitCommitId v6.0.2
OS Microsoft Windows 10.0.17127
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Metadata
Metadata
Assignees
Labels
Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aResolution-FixedThe issue is fixed.The issue is fixed.


Activity
markekraus commentedon Mar 21, 2018
A related discussion came up in the last community call. The Version in PowerShell Core is a
System.Management.Automation.SemanticVersion, but that type does not exist on Windows PowerShell.MaximoTrinidad commentedon Mar 21, 2018
Mark Kraus (@markekraus),
Hum! Interesting. Still I don't understand the reason for not leave it with "version" instead for "semanticversion". This way it will keep it consistent with other version.
Anyway, it was just an observation, as replacing the xml tag works as a workaround.
:)
SteveL-MSFT commentedon Mar 21, 2018
Maximo Trinidad (@MaximoTrinidad) the workaround only works in the case there isn't a label after the version (like 6.1.0-Preview1). I suppose if it's needed we could add a
-PowerShellVersiontype parameter to format SemanticVersion to Version and chop off the label if present.MaximoTrinidad commentedon Mar 21, 2018
Thanks Steve Lee (@SteveL-MSFT)!
daxian-dbw commentedon Mar 28, 2018
SemanticVersionalso affects remoting from windows powershell to a powershell core endpoint; related issue: #1819We should bring
SemanticVersionto windows powershell to solve the root problem.SteveL-MSFT commentedon Apr 25, 2018
@PowerShell/powershell-committee reviewed this and although a breaking change, we recommend havingPSVersionbe of typeSystem.Versionand add aPSSemanticVersionstring to have theSemanticVersion. Because this is a behavioral and breaking change, James Truher (@JamesWTruher) will author a small RFC to cover this.Update (Ilya (@iSazonov)): See new conclusion in #7016.