我一直在为App编写一些使用PowerShell Cmdlet的实用程序。有趣的是,微软似乎只记录了cmdlet,而不是Powershell模块后面使用的.net程序集。
现在,我熟悉了P/Invoke和create,并且学习了如何使用System.Management.Automation创建powershell会话并调用cmdlet。
但有些东西闻起来不太对劲。我基本上是在编写自己的包装器类,以将powershell调用隐藏在代码的其余部分中。似乎我应该( a)绕过powershell,直接转到它后面的托管库,或者( b)应该有更好的机制为powershell cmdlet生成互操作库。
现在看来,微软正在大量使用PS CmdLets,实际上它正在成为一种新的可互操作的API。
我是不是遗漏了什么?在这种情况下,有什么好的策略可以使用?
发布于 2013-09-25 19:48:19
你说的“气味”是对的。绕过powershell并不是编写实用程序的最佳方式,因为它背后的无文档托管库比cmdlet更可能悄无声息地改变。使用这种方法会给你带来麻烦。
你正试图将难以组合的事物结合起来。解决方案是引入一个代理,它允许以更自然的方式将您的代码与ps结合起来。
在您的情况下,可以创建ps脚本,以自然的方式与cmdlet通信,并提供必要的功能。在c#代码中,您可以简单地调用powershell.exe。如果这也不适合您,那么只需使用System.Management.Automation创建powershell会话并调用脚本即可。这种方法更安全,因为现在您可以使用powershell代理(自然powershell方式)与已记录的ps cmdlet进行通信,并通过c#代码与ps脚本进行通信(这使您能够更好地控制代码)。
发布于 2013-09-26 04:11:50
通过System.Managment.Automation与cmdlet交互并将结果转换为管道另一端的强类型对象是解决问题的最稳定的方法,这是非常痛苦的。
看看微软自己的AppV客户端托盘应用。它提供了它运行的powershell命令来完成它所做的一切。
您可能成功地访问了提供cmdlet的托管库,但正如您所指出的,它们是无文档的,很可能在您的领导下发生变化。即使如此,也可能有一些东西您不想去powershell,比如从获得的AppVPackageData NoteProperty。
https://stackoverflow.com/questions/18876660
复制相似问题