7

私は、App-V 用の PowerShell コマンドレットを利用するいくつかのユーティリティを作成してきました。興味深いのは、Microsoft がコマンドレットのみを文書化し、Powershell モジュールの背後で使用される .net アセンブリを文書化していないように見えることです。

これで、P/Invoke と COM 相互運用性に精通し、System.Management.Automation を使用して PowerShell セッションを作成し、コマンドレットを呼び出す方法を学びました。

でもなんか匂いが合わない。私は基本的に、自分のラッパー クラスを作成して、残りのコードから PowerShell の呼び出しを隠しています。a) powershell をバイパスしてその背後にあるマネージ ライブラリに直接アクセスするか、b) powershell コマンドレットの相互運用ライブラリを生成するためのより良いメカニズムが必要なようです。

Microsoft は最近 PS CmdLets を多用しているようで、基本的に相互運用する新しい API になりつつあります。

何か不足していますか？このシナリオで使用するのに適した戦略は何ですか?

4

2 に答える 2

1

大変なことですが、System.Managment.Automation を介してコマンドレットを操作し、その結果をパイプラインの反対側で厳密に型指定されたオブジェクトに変換することが、問題を解決する最も安定した方法になります。

Microsoft 独自の AppV Client トレイ アプリを見てください。実行するすべてのことを実行するために実行する powershell コマンドを提供します。

コマンドレットを提供するマネージ ライブラリをヒットすることに成功するかもしれませんが、ご指摘のとおり、コマンドレットは文書化されておらず、変更される可能性があります。それでも、Get-AppVirtualProcess から取得した AppVPackageData NoteProperty のように、powershell に行かないために見逃しているものがあるかもしれません。

于 2013-09-26T04:11:50.067 に答える
1

「におい」についてはあなたが正しいです。PowerShell をバイパスすることは、ユーティリティを記述するための最良の方法ではありません。その背後にある文書化されていないマネージド ライブラリは、コマンドレットよりもサイレントに変更される可能性が高いためです。このアプローチを使用すると、問題が発生する可能性があります。

組み合わせにくいものを組み合わせようとしています。解決策は、より自然な方法でコードを ps コマンドレットと組み合わせることができるプロキシを導入することです。

あなたの状況では、コマンドレットと自然な方法で通信し、必要な機能を提供する ps スクリプトを作成できます。C# コードでは、powershell.exe を呼び出すだけです。それもあなたに合わない場合は、System.Management.Automation を使用して PowerShell セッションを作成し、スクリプトを呼び出してください。PowerShell プロキシで文書化された ps コマンドレットと通信し (自然な PowerShell の方法)、C# コードから ps スクリプトと通信するようになったため (これにより、コードをより細かく制御できるようになります)、このアプローチはより安全です。

于 2013-09-25T19:48:19.143 に答える