Assemblies, Web.config and App.Config -- Building failover logic

Question

How do I engineer failover logic properly if an Assembly (.dll) cannot find a web.config file?

Background: I've got our website code nicely modularized into two different .dlls. For simplicity's sake, let's call them:

• website.dll
• commonengine.dll

The website code and .aspx / .ascx files calls upon the commonengine library for all data layer stuff. For connection strings, the commonengine in turn looks not to the app.config but to the website's web.config file (that's my own preference -- I prefer to have our production constants all in one place). The website code occasionally (very rarely) needs to access stuff in that web.config file. All good so far (even though not entirely pure).

Here's the trouble. I've written a third module. It's a Windows Service (specifically, it's a POP3 checker/processor -- processing mailbox requests and using the commonengine.dll for some data layer stuff).

The problem is the Windows Service calls upon the commonengine.dll, and the commonengine.dll cannot find web.config anywhere because, after all, it's a Windows service (.exe) and doesn't live in a website directory.

What's the proper test/logic here to use app.config when a web.config file cannot be found? Can any ASP.NET configuration gurus give me some guidance here? Thanks much if so.

Answer 1

I never read Web.config explicitly, I use the System.Configuration class to read it (e.g. System.Configuration.ConfigurationStrings["conn name"]). It will automatically go to Web.config in an ASP.NET app and app.config in an EXE.

Of course, you still have to take into account the fact that the config section might be missing.

Answer 2

Thanks much. (I too never read web.config explicitly, and use the System.Configuration.ConfigurationStrings methods, but I didn't know it automatically fails over from web.config to app.config.) Very helpful, thank you!

Of course, you still have to take into account the fact that the config section might be missing.

Great point -- it's easy for me to add this to both. I don't love the idea of some of the same (4-6) constants floating around in both files, but it's not too big a burden to keep updated.