Interoping With PowerShell CmdLets

问题:

I've been writing some utilities that make use of PowerShell Cmdlets for App-V. The interesting part is Microsoft seems to only document the cmdlets and not the .net assemblies used behind the Powershell modules.

Now I'm familiar with P/Invoke and COM Interop and I've learned how to use System.Management.Automation to create a powershell session and invoke the cmdlets.

But something doesn't smell right to me. I'm basically writing my own wrapper classes to hide the powershell invocations from the rest of my code. It seems like I should either a) bypass powershell and go straight for the managed library behind it or b) there should be better mechanism for generating interop libraries for powershell cmdlets.

It seems like Microsoft is making a lot of use of PS CmdLets these days that it's essentially becoming a new API to interop with.

Am I missing something? What's a good strategy to use in this scenario?

回答1:

You are right about the "smell". Bypassing the powershell is not the best way to write your utility, because undocumented managed library behind it are more likely to change silently than cmdlets. Using this approach can get you into trouble.

You are trying to combine hardly combinable things. Solution is to introduce a proxy that allows to combine your code with ps cmdlets in more natural way.

In your situation the ps script can be creates that communicates with cmdlets in natural way and provides the necessary functonality. In your c# code you can simply call the powershell.exe. If that doesn't smell right for you as well, then just use System.Management.Automation to create powershell session and invoke your script. This approach is safer, because now you communicate with documented ps cmdlets in your powershell proxy(natural powershell way), and communicate with your ps script from c# code (that gives you more control over the code)

回答2:

As painful as it is, interacting with the cmdlets through System.Managment.Automation and converting the results into strongly typed objects on the other side of the pipeline is going to be the most stable way to attack the problem.

Look at Microsoft's own AppV Client tray app. It provides the powershell commands that it runs to accomplish everything that it does.

You might have success hitting the managed library that provides the cmdlets, but as you pointed out, they're undocumented and likely to change out from under you. Even then, there may be things that you're missing not going to powershell, like the AppVPackageData NoteProperty that you get from Get-AppVirtualProcess.