Запрос ADSI к IIS не согласуется с IIS Manager в Vista

Question

Используя Vista...

У меня есть скрипт, который использует ADSI для установки ScriptMaps на веб-сайте IIS.Это javascript, запускаемый внутри cscript.exe, и код выглядит примерно так:

var web = GetObject("IIS://localhost/W3SVC/1");
var maps = web.ScriptMaps.toArray();
map[maps.length] = ".aaa,c:\\path\\to\\isapi\\extension.dll,1,GET,POST";
web.ScriptMaps = maps.asDictionary();
web.SetInfo();

Когда я заглядываю в диспетчер IIS после запуска скрипта, я вижу новую запись в списке сопоставлений обработчиков.У него странное название "AboMapperCustom-43155", которое, как я понимаю, происходит из уровня совместимости IIS7 для ADSI.

Если в диспетчере IIS я затем удалю эти сопоставления обработчиков, а затем запущу другой скрипт ADSI для запроса свойства ScriptMaps, в извлеченных ScriptMaps в скрипте все еще будет указана запись, которая была только что удалена.Результаты в скрипте ADSI не согласуются со списком "Сопоставлений обработчиков", показанным в диспетчере IIS.

Это сохраняется даже после запуска / остановки IISADMIN и W3SVC.

Является ли это ожидаемым поведением?ADSI поддерживается в качестве "режима совместимости" в IIS7.Это что, артефакт того самого?

Я считаю, что если сопоставление обработчика удалено из IIS MAnager, то оно действительно исчезло, даже если оно по-прежнему возвращается из запроса ADSI.

Кто-нибудь может дать какие-либо разъяснения по этому поводу?

Answer 1

Когда вы добавляете "scriptmap", используя биты совместимости с ADSI (используя веб-сайт по умолчанию в качестве аргумента), это добавляет отображение обработчика в applicationHost.config файл для сайта находится по адресу:

<location path="Default Web Site">
  <system.webServer>
    <handlers>
        <add name="AboMapperCustom-12345678" ... />
    </handlers>
  </system>
</location>

Когда вы удаляете сопоставление обработчика в диспетчере IIS7, вместо удаления сопоставления из applicationHost.config файл и раздел, показанный выше, a web.config файл добавляется в корневой каталог сайта со следующим:

<configuration>
  <system.webServer>
    <handlers>
        <remove name="AboMapperCustom-12345678" />
    </handlers>
  </system>
</configuration>

При получении конфигурации для веб-сайта с использованием нового управляемого Microsoft.Web.Administration .NET API вы можете прочитать конфигурацию на разных уровнях, например:

1:Ознакомьтесь с конфигурацией на сайте applicationHost.config или уровень хостинга приложений

ServerManager serverManager = new ServerManager();
var site = serverManager.Sites.Where(s => s.Id == 1).SingleOrDefault();
Configuration siteConfig = serverManager.GetApplicationHostConfiguration();
ConfigurationSection handlersSection = 
     siteConfig.GetSection("system.webServer/handlers", site.Name);
ConfigurationElementCollection handlersCollection = 
     handlersSection.GetCollection();

foreach (var item in handlersCollection)
{
    Console.WriteLine(item.Attributes["name"].Value);
}

В приведенном выше примере, даже если вы удалили сопоставление, оно все равно будет указано при повторении коллекции сопоставлений обработчика.Это потому, что вы запросили конфигурацию на уровне хоста приложения.Любой web.config файлы, существующие в корневом каталоге сайта или ниже, не будут прочитаны, и их обработчик <add/> и <remove/> директивы включены не будут.

2:Вы можете ознакомиться с конфигурацией, специфичной для сайта (или вложенной папки на сайте).:

ServerManager serverManager = new ServerManager();
Configuration siteConfig = serverManager.GetWebConfiguration("Default Web Site");    
ConfigurationSection handlersSection = 
    siteConfig.GetSection("system.webServer/handlers");
ConfigurationElementCollection handlersCollection = 
    handlersSection.GetCollection();

foreach (var item in handlersCollection)
{
    Console.WriteLine(item.Attributes["name"].Value);
}

Это также позволит ознакомиться с сайтом web.config файл и вернет список сопоставления обработчика, который учитывает <add/> и <remove/> директивы, указанные в web.config.

Это то, что делает приложение IIS7 Manager, когда вы просматриваете и изменяете сопоставления обработчиков.Это добавление и удаление обработчиков путем создания (при необходимости) web.config файл в корневой папке сайта (или вложенных папках) и добавление необходимых <add/> и <remove/> на этом уровне.

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

Это ошибка?Я не уверен, что это так, потому что в конечном счете ADSI никогда не была web.config осознающий в первую очередь.Также MS пришлось бы добавить новый метод или флаг, позволяющий вам указать, на каком уровне вы действительно хотите внести эти изменения в "scriptmap", и это может означать взлом и тестирование компонентов ADSI, что, в свою очередь, может привести к ошибкам.Поведение предназначено для имитации модификации старой метабазы IIS6, и applicationHost.config по сути, он аналогичен метабазе, так что вы можете утверждать, справедливо или ошибочно, что он поступает правильно.