为什么我会选择 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，并且正在为单独的应用程序编写另一组 cmdlet。

Answer 2

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

Answer 3

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

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

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

Answer 4

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