La consulta ADSI contra IIS no concuerda con el Administrador de IIS, en Vista

Question

Usando Vista...

Tengo un script que usa ADSI para configurar ScriptMaps en un sitio web IIS.Es javascript, se ejecuta dentro de cscript.exe y el código se parece a este:

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

Cuando miro en el Administrador de IIS después de ejecutar el script, puedo ver la nueva entrada en la lista de Asignaciones de controladores.Tiene un nombre extraño "AboMapperCustom-43155", que según tengo entendido proviene de la capa de compatibilidad IIS7 para ADSI.

Si, en el Administrador de IIS, elimino esas asignaciones de controladores y luego ejecuto otro script ADSI para consultar la propiedad ScriptMaps, los ScriptMaps recuperados en el script aún enumeran la entrada que se acaba de eliminar.Los resultados del script ADSI no concuerdan con la lista de "Asignaciones de controladores" que se muestra en el Administrador de IIS.

Esto persiste incluso después de un inicio/detención de IISADMIN y W3SVC.

¿Es este el comportamiento esperado?ADSI es compatible como "modo de compatibilidad" en IIS7.¿Es esto un artefacto de eso?

Creo que si se elimina el mapeo de controladores de IIS MAnager, entonces realmente desaparece, aunque todavía se devuelve de una consulta ADSI.

¿Alguien puede ofrecer alguna aclaración sobre esto?

Answer 1

Cuando agrega un 'mapa de secuencia de comandos' usando los bits de compatibilidad ADSI (usando el sitio web predeterminado por el bien del argumento), esto agrega una asignación de controlador al applicationHost.config archivo para el sitio en:

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

Cuando elimina la asignación del controlador en el administrador de IIS7, en lugar de eliminar la asignación del applicationHost.config archivo y la sección que se muestra arriba, una web.config El archivo se agrega a la raíz del sitio con lo siguiente:

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

Al obtener la configuración de un sitio web utilizando el nuevo administrador Microsoft.Web.Administration API .NET puede leer la configuración en diferentes niveles, por ejemplo:

1:Lea la configuración en el applicationHost.config o nivel 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);
}

En el ejemplo anterior, aunque haya eliminado la asignación, seguirá apareciendo en la lista al iterar la colección de asignaciones del controlador.Esto se debe a que solicitó la configuración en el nivel de host de la aplicación.Cualquier web.config Los archivos que existen en la raíz del sitio o debajo no se leerán y su controlador <add/> y <remove/> No se incluirán directivas.

2:Puede leer la configuración específica de un sitio (o subcarpeta de un sitio):

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

Esto también leerá el sitio. web.config archivo y devolverá una lista de mapeo de controladores que representa el <add/> y <remove/> directivas especificadas en el web.config.

Esto es lo que hace la aplicación IIS7 Manager cuando visualiza y modifica las asignaciones de controladores.Es agregar y eliminar controladores creando (si es necesario) un web.config archivo en la carpeta raíz del sitio (o subcarpetas) y agregando el requisito <add/> y <remove/> en este nivel.

La capa de compatibilidad IIS6 parece funcionar únicamente en el applicationHost.config Nivel APPHOST (opción 1 anterior), por lo que estás viendo estas diferencias.

¿Es un error?No estoy seguro de que sea porque, en última instancia, ADSI nunca fue web.config consciente en primer lugar.Además, MS tendría que agregar un nuevo método o indicador que le permita especificar en qué nivel realmente desea realizar estos cambios en el 'mapa de script' y eso puede significar romper y probar los componentes ADSI, lo que a su vez puede introducir errores.El comportamiento está ahí para simular la modificación de la antigua metabase de IIS6 y applicationHost.config De hecho, es análogo a la metabase, por lo que se podría argumentar, con razón o sin ella, que está haciendo lo correcto.