ADSI Navraag teen IIS nie saamstem met IIS Manager, op Vista

Question

Met Behulp Van Vista...

Ek het'n script wat gebruik ADSI te stel ScriptMaps op'n IIS Webwerf.Dit is javascript, hardloop binne cscript.exe en die kode lyk iets soos hierdie:

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

Wanneer ek kyk in die IIS Manager na die loop van die script, ek kan sien die nuwe inskrywing in die lys van die Hanteerder Afbeeldings.Dit het'n vreemde naam "AboMapperCustom-43155", wat ek verstaan kom van die IIS7 verenigbaarheid laag vir ADSI.

Indien, in IIS Manager, ek dan verwyder die Hanteerder Afbeeldings, dan loop nog ADSI script om navraag die ScriptMaps eiendom, die url besoek op ScriptMaps in die skrif nog lys van die inskrywing wat was net verwyder.Die resultate in die ADSI script stem nie saam met die lys van "Hanteerder Afbeeldings" getoon in die IIS Manager.

Hierdie voortduur selfs nadat'n begin/stop van IISADMIN en W3SVC.

Is hierdie verwagte gedrag?ADSI word ondersteun as'n "compatibility mode" in IIS7.Is dit'n juweel van wat?

Ek glo dat as die Hanteerder Kartering is verwyder van IIS MAnager, dan is dit is werklik gegaan het, selfs al is dit nog steeds kry teruggekeer van'n ADSI navraag.

Kan iemand bied enige verduideliking op hierdie?

Answer 1

Wanneer jy voeg'n " scriptmap met die ADSI verenigbaarheid stukkies (met behulp van die Standaard Web Site vir die wille van die argument), dit voeg'n hanteerder kartering van die applicationHost.config lêer vir die webwerf by:

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

Wanneer jy verwyder die hanteerder kartering in die IIS7 bestuurder, in plaas van die verwydering van die kartering van die applicationHost.config lêer en die artikel hierbo getoon, 'n web.config lêer is bygevoeg tot die wortel van die werf met die volgende:

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

Wanneer kry die opset vir'n webwerf met behulp van die nuwe bestuur Microsoft.Web.Administration .NETTO API jy kan lees die config op verskillende vlakke, byvoorbeeld:

1:Lees die opset by die applicationHost.config of APPHOST vlak

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

In die voorbeeld hierbo, selfs al het jy verwyder die kartering, dit sal nog steeds gelys word wanneer iterating die hanteerder kartering versameling.Hierdie, want jy het gevra vir die opset by die aansoek gasheer vlak.Enige web.config lêers wat bestaan in die webwerf wortel of hieronder sal nie gelees word en hul hanteerder <add/> en <remove/> riglyne sal nie ingesluit word.

2:Jy kan lees die opset wat is spesifiek vir'n webwerf (of'n subgids in'n webwerf):

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

Dit sal ook lees die site web.config lêer en sal terugkeer'n hanteerder kartering lys wat verantwoordelik is vir die <add/> en <remove/> die riglyne wat in die web.config.

Dit is wat die IIS7 Bestuurder aansoek doen wanneer jy lees en die wysiging van hanteerder afbeeldings.Dit is toe te voeg en die verwydering van hanteerders deur die skep van (indien nodig) 'n web.config lêer in die webwerf wortel gids (of subgidse) en die toevoeging van die vereiste <add/> en <remove/> op hierdie vlak.

Die IIS6 verenigbaarheid laag blyk te werk net op die applicationHost.config APPHOST vlak (opsie 1 hierbo) wat is die rede waarom jy sien hierdie verskille.

Is dit'n fout?Ek is nie seker wat dit is nie, want uiteindelik ADSI was nog nooit web.config bewus te wees in die eerste plek.Ook MS sou hê om by te voeg'n nuwe metode of vlag te laat om jou te spesifiseer op watter vlak jy regtig wil om te maak hierdie "scriptmap' veranderinge en dit kan beteken breek en die toets van die ADSI komponente, wat op sy beurt kan stel foute.Die gedrag is daar om te simuleer die wysiging van die ou IIS6 metabase, en applicationHost.config is in effek analoog daaraan om die metabase so jy kan argumenteer, reg of verkeerd, dit is die regte ding doen.