ADSI Query против 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

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

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

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

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

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

1: считывание конфигурации на уровне applicationHost.config или APPHOST

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 APPHOST (вариант 1 выше), поэтому вы видите эти различия.

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