I'm writing applications that interoperate with a third-party application.  This application exposes an API to developers via methods in a DLL.  Some time ago, the vendor of this app started integrating their own .NET components into their program, and when they did, they decided that their components should use the ConfigurationManager to get settings at runtime.
What this means:  their program, foo.exe, calls fooengine.dll, and it reads its settings from foo.exe.config.  My program, bar.exe, also calls fooengine.dll, and it reads its settings from bar.exe.config.
Well, that's just plain wrong. But how do I fix it?
The simple workaround is to replicate foo.exe.config's settings in bar.exe.config.  That'll work, but it's stupid.  It means that from an administrative standpoint, a given setting has to be maintained in N different files.  That's going to fail sooner or later.
I tried putting a configSource attribute on the appSettings section in my config file.  (As it happens, I'm using the applicationSettings section for my settings, and they're using the appSettings section for theirs, so I can live with simply getting that section from a different file.)  But the ConfigurationManager doesn't like that:  it wants the path in configSource to be not only relative to but below my program's directory.
I can physically read their settings file into an XmlDocument and then set them myself.  But now I'm tightly coupling my code to their implementation; if they put out a new release that moves the settings to the applicationSettings section (which is where they should be now that it's 2009), my code will break.
Is there another way out of this?
 
     
    