ADSI requête sur IIS ne sont pas d'accord avec Gestionnaire des services Internet, sur Vista

Question

En utilisant Vista ...

J'ai un script qui utilise ADSI pour définir ScriptMaps sur un site Web IIS. Il est le javascript, exécuter dans cscript.exe, et le code ressemble à ceci:

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

Quand je regarde dans le Gestionnaire des services Internet après l'exécution du script, je peux voir la nouvelle entrée dans la liste des Mappages. Il a un nom étrange "AboMapperCustom-43155", que je comprends provient de la couche de compatibilité IIS7 pour ADSI. Si, dans le Gestionnaire des services Internet, je supprime ensuite ces mappages de gestionnaires, puis exécute un autre script ADSI pour interroger la propriété ScriptMaps, les scripts récupérés dans le script indiquent toujours l'entrée qui vient d'être supprimée. Les résultats dans le script ADSI ne sont pas en accord avec la liste des "Mappages de gestionnaires" affichée dans le Gestionnaire des services Internet.

Ceci persiste même après un démarrage/arrêt de IISADMIN et W3SVC.

Est-ce que ce comportement est attendu? ADSI est pris en charge en tant que "mode de compatibilité" dans IIS7. Est-ce un artefact de cela?

Je crois que si le mappage du gestionnaire est supprimé d'IIS MAnager, il est définitivement supprimé, même s'il est toujours renvoyé à partir d'une requête ADSI.

Quelqu'un peut-il apporter des éclaircissements à ce sujet?

Answer 1

Lorsque vous ajoutez un « scriptmap » en utilisant les bits de compatibilité ADSI (en utilisant le site Web par défaut pour les besoins du raisonnement), cela ajoute un mappage de gestionnaire dans le fichier applicationHost.config pour le site à l'adresse:

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

Lorsque vous supprimez le mappage de gestionnaire dans le gestionnaire IIS7, au lieu de supprimer le mappage du fichier applicationHost.config et la section ci-dessus, un fichier web.config est ajouté à la racine du site avec les éléments suivants:

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

Lors de l'obtention de la configuration d'un site Web en utilisant la nouvelle gestion Microsoft.Web.Administration API .NET, vous pouvez lire la configuration à différents niveaux, par exemple:

1: Lisez la configuration au niveau applicationHost.config ou 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); 
} 

Dans l'exemple ci-dessus, même si vous avez supprimé le mappage, il sera toujours répertorié lors de l'itération de la collection de mappages de gestionnaires. Ceci parce que vous avez demandé la configuration au niveau de l'hôte de l'application. Tous les fichiers web.config qui existent dans la racine du site ou ci-dessous ne seront pas lus et leurs gestionnaires <add/> et <remove/> ne seront pas inclus.

2: Vous pouvez lire la configuration spécifique à un site (ou sous-dossier dans un 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); 
} 

Cela permettra également de lire le fichier le site web.config et renvoie une liste de mappage de gestionnaire qui compte pour les directives <add/> et <remove/> spécifiées dans le web.config.

C'est ce que fait l'application IIS7 Manager lorsque vous visualisez et modifiez des mappages de gestionnaires. Il ajoute et supprime des gestionnaires en créant (si nécessaire) un fichier web.config dans le dossier racine du site (ou des sous-dossiers) et en ajoutant les champs requis <add/> et <remove/> à ce niveau.

La couche de compatibilité IIS6 semble fonctionner uniquement au niveau APPHOST applicationHost.config (option 1 ci-dessus), ce qui explique pourquoi vous voyez ces différences.

Est-ce un bug? Je ne suis pas sûr que c'est parce que finalement ADSI n'a jamais été informé en premier lieu. MS devrait également ajouter une nouvelle méthode ou un nouveau drapeau pour vous permettre de spécifier à quel niveau vous voulez vraiment faire ces changements de script, ce qui peut vouloir dire casser et tester les composants ADSI, ce qui peut à son tour introduire des bogues. Le comportement est là pour simuler la modification de l'ancienne métabase IIS6, et applicationHost.config est en effet analogue à la métabase de sorte que vous pourriez argumenter, à tort ou à raison, qu'il fait ce qu'il faut.