我一直在为 App-V 编写一些使用 PowerShell Cmdlet 的实用程序。有趣的是，微软似乎只记录了 cmdlet，而不是 Powershell 模块后面使用的 .net 程序集。
现在我熟悉了 P/Invoke 和 COM 互操作，并且学会了如何使用 System.Management.Automation 创建一个 powershell 会话并调用 cmdlet。
但是我觉得有些不对劲。我基本上是在编写自己的包装类来隐藏我的其余代码中的 powershell 调用。看来我应该a）绕过powershell并直接使用它后面的托管库，或者b）应该有更好的机制来为powershell cmdlet生成互操作库。
这些天来，微软似乎在大量使用 PS CmdLets，它本质上正在成为一种新的互操作 API。
我错过了什么吗？在这种情况下使用什么好的策略？
尽管很痛苦，但通过 System.Managment.Automation 与 cmdlet 交互并将结果转换为管道另一端的强类型对象将是解决问题的最稳定方法。
看看微软自己的 AppV Client 托盘应用。它提供了它运行的 powershell 命令来完成它所做的一切。
您可能成功地访问了提供 cmdlet 的托管库，但正如您所指出的，它们没有记录在案，并且可能会从您的手下发生变化。即便如此，您可能会缺少一些不使用 powershell 的东西，例如您从 Get-AppVirtualProcess 获得的 AppVPackageData NoteProperty。
你对“气味”是正确的。绕过 powershell 并不是编写实用程序的最佳方式，因为它背后的未记录托管库比 cmdlet 更有可能静默更改。使用这种方法可能会给您带来麻烦。
您正在尝试组合几乎无法组合的事物。解决方案是引入一个代理，允许以更自然的方式将您的代码与 ps cmdlet 结合起来。
在您的情况下，可以创建以自然方式与 cmdlet 通信并提供必要功能的 ps 脚本。在您的 c# 代码中，您可以简单地调用 powershell.exe。如果这也不适合您，那么只需使用 System.Management.Automation 创建 powershell 会话并调用您的脚本。这种方法更安全，因为现在您可以在 powershell 代理中与记录在案的 ps cmdlet 进行通信（自然 powershell 方式），并通过 c# 代码与您的 ps 脚本进行通信（这使您可以更好地控制代码）