为什么使用 IIS7.5 的 Microsoft.Web.Management.dll 只能在 64 位进程中使用? [英] Why does using IIS7.5's Microsoft.Web.Management.dll only work in a 64bit process?
问题描述
我正在编写一些代码来允许用户远程管理 IIS7.在引擎盖下,这将授权规则添加到 c:windowssystem32inetsrvconfigadministration.config
下的以下配置部分:
system.webServer/management/authorization/authorizationRules
我正在使用 Microsoft.Web.Administration
程序集和命名空间,代码类似于以下内容:
使用 Microsoft.Web.Management.Server;...ManagementAuthorization.Grant("MySiteUser, "My Web Site", false);
此代码在 32 位进程中运行时抛出异常,如果构建为 64 位则运行正常:
<前>System.Runtime.InteropServices.COMException 未处理消息=文件名:\?C:Windowssystem32inetsrvconfigadministration.config错误:无法读取配置节system.webServer/management/authorization",因为它缺少节声明`但是,使用 Microsoft.Web.Administration
程序集和命名空间执行的其他服务器管理任务在 32 位进程中也能正常工作,例如:
使用 Microsoft.Web.Administration;....int iisNumber = 60000;使用 (ServerManager serverManager = new ServerManager()){var site = serverManager.Sites.Where(s => s.Id == iisNumber).SingleOrDefault();如果(网站!= null){站点停止();}}
这两个程序集都出现在 GAC 中并且是纯 MSIL(即使有一个 COM 互操作层可以直接与 IIS7 的底层管理机制对话).
底层配置文件 applicationHost.config
和 administration.config
仅对 64 位编辑器(例如 notepad.exe 或 NotePad2.exe)可见,我怀疑这这就是为什么我的代码无法通过 Microsoft.Web.Management
administration.config
为什么 Microsoft.Web.Administration
允许我在 32 位进程中读取/修改 applicationHost.config
而 Microsoft.Web.Management
code> 只能读取/修改 administration.config
如果在 64 位进程中运行?
我无法将我的项目重新编译为面向 x64,因为依赖于我们没有源的 32 位 COM 库.我可以构建一个解决方法,其中涉及调用进程外 64 位 WCF 应用程序(或一些类似的东西),但不想这样做.
经过一番挖掘,看起来这是一个错误:
这个论坛帖子和 Carlos Aguilar 的帖子解释了一切:
<块引用>http://forums.iis.net/p/1157779/1956471.aspx
现在我明白了这个问题,什么是发生的事情是卡西尼是 32 位的过程和结合一个我们配置中的错误让我们尝试加载重定向"syswow(而不是 system32)这是我们找不到的原因管理配置文件运行在 64位过程缓解了问题因为没有魔法"重定向然后我们转到正确的文件夹.
任何 32 位进程都会遇到这种麻烦.
I'm writing some code to permit users to remotely manage IIS7. Under the bonnet this adds authorisation rules to c:windowssystem32inetsrvconfigadministration.config
under the following config section:
system.webServer/management/authorization/authorizationRules
I'm using the Microsoft.Web.Administration
assembly and namespace with code similar to the following:
using Microsoft.Web.Management.Server;
...
ManagementAuthorization.Grant("MySiteUser, "My Web Site", false);
This code throws an exception if run in a 32 bit process, if built as 64 bit it runs fine:
System.Runtime.InteropServices.COMException was unhandled Message=Filename: \?C:Windowssystem32inetsrvconfigadministration.config Error: The configuration section 'system.webServer/management/authorization' cannot be read because it is missing a section declaration`
However other server management tasks performed using the Microsoft.Web.Administration
assembly and namespace work just fine in a 32 bit process, for example:
using Microsoft.Web.Administration;
....
int iisNumber = 60000;
using (ServerManager serverManager = new ServerManager())
{
var site = serverManager.Sites.Where(s => s.Id == iisNumber).SingleOrDefault();
if (site != null)
{
site.Stop();
}
}
Both these assemblies appear in the GAC and are pure MSIL (even though there is a COM interop layer to talk directly to IIS7's underlying management mechanisms).
The underlying configuration files applicationHost.config
and administration.config
are only visible to 64 bit editors (e.g. notepad.exe or NotePad2.exe) and I suspect that this is why my code can't modify administration.config
via the Microsoft.Web.Management
Why does the Microsoft.Web.Administration
allow me to read/modify applicationHost.config
in a 32 bit process but Microsoft.Web.Management
can only read/modify administration.config
if run in a 64 bit process?
I am unable to recompile my project to target x64 because there is a dependency on a 32bit COM library that we don't have source for. I can build a work around which would involve making calls to an out of process 64 bit WCF app (or some such similar thing) but would prefer not to.
After some digging it looks like this is a bug:
This forum thread and a post by Carlos Aguilar explains all:
http://forums.iis.net/p/1157779/1956471.aspx
Now I understand the issue, what is happening is that Cassini is a 32 bit process and that in conjunction of a bug in our configuration makes us try to load the "redirected" syswow (instead of system32) which is the reason why we cannot find administration.config. Running in 64 bit process alleviates the problem cause there is no "magic" redirection and we go to the right folder.
Any 32 bit process is going to encounter this roadhump.
这篇关于为什么使用 IIS7.5 的 Microsoft.Web.Management.dll 只能在 64 位进程中使用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!