Set location of app.config file for interop com ob

Question

I am creating a windows com object in VS2010 and VB.net (interop)

This com object should be able to work with any NON managed code application such as word, Excel or in this case Access.

The creating of the com object and using regasm etc. works fine. No problem.

However the INSTANT I create a com object that requires connection strings or anything else from the app.config file then it fails. In this case it happens to be a web service and the common "endpoint" or app.config file could not be found error occurs. (if it was just a connection string I would simply read in this value – but the config file quite messy due to a web service definition).

There is some suggesting that placing the .dll's and app.config in the SAME directory as the office program such as excel then renaming the config file as Excel.exe.config should work.

This does not seem to be working for me.

Is there a means to have the vb.net class (.dll) that is now a com object to know to load + use a config file for the .dll and not some main application file?

Note that in this case I do NOT have a main application config file since I am launching a non managed application like word or Excel and attempting to use my class object.

In vb.net obviously I can copy the config file stuff from the .dll to the main application config and we are off to the races. I don't have a managed "main" file as noted.

So how do I get the class.dll file to load up the class.dll.config file when an instance of the object is created in non managed code?

Answer 1

Using application settings in a class library is in general a poor practice, .NET only supports them for EXE projects. It is off the chart in the case of a [ComVisible] DLL, you have completely no control over which EXE uses your code.

It's not like it doesn't work, putting a copy of foo.exe.config in the foo.exe client directory works just fine. Trouble starts when you are not the only one that looked for this solution. Now installers start to overwrite each other's .config files, your customer loses big time when add-ins fail undiagnosably.

There's just one solution to this problem: don't use settings. Plenty of other ways to provide config to a class library. An .xml file in a well known location works just fine as well.