Если вы вызываете интерфейс командной строки PowerShell с -File
, все аргументы неизменно преобразуются в строки , поэтому ваша безопасная строка не будет работать (она преобразуется в обычную строку с литерал содержимое System.Security.SecureString
).
Чтобы (в основном) сохранить типы аргументов, вы должны передать блок сценария , который вызываетPowerShell для автоматической сериализации и десериализации аргументов с сохранением типов [1] , который правильно сохраняет [securestring]
экземпляров, но учтите, что этот метод работает только при вызове из PowerShell (тоже):
if (-not $thisAppDomain)
{
Write-Host "Invoking script in a new app domain"
powershell -Command {
$script, $splat = $Args # parse the args array into distinct variables
. $script -thisAppDomain @splat # call the script with splatting
} -args $PSCommandPath, $PSBoundParameters
return
}
Обратите внимание, как значения из контекста вызывающей стороны, на которые нужно сослаться в блоке сценария, который будет выполняться в сеансе new , должны передаваться какаргументы , через -args <arg-array>
- см. Get-Help about_powershell.exe
или запустите powershell -?
для получения более краткой справки.
Примечание : As Патрик Майнеке указывает на вышеприведенный подход, в котором используется преобразованныйСтрока ommand с зашифрованной строкой в кодировке Base64 может гипотетически потерпеть неудачу из-за превышения макс.длина командной строки, которая составляет 32 768 символов в Windows 10 (см. CreateProcess
функция WinAPI ).
При этом, если вы не передадите исключительно большие блоки скриптов и / или сотни аргументов, вы 'маловероятно, что он достигнет этого предела.
[1] Такой же тип сериализации также используется, например, в удаленном взаимодействии PowerShell и в фоновых заданиях.Обратите внимание, что не только фиксированный набор типов может быть точно десериализован, но PowerShell делает все возможное, чтобы эмулировать других типов с пользовательскими объектами , которые имеют те же свойства.