O ADSI consulta contra o IIS não concordar com o Gerenciador de IIS, no Vista

Question

Usando Vista ...

Eu tenho um script que usa ADSI para ScriptMaps definido em um site IIS. É de javascript, executado dentro cscript.exe, e os olhares de código algo como isto:

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();

Quando eu olho no Gerenciador do IIS depois de executar o script, eu posso ver a nova entrada na lista de Mapeamentos de manipulador. Ele tem um nome estranho "AboMapperCustom-43155", que eu entendo vem da camada de compatibilidade IIS7 para ADSI.

Se, no Gerenciador do IIS, eu, em seguida, remover esses Mapeamentos de manipulador, em seguida, executar outro script ADSI para consultar a propriedade ScriptMaps, os ScriptMaps recuperados no script ainda lista a entrada que acabou de ser removido. Os resultados do script ADSI não concordar com a lista de "Mapeamentos de manipulador" mostrado no Gerenciador do IIS.

isso persistir mesmo após uma start / stop de IISADMIN e W3SVC.

É este o comportamento esperado? ADSI é suportado como um "modo de compatibilidade" no IIS7. É este um artefato de que?

Eu acredito que se o mapeamento de manipulador é removido do IIS Manager, então ele é realmente ido, embora ainda se voltou de uma consulta ADSI.

Alguém pode oferecer qualquer esclarecimento sobre este assunto?

Answer 1

Quando você adiciona um 'mapa de script' usando os bits de compatibilidade ADSI (usando o Default Web Site para a causa do argumento), isto adiciona um mapeamento de manipulador para o arquivo applicationHost.config para o site em:

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

Quando você excluir o mapeamento de manipulador no gerenciador IIS7, em vez de remover o mapeamento do arquivo applicationHost.config ea seção mostrada acima, um arquivo web.config é adicionado à raiz do site com o seguinte:

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

Ao obter a configuração para um site usando a nova API gerenciada Microsoft.Web.Administration .NET você pode ler a configuração em diferentes níveis, por exemplo:

1: Leia a configuração no nível APPHOST applicationHost.config ou

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);
}

No exemplo acima, mesmo que você tenha removido o mapeamento, ele ainda será listado quando a iteração da coleção mapeamento de manipulador. Isso porque você pediu a configuração no nível do host do aplicativo. Quaisquer arquivos web.config que existem na raiz do site ou abaixo não irá ser lido e suas diretrizes <add/> e <remove/> manipulador não será incluído.

2: Você pode ler a configuração que é específico para um site (ou subpasta em um site):

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);
}

Isso também irá ler o arquivo local web.config e retornará uma lista de mapeamento de manipulador que contas para as directivas <add/> e <remove/> especificado no web.config.

Isto é o que a aplicação IIS7 Manager está fazendo quando você estiver vendo e modificar mapeamentos de manipulador. É adicionar e remover manipuladores criando (se necessário) um arquivo web.config na pasta raiz do site (ou subpastas) e adicionando o <add/> necessária e <remove/> a este nível.

A camada de compatibilidade IIS6 parece operar apenas no nível applicationHost.config APPHOST (opção 1 acima) e é por isso que você está vendo essas diferenças.

É um bug? Eu não tenho certeza que é porque em última análise, ADSI não foi web.config conscientes, em primeiro lugar. Também MS teria que adicionar um novo método ou bandeira para permitir que você especificar em que nível você realmente quer fazer essas mudanças 'mapa de script' e que pode significar quebrar e testar os componentes ADSI, que por sua vez podem introduzir erros. O comportamento é lá para simular modificar o velho metabase IIS6, e applicationHost.config está em vigor análoga à metabase para que você poderia argumentar, com razão ou não, ele está fazendo a coisa certa.