针对IIS的ADSI查询与Vista上的IIS管理器不一致 [英] ADSI Query against IIS does not agree with IIS Manager, on Vista

问题描述

使用Vista ...

Using Vista...

我有一个脚本，它使用ADSI在IIS网站上设置ScriptMaps。这是javascript，在cscript.exe中运行，代码如下所示：

I have a script that uses ADSI to set ScriptMaps on an IIS Website. It's javascript, run within cscript.exe, and the code looks something like this:

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

当我在运行脚本后查看IIS管理器时，我可以在列表中看到新条目处理程序映射。它有一个奇怪的名字AboMapperCustom-43155，据我所知，它来自ADSI的IIS7兼容层。

When I look in the IIS Manager after running the script, I can see the new entry in the list of Handler Mappings. It has a weird name "AboMapperCustom-43155", which I understand comes from the IIS7 compatibility layer for ADSI.

如果在IIS管理器中我删除了那些处理程序映射，然后运行另一个ADSI脚本来查询ScriptMaps属性，则脚本中检索到的ScriptMaps仍会列出该条目刚被删除。 ADSI脚本中的结果与IIS管理器中显示的处理程序映射列表不一致。

If, in IIS Manager, I then remove those Handler Mappings, then run another ADSI script to query the ScriptMaps property, the retrieved ScriptMaps in the script still lists the entry that was just removed. The results in the ADSI script don't agree with the list of "Handler Mappings" shown in the IIS Manager.

即使在IISADMIN和W3SVC启动/停止后，这仍然存在。

This persists even after a start/stop of IISADMIN and W3SVC.

这是预期的行为吗？在IIS7中支持ADSI作为兼容模式。这是一件神器吗？

Is this expected behavior? ADSI is supported as a "compatibility mode" in IIS7. Is this an artifact of that?

我相信如果从IIS MAnager中删除Handler Mapping，那么它确实已经消失了，即使它仍然从ADSI查询返回。

I believe that if the Handler Mapping is removed from IIS MAnager, then it is really gone, even though it still gets returned from an ADSI query.

有人可以对此作出任何澄清吗？

Can anyone offer any clarification on this?

推荐答案

当您使用ADSI兼容性位（为了参数使用默认网站）添加scriptmap时，这会将处理程序映射添加到 applicationHost.config 该网站的文件：

When you add a 'scriptmap' using the ADSI compatibility bits (using the Default Web Site for the sake of argument), this adds a handler mapping to the applicationHost.config file for the site at:

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

当您删除IIS7管理器中的处理程序映射时，而不是从<$ c中删除映射$ c> applicationHost.config 文件和上面显示的部分，一个 web.config 文件被添加到网站的根目录，其中包含以下内容：

When you delete the handler mapping in the IIS7 manager, instead of removing the mapping from the applicationHost.config file and the section shown above, a web.config file is added to the root of the site with the following:

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

使用新的托管 Microsoft.Web获取网站配置时。管理 .NET API您可以在不同级别读取配置，例如：

When getting the configuration for a website using the new managed Microsoft.Web.Administration .NET API you can read the config at different levels, for example:

1：读取<$的配置c $ c> applicationHost.config 或APPHOST级别

1: Read the configuration at the applicationHost.config or APPHOST level

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

在上面的示例中，即使您已删除映射，它也会仍然在迭代处理程序映射集合时列出。这是因为您已经要求在应用程序主机级别进行配置。网站根目录或更低版本中存在的任何 web.config 文件将不会被读取，其处理程序< add /> 和< remove /> 指令不会包含在内。

In the example above, even though you've removed the mapping, it will still be listed when iterating the handler mapping collection. This because you've asked for the configuration at the application host level. Any web.config files that exist in the site root or below will not be read and their handler <add/> and <remove/> directives will not be included.

2：你可以读取特定于站点（或站点中的子文件夹）的配置：

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

这也将读取网站 web.config file并将返回一个处理程序映射列表，该列表包含< add /> 和< remove /> web.config 中指定的指令。

This will also read the site web.config file and will return a handler mapping list that accounts for the <add/> and <remove/> directives specified in the web.config.

这是IIS7 Manager应用程序的内容在查看和修改处理程序映射时正在执行。它通过在站点根文件夹（或子文件夹）中创建（如果需要） web.config 文件并添加必需的<来添加和删除处理程序;在此级别添加/> 和< remove /> 。

This is what the IIS7 Manager application is doing when you are viewing and modifying handler mappings. It is adding and removing handlers by creating (if necessary) a web.config file in the site root folder (or subfolders) and adding the requisite <add/> and <remove/> at this level.

IIS6兼容层似乎仅在 applicationHost.config APPHOST级别（上面的选项1）中运行，这就是您看到这些差异的原因。

The IIS6 compatibility layer appears to operate solely at the applicationHost.config APPHOST level (option 1 above) which is why you're seeing these differences.

这是一个错误吗？我不确定是不是因为最初ADSI从来都不是 web.config 。此外，MS必须添加一个新方法或标志，以允许您指定您真正想要在哪个级别进行这些脚本映射更改，这可能意味着破坏和测试ADSI组件，这反过来可能会引入错误。行为是模拟修改旧的IIS6元数据库， applicationHost.config 实际上与元数据库类似，所以你可以辩解，无论是对还是错，它正在做正确的事情。

Is it a bug? I'm not sure it is because ultimately ADSI was never web.config aware in the first place. Also MS would have to add a new method or flag to allow you to specify at which level you really want to make these 'scriptmap' changes and that may mean breaking and testing the ADSI components, which in turn may introduce bugs. The behaviour is there to simulate modifying the old IIS6 metabase, and applicationHost.config is in effect analagous to the metabase so you could argue, rightly or wrongly, it's doing the right thing.

这篇关于针对IIS的ADSI查询与Vista上的IIS管理器不一致的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！