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

我会选择PowerShell而不是WMI，原因如下： 编写cmdlet只是添加.NET类。 PowerShell运行时提供内置的命令行解析。 在PowerShell中编写管理界面使管理员能够将应用程序的管理与其他应用程序和服务（如Exchange，Active Directory或SQL Server）的管理集成在一起。 PowerShell环境使管道可供管道使用，从而可以更有效地完成应用程序的管理任务。 可发现性。 PowerShell通过Get-Command，Get-Member和Get-Help为管理员提供了一个极易发现的环境，从而缩短了维护应用程序的学习时间。 即使您使用WMI路由，PowerShell也支持使用WMI（尽管有一些小问题）。 对我而言，PowerShell是面向应用程序的面向任务的界面的最佳方式。在Microsoft提供PowerShell的支持下，它将成为整个企业中管理应用程序和服务的一致界面。 我的日常工作是作为管理员，我正在推动所有与我合作的供应商展示PowerShell管理API，因为这使得管理应用程序的学习曲线和上下文切换更低。在开发方面，我已经编写了（并且仍在开发）一系列PowerShell cmdlet，用于我使用的一个开源产品，并且正在为另一个应用程序工作。     

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

我不确定我会做出决定。它不是 - 或者......你可以选择两者兼顾。 WMI可以被许多不同的东西使用，而不仅仅是PowerShell。为什么不在PowerShell中编写管理工具，然后将WMI包装在一些面向任务的cmdlet中以使管理员更容易？这就是一些MS产品团队选择做的事情，特别是当他们有其他WMI消费者他们想要继续支持时。 如果您已经拥有合适的.NET代码，那么将其转换为cmdlet可能比将其转换为WMI提供程序要快。如果是这种情况，速度是一个问题，那就更容易了。但无论您做什么，您都可以将其包装在管理员的PowerShell cmdlet中，这绝对是推荐的方法。     

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