我一直在编写一些为App-V使用PowerShell Cmdlet的实用程序。有趣的是,Microsoft似乎只记录了cmdlet,而不是Powershell模块后面使用的.net程序集。
现在我熟悉P / Invoke和COM Interop,我已经学会了如何使用System.Management.Automation创建一个PowerShell会话并调用cmdlet。
但有些东西对我来说没有味道。我基本上编写自己的包装类来隐藏其余代码中的powershell调用。看起来我应该a)绕过powershell并直接进入它后面的托管库,或者b)应该有更好的机制来为PowerShell cmdlet生成互操作库。
似乎微软现在大量使用PS CmdLets,它实际上已经成为一个新的互操作API。
我错过了什么吗?在这种情况下使用什么是好策略?
答案 0 :(得分:1)
你对“气味”是正确的。 绕过powershell并不是编写实用程序的最佳方法,因为它背后的无证件托管库比cmdlet更可能无声地更改。使用这种方法可能会让您陷入困境。
你正试图结合几乎无法组合的东西。 解决方案是引入一个代理,允许以更自然的方式将代码与ps cmdlet结合使用。
在您的情况下,ps脚本可以是以自然方式与cmdlet通信的创建,并提供必要的功能。在您的c#代码中,您只需调用powershell.exe即可。如果这也不适合你,那么只需使用System.Management.Automation来创建powershell会话并调用你的脚本。这种方法更安全,因为现在您使用powershell代理(自然PowerShell方式)与已记录的ps cmdlet进行通信,并通过c#代码与您的ps脚本进行通信(这使您可以更好地控制代码)
答案 1 :(得分:1)
尽管很痛苦,但是通过System.Managment.Automation与cmdlet进行交互并将结果转换为管道另一侧的强类型对象将是解决问题的最稳定方法。
查看Microsoft自己的AppV客户端托盘应用程序。它提供了运行的powershell命令来完成它所做的一切。
您可能成功点击提供cmdlet的托管库,但正如您所指出的那样,它们没有文档记录,可能会从您下面更改。即便如此,也许有些事情你不会想到PowerShell,比如你从Get-AppVirtualProcess获得的AppVPackageData NoteProperty。