[英]ADSI Query against IIS does not agree with IIS Manager, on Vista
Using Vista... 使用Vista ...
I have a script that uses ADSI to set ScriptMaps on an IIS Website. 我有一个脚本,该脚本使用ADSI在IIS网站上设置ScriptMap。 It's javascript, run within cscript.exe, and the code looks something like this: 它是javascript,在cscript.exe中运行,代码看起来像这样:
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();
When I look in the IIS Manager after running the script, I can see the new entry in the list of Handler Mappings. 运行脚本后在IIS管理器中查看时,可以在“处理程序映射”列表中看到新条目。 It has a weird name "AboMapperCustom-43155", which I understand comes from the IIS7 compatibility layer for ADSI. 它有一个奇怪的名称“ AboMapperCustom-43155”,据我了解它来自用于ADSI的IIS7兼容性层。
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. 如果在IIS管理器中删除了这些处理程序映射,然后运行另一个ADSI脚本来查询ScriptMaps属性,则脚本中检索到的ScriptMaps仍会列出刚刚删除的条目。 The results in the ADSI script don't agree with the list of "Handler Mappings" shown in the IIS Manager. ADSI脚本中的结果与IIS管理器中显示的“处理程序映射”列表不一致。
This persists even after a start/stop of IISADMIN and W3SVC. 即使在IISADMIN和W3SVC的启动/停止之后,该问题仍然存在。
Is this expected behavior? 这是预期的行为吗? ADSI is supported as a "compatibility mode" in IIS7. IIS7中将ADSI作为“兼容模式”支持。 Is this an artifact of that? 这是假象吗?
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. 我相信,如果从IIS MAnager中删除了“处理程序映射”,则即使它仍然从ADSI查询返回,它也确实消失了。
Can anyone offer any clarification on this? 谁能对此提供任何澄清?
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: 当您使用ADSI兼容性位添加“脚本映射”(出于参数目的,使用默认网站)时,这会将处理程序映射添加到该站点的applicationHost.config
文件中,位于:
<location path="Default Web Site">
<system.webServer>
<handlers>
<add name="AboMapperCustom-12345678" ... />
</handlers>
</system>
</location>
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: 当您在IIS7管理器中删除处理程序映射时,不是从applicationHost.config
文件和上面显示的部分中删除映射,而是将web.config
文件添加到站点的根目录中,并具有以下内容:
<configuration>
<system.webServer>
<handlers>
<remove name="AboMapperCustom-12345678" />
</handlers>
</system>
</configuration>
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: 使用新的托管Microsoft.Web.Administration
.NET API获取网站的配置时,您可以在不同级别读取配置,例如:
1: Read the configuration at the applicationHost.config
or APPHOST level 1:在applicationHost.config
或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);
}
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. 站点根目录或更低版本中存在的任何web.config
文件都不会被读取,并且它们的处理程序<add/>
和<remove/>
指令将不包括在内。
2: You can read the configuration that is specific to a site (or subfolder in a site): 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);
}
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
. 这还将读取站点web.config
文件,并将返回一个处理程序映射列表,该列表说明了web.config
指定的<add/>
和<remove/>
指令。
This is what the IIS7 Manager application is doing when you are viewing and modifying handler mappings. 当您查看和修改处理程序映射时,这就是IIS7 Manager应用程序正在做的事情。 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. 它是通过在站点根文件夹(或子文件夹)中创建(如果需要) web.config
文件并在此级别添加必需的<add/>
和<remove/>
来添加和删除处理程序的。
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. IIS6兼容性层似乎仅在applicationHost.config
APPHOST级别(上面的选项1)下运行,这就是为什么您会看到这些差异。
Is it a bug? 是虫子吗? I'm not sure it is because ultimately ADSI was never web.config
aware in the first place. 我不确定这是因为最终ADSI从来没有意识到web.config
。 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. MS还必须添加新的方法或标志,以允许您指定真正要进行“脚本映射”更改的级别,这可能意味着破坏和测试ADSI组件,从而可能引入错误。 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. 该行为可以模拟修改旧的IIS6元数据库,而applicationHost.config
实际上类似于该元数据库,因此您可以说是对是非。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.