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

Question

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

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

这篇关于IIS 7 中的配置选项的文章描述了每种方法，但我对以下几件事有点不确定：

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 所建议的，我将使用新的 IIS 7 托管代码管理 API（Microsoft.Web.Administration等）。您可以在 IIS7 上使用 IIS6 兼容性组件，这些组件为消费者维护旧式 ADSI API（但是新 IIS7 组件的包装器），并且它们大部分都可以工作。

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

拥有两个代码库（一个用于 IIS6，一个用于 IIS7）可能看起来工作量很大，但说实话，这也不算太糟糕。我为一名托管服务商工作，一直走这条路，我们硬着头皮决定保留旧的 IIS6 代码，但从 IIS7 重新开始。