Le query ADSI su IIS non sono d'accordo con IIS Manager, su Vista

Question

Uso di Vista ...

Ho uno script che utilizza ADSI per impostare ScriptMaps su un sito Web IIS. È javascript, eseguito all'interno di cscript.exe e il codice è simile al seguente:

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 guardo Gestione IIS dopo aver eseguito lo script, posso vedere la nuova voce nell'elenco dei mapping dei gestori. Ha un nome strano & Quot; AboMapperCustom-43155 & Quot ;, che capisco deriva dal livello di compatibilità IIS7 per ADSI.

Se, in Gestione IIS, rimuovo quei mapping dei gestori, quindi eseguo un altro script ADSI per interrogare la proprietà ScriptMaps, gli ScriptMaps recuperati nello script continuano a elencare la voce che è stata appena rimossa. I risultati nello script ADSI non coincidono con l'elenco di & Quot; Handler Mappings & Quot; mostrato in Gestione IIS.

Ciò persiste anche dopo un avvio / arresto di IISADMIN e W3SVC.

Questo comportamento è previsto? ADSI è supportato come & Quot; modalità di compatibilità & Quot; in IIS7. È un artefatto di questo?

Credo che se la mappatura del gestore viene rimossa da IIS MAnager, allora è davvero sparita, anche se viene comunque restituita da una query ADSI.

Qualcuno può offrire qualche chiarimento al riguardo?

Answer 1

Quando si aggiunge un 'scriptmap' usando i bit di compatibilità ADSI (usando il sito Web predefinito per ragioni di argomento), questo aggiunge un mapping dei gestori al file applicationHost.config per il sito in:

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

Quando si elimina la mappatura del gestore nel gestore IIS7, invece di rimuovere la mappatura dal file web.config e dalla sezione mostrata sopra, un file Microsoft.Web.Administration viene aggiunto alla radice del sito con il seguente:

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

Quando si ottiene la configurazione per un sito Web utilizzando la nuova API gestita <add/> .NET, è possibile leggere la configurazione a diversi livelli, ad esempio:

1: leggi la configurazione a <remove/> o al livello 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);
}

Nell'esempio sopra, anche se hai rimosso la mappatura, questa verrà comunque elencata durante l'iterazione della raccolta di mappature del gestore. Questo perché hai richiesto la configurazione a livello di host dell'applicazione. Eventuali <=> file presenti nella radice del sito o in basso non verranno letti e le relative direttive <=> e <=> non verranno incluse.

2: puoi leggere la configurazione specifica di un sito (o sottocartella in un sito):

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

Questo leggerà anche il file <=> del sito e restituirà un elenco di mappatura del gestore che tiene conto delle direttive <=> e <=> specificate nel <=>.

Questo è ciò che l'applicazione IIS7 Manager sta eseguendo durante la visualizzazione e la modifica dei mapping dei gestori. Aggiunge e rimuove i gestori creando (se necessario) un <=> file nella cartella principale del sito (o sottocartelle) e aggiungendo i requisiti <=> e <=> a questo livello.

Il livello di compatibilità IIS6 sembra funzionare esclusivamente al livello <=> APPHOST (opzione 1 sopra) ed è per questo che stai vedendo queste differenze.

È un bug? Non sono sicuro che alla fine ADSI non sia mai stato <=> a conoscenza. Inoltre, MS dovrebbe aggiungere un nuovo metodo o flag per consentire all'utente di specificare a quale livello si desidera realmente apportare queste modifiche alla "sceneggiatura" e ciò può significare interrompere e testare i componenti ADSI, che a loro volta possono introdurre bug. Il comportamento è lì per simulare la modifica della vecchia metabase IIS6 e <=> è in effetti analogo alla metabase in modo da poter discutere, nel modo giusto o sbagliato, che sta facendo la cosa giusta.