- Existuje způsob, jak získat správný/očekávaný typ proměnné, který má být vrácen při volání
Receive-Job?
Kvůli použití úlohy na pozadí ztratíte přesnost písma :objekty, které získáváte zpět, jsou emulace bez metod původních typů.
Ruční znovuvytvoření původních typů nestojí za námahu a nemusí být ani možné – i když práce s emulacemi možná postačí.
Aktualizovat :Podle vaší vlastní odpovědi přechod z práce s System.DataSet do System.DataTable výsledkem jsou použitelné emulace.
Další informace naleznete ve spodní části.
- Existuje lepší způsob, jak spouštět dotazy SQL pod jiným účtem AD pomocí příkazu Invoke-Sqlcmd?
Potřebujete probíhající způsob vyvolání za účelem zachování typové věrnosti , ale nemyslím si, že je to možné pomocí libovolných příkazů, pokud chcete předstírat identitu jiného uživatele .
Například v procesu (založená na vláknech) alternativa k Start-Job - Start-ThreadJob - nemá -Credential parametr.
Nejlepším řešením je proto zkusit vytvořit Invoke-SqlCmd 's -Credential parametr pracovat za vás, nebo najít jiný průběžný způsob spouštění dotazů s přihlašovacími údaji daného uživatele.
Serializace a deseralizace objektů v úlohách na pozadí / vzdálená komunikace / mini-shell:
Kdykoli PowerShell zařazuje objekty přes hranice procesu , využívá serializaci založenou na XML u zdroje a deserializaci v místě určení pomocí formátu známého jako CLI XML (Common Language Infrastructure XML).
To se děje v kontextu Vzdáleného ovládání PowerShell (např. Invoke-Command volá s -ComputerName parametr) a také v úlohách na pozadí (Start-Job ) a tzv. miniskořápky (které se implicitně používají, když voláte rozhraní příkazového řádku PowerShell zevnitř samotného PowerShellu pomocí bloku skriptu; např. powershell.exe { Get-Item / } ).
Tato deseralizace zachovává věrnost typu pouze pro omezenou sadu známých typů , jak je uvedeno v MS-PSRP, specifikaci protokolu PowerShell Remoting Protocol. To znamená, že pouze instance pevné sady typů jsou deserializovány jako jejich původní typ .
Instance všech ostatních typů jsou emulovány :typy podobné seznamům se stanou [System.Collections.ArrayList] v instancích se typy slovníků stanou [hasthable] instance a další typy stanou se vlastními objekty bez metod (pouze vlastnosti) ([pscustomobject] instance) , jehož .pstypenames vlastnost obsahuje původní název typu s předponou Deserialized. (např. Deserialized.System.Data.DataTable ), stejně jako názvy základu typu se stejnou předponou typy (hierarchie dědičnosti).
Navíc hloubka rekurze pro objektové grafy ne -[pscustomobject] instance je omezena na 1 úroveň - Všimněte si, že to zahrnuje instanci vlastních tříd PowerShellu , vytvořený pomocí class klíčové slovo:To znamená, pokud hodnoty vlastností vstupního objektu nejsou instancí dobře známých typů samy o sobě (druhé zahrnují typy pouze s jednou hodnotou, včetně primitivních typů .NET, jako je [int] , na rozdíl od typů složených z více vlastností) jsou nahrazeny jejich .ToString() reprezentace (např. zadejte System.IO.DirectoryInfo má .Parent vlastnost, která je další System.IO.DirectoryInfo instance, což znamená, že .Parent hodnota vlastnosti se serializuje jako .ToString() reprezentace této instance, což je její úplný řetězec cesty); ve zkratce:Nevlastní (skalární) objekty se serializují tak, že hodnoty vlastností, které samy nejsou instancemi dobře známých typů, jsou nahrazeny jejich .ToString() zastoupení ; viz tato odpověď pro konkrétní příklad.
Naproti tomu explicitní použití serializace CLI XML prostřednictvím Export-Clixml výchozí je hloubka 2 (vlastní hloubku můžete určit pomocí -Depth a podobně můžete ovládat hloubku, pokud použijete základní System.Management.Automation.PSSerializer zadejte přímo ).
V závislosti na původním typu můžete být schopen rekonstruovat instance původního typu ručně , ale to není zaručeno. (Úplný název původního typu můžete získat voláním .pstypenames[0] -replace '^Deserialized\.' na daný uživatelský objekt.)
V závislosti na vašich potřebách zpracování však emulace původních objektů může být dostačující.