views:

172

answers:

1

I had a situation on a dev server where all the ASP.Net applications we have started to fail at the same time.

After some investigation we found that calls the app settings, in 1.1 apps, and the connection strings collection in 2.0 apps all failed. The config files had the values, but the code was returning null.

After some head scratching and searching I thought that perhaps the root web.config was being used and the sites one ignored. To test out this theory I added the app settings required for one of the sites to the root web.config. This allowed the site to work.

After I had proven that I deleted the settings from the root web.config and reset IIS. But now all of the sites are working again, even ones that do not rely on the settings I had previously added to the root web.config.

Can anyone explain why this might of happened? As far as I can tell touching the root web.config caused it all to work again, but I have no idea why or what caused the problem in the first place.

EDIT: This is on IIS 6.0 on Windows Server 2003 SP2

+1  A: 

What could have happened depends on which version of IIS you were running. Root web.config is always read in ASP.NET, but web.config files in IIS subdirectories are only read when the subdirectory is defined as a web application in IIS. If you create a web.config in an IIS subdirectory that is not an application directory it will not be read.

I have never seen what you describe happen, but I imagine if the state of the running IIS process became corrupted and failed to recognize app dirs, the config system could miss the files in the subdirs.

I think this would be more likely to occur on IIS 5.x, such as Win2000 or XP than on Server 2008 or Windows 7.

This is IIS 6.0, and I am pretty sure the sites where all configured as applications. They did work up till now anyway. The IIS worker process did die a few times, but as far as I can tell it is because of apps not handling the config values not being there.
Glenn Condron
IIS 6.0 on Server 2003 still had a binary metabase, which holds the definitions of what is an application directory, and ASP.NET config was basically an add-on on top of the existing IIS binary config. Although you can edit the 6.0 metabase in XML, it is stored in binary. My guess is that the binary version of the metabase in memory was corrupted while the server was running, and changing the root config caused the tree of dependent file watchers that is the ASP.NET to be restarted. In IIS 7.0 the web server and ASP.NET share text based config, so this is much less likely to happen.
That sounds like it might be what happened. Corruption of the metabase hadn't occured to me.
Glenn Condron