Pass variable to nested powershell.exe without converting the type

Hi. I’m trying to pass a variable to a nested powershell.exe call from a powershell script using something like:

#main script pseudo
$var = get-some-data

$result = powershell.exe -command {some-cmdlet -param1 $var}

However when I do that, it fails, because the call converts the $var from the original type to System.String and that’s not what the some-cmdlet is expecting.
I’ve tried passing it using powershell.exe -command {} -args $var, tried using Start-Process to exec the powershell.exe etc., but can’t get it working.

Any help is appreciated.

The reason I need to do this is because the some-cmdlet is poorly written and outputs directly to console (it’s a MS .dll module, so I can’t fix the original code) and I haven’t been able to capture the output. Same thing happens when trying to capture it when calling it remotely (invoke-command).
The only way I could capture the output is using nested powershell.exe call, which works when I retrieve the object directly in the some-cmdlet call, but not when it’s already stored in a variable).

@Budrumi Welcome to PowerShell.org forums,

Since its a new process, AFAIK it always converts arguments and its values to string.

For similar cases, what I normally do is to make some-cmdlet in a new script. And before calling this in new process, export all data required to xml using Export-CliXml and use Import-CliXml inside new script.

example.

Get-SomData | Export-CliXml -Path c:\temp\tempinput.xml

powershell.exe -command {.\newscript.ps1 -argpath c:\temp\tempinput.xml}

Temp script will be like

Param($ArgPath)

$Arguments = Import-CliXml -Path $ArgPath
Some-Cmdlet -Param1 $Arguments

see Export-Clixml and Import-Clixml

1 Like

@kvprasoon thanks for the idea, I’ve implemented it, however that still doesn’t work, because some-cmdlet now complains about the object type being (have to be specific here) “Deserialized.Mi
crosoft.Internal.EnterpriseStorage.Dls.UI.ObjectModel.SystemProtection.SystemProtectionDatasource” instead of “Microsoft.Internal.EnterpriseStorage.Dls.UI.ObjectModel.OMCommon.Datasource
Any further ideas?

$Arguments = Import-CliXml -Path $ArgPath

You can consume it in different ways. You will get a clear picture reading both the docs I’ve shared as a link. Make sure to have a closer look at -Depth parameter of Export-CliXml.

I’ve read the docs, I’m not much smarter. I’ve tried changing the depth (tried range 1-10) when exporting, some-cmdlet always complains about not being able to convert the value of the deserialized type to the required original type.
I’ve also tried specifying the required type in the import-clixml code, but that gives the same conversion error.

Any further ideas?
I searched some more and from the results I found, there seems to be no way to restore the original object type when importing clixml?