管理インターフェイスを開発するためにWMIではなくPowershellを選択するのはなぜですか？

Question

分散システムの改善された管理インフラストラクチャの開発について議論しています。 COM、Webサービス、および.NETコンポーネントを使用します。 Microsoft Windows Server XP / 2003に基づいているため、基本的に2つのオプションがあります。

1. Powershellコマンドレット
2. ネイティブコード（クラス、インスタンス、メソッド、イベント）にSystem.ManagementおよびWMIプロバイダーを使用するWMIクラス

WMIよりもPowershellを選択する理由

Answer 1

次の理由により、WMIよりもPowerShellを選択します。

1. コマンドレットの作成は、.NETクラスの追加のみです。
2. PowerShellランタイムには、コマンドライン解析が組み込まれています。
3. PowerShellで管理インターフェイスを作成すると、管理者はアプリケーションの管理を他のアプリケーションやサービス（Exchange、Active Directory、SQL Serverなど）の管理と統合できます。
4. PowerShell環境により、管理者はパイプラインを使用できるようになり、アプリケーションの管理タスクをより効率的に実行できます。
5. 検出可能性。 PowerShellは、Get-Command、Get-Member、およびGet-Helpを介して、管理者が作業するための非常に発見しやすい環境を提供します。その結果、アプリケーションを維持するための学習曲線が短くなります。

WMIルートを使用する場合でも、PowerShellはWMIの使用をサポートしています（ただし、いくつかの不具合があります）。

PowerShellは、アプリケーションへのタスク指向インターフェースを表示する最良の方法です。マイクロソフトはPowerShellを提供してきましたが、これは、企業全体でアプリケーションとサービスを管理するための一貫したインターフェイスです。

管理者としての私の仕事は、PowerShell管理APIの作成に取り組むすべてのベンダーに押し付けています。これにより、アプリケーションを管理するための学習曲線とコンテキスト切り替えがはるかに少なくなります。開発側では、私が作業する1つのオープンソース製品用の一連のPowerShellコマンドレットを作成し（現在も作業中）、別のアプリケーション用に別のセットを作成しています。

Answer 2

Jeffrey Snoverが「なぜPowerShellなのか」に答えます。 こちら。投稿はSQLのコンテキストで行われていますが、ここでは非常に適用可能です。

Answer 3

決定を下すかどうかはわかりません。どちらでもない-または...両方を選択できます。

WMIは、PowerShellだけでなく、さまざまなもので使用できます。 PowerShellで管理計装を作成し、そのWMIをタスク指向のコマンドレットでラップして、管理者の作業を容易にしませんか？これは、一部のMS製品チームが行うことを選択していることです。特に、サポートを継続したいWMIの他の消費者がいる場合はそうです。

既に適切な.NETコードを取得している場合、それをコマンドレットに変換する方が、WMIプロバイダーに変換するよりも高速です。それが事実であり、速度が懸念される場合は、より簡単な方法で行ってください。ただし、何をするにしても、管理者用のPowerShellコマンドレットでいつでもラップできます。これは間違いなく推奨されるアプローチです。

Answer 4

これまでに提供した情報でこれに答えられるかどうかはわかりません。私の直感では、既に.Netコードを持っているように聞こえるので、PowerShellを使用する必要があります。しかし、それは本当にあなたがやろうとしていることに正確に依存しています。