I'd like to bring up a couple more options that I've discovered while researching.
It would be too much work to switch from SelfServicing to Adapter at this point. We've been developing around SelfServicing for years.
Also, thanks for pointing out the dllhost.exe.config idea. I wasn't aware of this. Nevertheless, unfortunately it's not really an option for us. Because it's a shared file, our sys admin won't allow us to update it.
So, Option 3 is to load your class library into its own AppDomain. In other words, I ended up building 3 DLLs.
MyInterop.dll (this is the dll that is registered for COM interop containing the classes that are called by vbscript. It directly references MyLLBLInterface.dll)
MyLLBLInterface.dll (this is a lightweight dll that contains some interfacing methods and business logic. It directly references MyLLBLProject.dll)
MyLLBLProject.dll (this is my LLBL generated Self Servicing DLL). It also has a matching a config file: MyLLBLProject.dll.config)
Inside of my interop class, I create a new appdomain. Using AppDomainSetup I'm able to specify the configuration file for that AppDomain. I specify "MyLLBLProject.dll.config". Then using remoting I load MyLLBLInterface.dll into the new AppDomain and I utilize it.
At this point LLBL reads in MyLLBLProject.dll.config, sees that catalog name overwriting is allowed, and I'm able to change the ActualConnectionString with different catalog names.
Option 4 is to build a Serviced COM+ component instead of a COM component. By making my interop library a Serviced COM+ component, I can specify the Application Root Directory. If the following files exist in the root directory, then COM+ will load the config file when it loads the library:
Application.Manifest
Application.Config
The manifest file contains only this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"></assembly>
The Application.Config file contains the standard sqlServerCatalogNameOverwrites information.