11

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

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

WMIではなくPowershellを選択するのはなぜですか？

4

4 に答える 4

10

次の理由から、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 は、タスク指向のインターフェイスをアプリケーションに表示するための最良の方法です。Microsoft が提供してきたサポートにより、PowerShell は企業全体でアプリケーションとサービスを管理するための一貫したインターフェイスになります。

私の日常の仕事は管理者であり、アプリケーションを管理するための学習曲線とコンテキストの切り替えがはるかに少なくなるため、PowerShell 管理 API を表面化するように協力するすべてのベンダーを推進しています。開発面では、私が使用している 1 つのオープン ソース製品用に一連の PowerShell コマンドレットを作成し (現在も作業中)、別のアプリケーション用の別のセットに取り組んでいます。

于 2008-11-03T19:16:23.790 に答える
4

Jeffrey Snover が「PowerShell を使用する理由」についてここで回答しています。投稿は SQL のコンテキストにありますが、ここでも非常に当てはまります。

于 2008-11-03T19:35:25.640 に答える
2

私が決断を下すかどうかはわかりません。正確にはどちらかではありません... 両方を行うことを選択できます。

WMI は、PowerShell だけでなく、さまざまなもので使用できます。管理ツールを PowerShell で作成し、その WMI をいくつかのタスク指向のコマンドレットでラップして、管理者の負担を軽減してみませんか? 一部の MS 製品チームは、特にサポートを継続したい WMI の利用者が他にいる場合に、そうすることにしています。

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

于 2008-11-24T21:54:29.743 に答える
0

これまでに提供された情報でこれに答えられるかどうかはわかりません。私の直感では、.Net コードが既にいくつかあるように聞こえるので、powershell を使用する必要があります。しかし、それは実際に何をしようとしているのかによって異なります。

于 2008-11-03T17:04:56.940 に答える