Interaction with PowerShell CmdLets

I wrote several utilities that use PowerShell cmdlets for App-V. An interesting part of Microsoft seems to only document cmdlets, not the .net collections used behind Powershell modules.

I am now familiar with P / Invoke and COM Interop, and I learned how to use System.Management.Automation to create a powershell session and call cmdlets.

But something doesn’t smell to me. I mostly write my own wrapper classes to hide powershell calls from the rest of my code. It seems that I should either a) bypass powershell and go directly to the managed library behind it, or b) there should be a better mechanism for creating interop libraries for powershell cmdlets.

Microsoft seems to be using PS CmdLets a lot these days, which is essentially becoming the new API to interact with.

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

+7
c # powershell cmdlets appv
source share
2 answers

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

You are trying to combine difficult to combine things. The solution is to introduce a proxy, which allows you to more naturally combine your code with ps command commands.

In your situation, you can create a ps script that naturally associates with cmdlets and provides the necessary functionality. In C # code, you can simply call powershell.exe. If this doesn't smell good to you, just use System.Management.Automation to create a powershell session and call the script. This approach is safer because now you are talking to documented ps cmdlets in your powershell proxy (the natural powershell path) and talking to your ps script with C # code (which gives you more control over the code)

+1
source share

However painful it may be, interacting with cmdlets through System.Managment.Automation and converting the results to strongly typed objects on the other side of the pipeline will be the most stable way to attack a problem.

Take a look at the Microsoft App Store app for your app. It provides powershell commands that it executes to do everything it does.

You may succeed in a managed library that provides cmdlets, but as you pointed out, they are undocumented and most likely will change from under you. Even then, there may be things that you don’t have enough to not use PowerShell, such as AppVPackageData NoteProperty, which you get from Get-AppVirtualProcess.

+1
source share

All Articles