Pourquoi devrais-je choisir Powershell plutôt que WMI pour développer des interfaces de gestion?

Question

Nous discutons du développement d'une infrastructure de gestion améliorée pour notre système distribué. Nous utilisons COM, des services Web et des composants .NET. Puisque nous sommes basés sur Microsoft Windows Server XP / 2003, nous avons essentiellement deux options:

1. Cmdlets Powershell
2. Classes WMI utilisant System.Management et les fournisseurs WMI pour le code natif (classe, instance, méthode, événement)

Pourquoi choisirions-nous Powershell plutôt que WMI?

Answer 1

Je choisirais PowerShell plutôt que WMI pour les raisons suivantes:

1. L'écriture d'une cmdlet consiste uniquement à ajouter une classe .NET.
2. Le moteur d'exécution de PowerShell fournit une analyse de ligne de commande intégrée.
3. L'écriture de votre interface de gestion dans PowerShell permet aux administrateurs d'intégrer la gestion de votre application à celle d'autres applications et services (comme Exchange, Active Directory ou SQL Server).
4. L'environnement PowerShell met le pipeline à la disposition des administrateurs, permettant ainsi aux tâches de gestion de votre application d'être effectuées plus efficacement.
5. découvrabilité. PowerShell, via Get-Command, Get-Member et Get-Help, fournit un environnement extrêmement facile à découvrir pour les administrateurs, ce qui permet une période d'apprentissage plus courte pour la maintenance de votre application.

Même si vous choisissez la route WMI, PowerShell prend en charge l’utilisation de WMI (même s’il ya quelques problèmes).

Pour moi, PowerShell est le meilleur moyen de faire apparaître une interface orientée tâche vers une application. Grâce au support fourni par Microsoft, PowerShell constitue une interface cohérente pour la gestion des applications et des services dans l’ensemble de l’entreprise.

Mon travail quotidien est celui d'administrateur et j'encourage tous les fournisseurs avec lesquels je travaille à faire apparaître une API de gestion PowerShell, car cela simplifie considérablement la courbe d'apprentissage et le changement de contexte pour la gestion des applications. En ce qui concerne le développement, j’ai écrit (et je travaille toujours sur) une série d’applets de commande PowerShell pour un produit open source avec lequel je travaille et un autre ensemble pour une application distincte.

Answer 2

Jeffrey Snover répond à la question "Pourquoi PowerShell"? ici . Le message est dans le contexte de SQL, mais très applicable ici.

Answer 3

Je ne suis pas sûr que je prendrais la décision. Ce n'est pas exactement l'un ou l'autre ... ou vous pouvez choisir de faire les deux.

WMI peut être consommé par un certain nombre de choses différentes, pas seulement par PowerShell. Pourquoi ne pas écrire votre instrumentation de gestion dans PowerShell, puis encapsuler ce WMI dans des applets de commande orientées tâches pour faciliter la tâche des administrateurs? C’est ce que certaines équipes de produits MS choisissent de faire, en particulier quand elles souhaitent continuer à prendre en charge d’autres utilisateurs de WMI.

Si vous disposez déjà du code .NET approprié, il peut être plus rapide de le convertir en applet de commande que de le transformer en fournisseur WMI. Si tel est le cas et que la vitesse pose problème, optez pour ce qui est plus facile. Mais quoi que vous fassiez, vous pouvez toujours le placer dans une applet de commande PowerShell pour les administrateurs, ce qui est sans aucun doute l'approche recommandée.

Answer 4

Vous n'êtes pas sûr de pouvoir répondre à cette question avec les informations que vous avez fournies jusqu'à présent. Mon sentiment est que vous devriez utiliser Powershell, car il semble que vous ayez peut-être déjà du code .Net. Mais cela dépend vraiment de ce que vous essayez de faire.