Что лучше для администрирования IIS в ASP.Net: WMI или ADSI или управляемый API? а какая разница? - PullRequest
Новая
       53

Что лучше для администрирования IIS в ASP.Net: WMI или ADSI или управляемый API? а какая разница?

4 голосов
/ 09 февраля 2010

Я работаю над настройкой, управлением и управлением IIS 6.0 и более поздних версий с использованием веб-приложения на основе ASP.Net. Я рассматриваю варианты WMI, ADSI, Managed 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 и неуправляемый код может быть использован, если это неизбежно.

Спасибо

Привет

Steve

Ответы [ 2 ]

4 голосов
/ 09 февраля 2010

Для IIS6 я бы использовал пространство имен System.DirectoryServices, которое является управляемой оболочкой для ADSI. Я считаю, что это проще в использовании по сравнению с работой с поставщиками IIS WMI.

Для IIS7, и, как Предложено , я бы использовал новый API администрирования управляемого кода IIS 7 (Microsoft.Web.Administration и др.). В IIS7 можно использовать компоненты совместимости IIS6, которые поддерживают API-интерфейсы ADSI старого стиля для потребителей (но являются оболочкой для новых компонентов IIS7), и они в основном работают.

Однако у вас возникают проблемы с оболочками ADSI. Например, они не знают свойств сопоставления обработчиков (аналогично карте сценариев IIS6), таких как preConditions, которые, например, позволяют нескольким версиям определений сопоставления обработчиков ASP.NET размещаться на одном сайте или в одном приложении. Уровень совместимости ADSI создаст объекты, известные как AboMapperCustom объекты, которые неоптимальны по своей конфигурации и не знают об этих новых функциях.

Наличие двух кодовых баз (одна для IIS6 и одна для IIS7) может показаться большой работой, но, честно говоря, это не так уж плохо. Я работаю на хостера, прошел этот путь, и мы укусили пулю и решили, что сохраним старый код IIS6, но начнем заново с IIS7.

4 голосов
/ 09 февраля 2010

Для IIS 7 и выше вы, вероятно, хотите IIS Management API . Я предполагаю, что вы уже прочитали сравнение MSDN технологий администрирования . Рассматривая только 1 проект, я бы использовал тот инструмент, который вам наиболее знаком. Все, что связано с прямыми манипуляциями с метабазой IIS, требует специальных усилий для изучения.

Учитывая кривую обучения, я решил использовать WMI. Он широко используется за пределами IIS, и освоение этого ощущается как хорошая инвестиция. C # поддерживает его хорошо. Если вы немного знакомы с PowerShell, вы можете легко изучить его с помощью объекта "gwmi". Если вы используете WMI из .NET, начните с управляемого генератора кода .

...