问题
I'm writing some code to permit users to remotely manage IIS7. Under the bonnet this adds authorisation rules to c:\windows\system32\inetsrv\config\administration.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:\Windows\system32\inetsrv\config\administration.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.
回答1:
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.
来源:https://stackoverflow.com/questions/3735540/why-does-using-iis7-5s-microsoft-web-management-dll-only-work-in-a-64bit-proces