11

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

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

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

4

4 回答 4

10

出于以下原因，我会选择 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，并且正在为单独的应用程序开发另一组。

于 2008-11-03T19:16:23.790 回答
4

Jeffrey Snover 在此处回答“为什么使用 PowerShell” 。这篇文章是在 SQL 的上下文中，但在这里非常适用。

于 2008-11-03T19:35:25.640 回答
2

我不确定我会做出决定。这不完全是非此即彼的……您可以选择两者兼而有之。

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

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

于 2008-11-24T21:54:29.743 回答
0

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

于 2008-11-03T17:04:56.940 回答