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

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.

---

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.