WCF client from VBA

Question

In .NET, I have developed a client library for my WCF service.

I have registered the assembly for COM interop so that I can make calls to the library from VBA.

However, since the executable using the library is not built in the .NET setting, library functions are unable to find the config file that defines the service bindings ('app.config' in the visual studio project)

Is there any way for me to specify the path where the config file should be expected to sit?

Thanks

Answer 1

Even if you have a "native" Win32 app, you can still put a config file called MyApp.exe.config right in the same directory as the app, and the .NET parts should be able to find and interpret that config file.

Your VB app won't know anything about that config file and won't do anything with it - but your .NET client library will find and use it.

I've used this technique to integrate C# code components into a native C++/Win32 app - works like a charm for me.

It requires a fully compiled, native EXE file for this method to work - not sure if your VBA project offers that, though...

---

If you can't live with this option, the only other option, really, is to programmatically define and load the config file. You cannot define / specify the location of the config file - but you can load a specific config file in code and use it (almost the same as the default config file).

Check out the ConfigurationManager.OpenMappedExeConfiguration method:

// you need to define a ExeConfigurationFileMap that defines what file to use
ExeConfigurationFileMap exeMap = new ExeConfigurationFileMap();
exeMap.ExeConfigFilename = @"C:\Application\Default.config";

// then, you need to load that file with the ConfigurationManager
Configuration exeConfig = 
  ConfigurationManager.OpenMappedExeConfiguration(exeMap, ConfigurationUserLevel.None);

// now you can access parts of that config
string someValue = exeConfig.AppSettings.Settings["SomeValue"].Value;
string connStr = exeConfig.ConnectionStrings.ConnectionStrings["Default"].ConnectionString;

Answer 2

The right way to do this is not to directly COM-activate the WCF client, but to write a custom shim that will spin up a new AppDomain, create the client there, and return the IDispatch for the client to the COM caller. Once you're creating your own AppDomain, you can have it load its config file from any location you like- it's up to your hosting shim to tell it where. With the AppDomainManager introduced in 2.0, you don't even have to write an unmanaged shim- you can write a tiny 100% managed ComVisible shim that loads your WCF client up into its own domain. I've used this technique for a number of large projects that had to run inside Excel (same problem you had- bad form to drop an Excel.exe.config into a shared location), and it works great.