When using interop there is no .config xml file in which to update the sqlServerCatalogNameOverwrites. On my project we use vbscript (ASP) and IIS. Our ASP app calls into our LLBL Generated library.

The first thing the ASP app does is pass along a new connection string. The LLBL library sets ActualConnectionString to be the passed in connection string. This allows us to use different catalog names in LLBL 1.0, but no longer works in LLBL 2.0.

I am aware of the fix:

<?xml version="1.0"?> <configuration> <configSections> <section name="sqlServerCatalogNameOverwrites" type="System.Configuration.NameValueFileSectionHandler, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> </configSections> <sqlServerCatalogNameOverwrites> <add key="XXXXXXXX" value=""/> </sqlServerCatalogNameOverwrites> </configuration>

But I have nowhere to put this fix. I don't have a web.config file, I don't have an exe.config file. What are my optionsl

Then, SelfServicing isn't for you here . Instead you should use Adapter : http://llblgen.com/TinyForum/Messages.aspx?ThreadID=12063

That isn't strictly correct, you can always use a config file.

If using VBScript the file maybe be wscript.exe.config or cscript.exe.config or for IIS it could be inetinfo.exe.config , dllhost.exe.config or w3wp.exe.config depending on the process hosting your application.

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.

Thank you very much for the valuable information. I'm sure it would very useful for others going into the same path.