October 30, 2009

Weird issue with accessing Web.config section on 64-bit Windows Server 2008 (IIS 7)

I was returning to this issue for several times starting from this weekend. Initially it was looking really simple: by some reason our ASP.NET sample (as well as ASP.NET MVC and Astoria samples) were simply not working on 64-bit Windows Server 2008 with IIS 7, although everything was fine on Vista. "Not working" means they were showing an error page on attempt to open any of these web application:
  • InvalidOperationException: Section 'Xtensive.Storage' is not found in application configuration file.
It was thrown by our own DomainConfiguration.Load(...) method - the following code there was throwing an exception:

var section = (ConfigurationSection) ConfigurationManager.GetSection(sectionName);
if (section==null) 
  throw new InvalidOperationException(string.Format(
    Strings.ExSectionIsNotFoundInApplicationConfigurationFile, sectionName));

So this was looking pretty simple: by some reason IIS does not see our section and thus returns null from GetSection method.

Certainly, initially I suspected there is something wrong with Web.config file. So I studied everything related to new configuration features that appeared in IIS 7. Nothing helped. I tried to rename this section, wrap it into group and so on. No results.

My Web.config was looking like that:

  <section name="Xtensive.Storage" type="Xtensive.Storage.Configuration.Elements.ConfigurationSection, Xtensive.Storage, Version=, Culture=neutral, PublicKeyToken=93a6c53d77a5296c"/>
    <domain name="mssql" upgradeMode="Recreate" connectionUrl="sqlserver://localhost/DO40-Tests"/>

Btw, what was really strange is that actually IIS was seeing this section: when I tried to modify e.g. its name in <section name="..." .../> tag without modifying its tag names below, IIS was showing appropriate (different) error message. Moreover, running the same application under Visual Studio .NET (i.e. under integrated Cassini) on the same PC was leading to no errors!

Finally I found a workaround:

ConfigurationSection section;
if (HttpContext.Current!=null) {
  // See http://code.google.com/p/dataobjectsdotnet/issues/detail?id=459
  // (workaround for IIS 7 @ 64 bit Windows Server 2008)
  var config = WebConfigurationManager.OpenWebConfiguration("~");
  section = (ConfigurationSection) config.GetSection(sectionName);
  section = (ConfigurationSection) ConfigurationManager.GetSection(sectionName);
if (section==null) 
  throw new InvalidOperationException(string.Format(
    Strings.ExSectionIsNotFoundInApplicationConfigurationFile, sectionName));

Can you imagine this?
  • Why default ConfigurationManager.GetSection does not work the same way in this case? Worse, why it does not fail at all on Vista, but fails only on 64-bit Windows Server 2008?
  • Why, at least, it does not fail properly, with error like "you're using wrong method"? It behaves as if it deals with wrong .config file there.
I spent a lot of time on this mainly because I didn't expect there can be something related to API calls at all. All the problems I faced before on this OS were much more obvious. But in this case I was thinking there is really something wrong with Web.config content until I understood there can be an issue related to GetSection method we call. This was really not obvious for me, since the same code was working properly everywhere else.

Moreover, I couldn't find anything related to this issue on the web. I tried this workaround not because I found it somewhere, but because I found this part of API (I mean OpenWebConfiguration), and, btw, tried few other ways of its usage until it started to work, so possibly GetSection does not work properly not because it is buggy, but because WebConfigurationManager is buggy. Further I discovered there are some known bugs - e.g. I voted for this one. But as I said, I could find nothing exact.

So that's why I wrote this post. The issue seems important, since it is related to generally any web application using custom Web.config section. Of course, if it has any chance to run on 64-bit Windows.

P.S. This is the last bug related to running DataObjects.Net on 64-bit Windows I planned to fix till officially confirming "it works on 64-bit Windows" :)