为什么我会选择Powershell而不是WMI来开发管理界面？

Question

我们正在讨论为我们的分布式系统开发改进的管理基础架构。 我们使用COM，Web服务和.NET组件。由于我们基于Microsoft Windows Server XP / 2003，我猜，我们基本上有两种选择：

1. Powershell cmdlet
2. 使用System.Management和WMI提供程序的WMI类用于本机代码（类，实例，方法，事件）

为什么我们选择Powershell而不是WMI？

Answer 1

我会选择PowerShell而不是WMI，原因如下：

1. 编写cmdlet只是添加.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，因为这使得用于管理应用程序的学习曲线和上下文切换更低。在开发方面，我已经编写了（并且仍在开发）一系列PowerShell cmdlet，用于我使用的一个开源产品，并且正在为另一个应用程序开发另一个。

Answer 2

Jeffrey Snover回答“为什么选择PowerShell”here。帖子在SQL的上下文中，但非常适用于此。

Answer 3

我不确定我会做出决定。它不是 - 或者......你可以选择两者兼顾。

WMI可以被许多不同的东西使用，而不仅仅是PowerShell。为什么不在PowerShell中编写管理工具，然后将WMI包装在一些面向任务的cmdlet中以使管理员更容易？这就是一些MS产品团队选择做的事情，特别是当他们有其他WMI消费者时，他们希望继续支持。

如果您已经拥有合适的.NET代码，将其转换为cmdlet可能比将其转换为WMI提供程序要快。如果是这种情况，速度是一个问题，那就更容易了。但无论您做什么，您都可以将其包装在管理员的PowerShell cmdlet中，这绝对是推荐的方法。

Answer 4

不确定目前为止您提供的信息是否可以解答此问题。我的直觉是你应该使用powershell，因为听起来你可能已经有了一些.Net代码。但它确实只取决于你想要做什么。