ASP.Net中的IIS管理更好：WMI或ADSI或托管API？有什么区别？

Question

我正在使用基于ASP.Net的Web应用程序配置和操作和控制IIS 6.0及更高版本。我正在考虑将WMI，ADSI，托管API作为我的选项。

我有一个目标Windows系统WIN2k3或更高版本。语言的选择是C＃，应用程序必须使用ASP.Net构建。

本文介绍了每种方法，但我对某些方面有些不确定; http://learn.iis.net/page.aspx/283/provisioning-options-in-iis7/rev/1

我对这些选项有以下问题。

1. 对于所述目标哪个更好或更强大？ ADSI（System.DirectoryServices）或WMI（Microsoft.Web.Management）还是托管API（Microsoft.Web.Administratoion）？纠正我，如果我在这里做错了什么。

2. 下一版本的IIS可能支持哪种选项或技术？

3. 哪个选项具有最大的灵活性和可扩展性？
4. 从哪里可以找到任何建议/选择的技术资源？

我不太可能在II5.1或更低版本上工作。所以兼容区域从IIS 6.0及更高版本开始。应用程序必须使用ASP.Net构建，如果不可避免，可能会使用未受管理的代码。

感谢

问候

史蒂夫

Answer 1

对于IIS6我会使用System.DirectoryServices命名空间，它是ADSI的托管包装器。与使用IIS WMI提供程序相比，我发现使用起来更简单。

对于IIS7和Precipitous suggested，我会使用新的IIS 7托管代码管理API（Microsoft.Web.Administration等）。您可以在IIS7上使用IIS6兼容性组件，它们为消费者维护旧式ADSI API（但是是新IIS7组件的封装），并且它们大多可以工作。

但是，您确实遇到ADSI包装问题。例如，他们不知道处理程序映射（类似于IIS6脚本映射）属性，例如preConditions，例如，它允许多个版本的ASP.NET处理程序映射定义共同驻留在同一个站点或应用程序中。ADSI兼容性层将创建名为AboMapperCustom的对象，这些对象在其配置中次优，并且不知道这些新功能。

有两个代码库（一个用于IIS6和一个用于IIS7）可能看起来像很多工作，但说实话这是不是太糟糕。我为托管人工作，一直走在这条路上，我们咬紧牙关，决定保留旧的IIS6代码，但重新开始使用IIS7。

Answer 2

对于IIS 7及以上，你可能想IIS Management API。我假设你已经阅读MSDN comparison of administration technologies。考虑到只有一个项目，我会使用你最熟悉的工具。涉及对IIS元数据库的直接操作的任何事情都需要专心学习。

鉴于学习曲线，我选择使用WMI。它在IIS之外广泛使用，掌握它感觉像是一个很好的投资。 C＃支持它。如果您知道一些PowerShell，可以使用“gwmi”对象轻松探索它。如果使用.NET中的WMI，则从managed code generator开始。