ComVisible .NET assembly and app.config

Question

• I have .NET assembly with some classes marked as ComVisible
• This assembly is registered with regasm /codebase "assembly_path"
• I have app.config name (actually - MyAssemblyName.dll.config) which are in assembly's folder
• I access to appSettings in my assembly through ConfigurationManager.AppSettings["SettingName"]
• I have VBScript file which creates my COM object through CreateObject("...")
• When object is created (from VBScript), ConfigurationManager.AppSettings["SettingName"] returns null. It looks like assembly doesn't see config file.

What should I to do to make it workable?

Answer 1

One possible way, as Komyg said, is to read config file directly, instead of using ConfigurationManager's embedded behavior. For those, who will have the same problem: instead of

ConfigurationManager.AppSettings["SettingName"]

you can use:

var _setting = ConfigurationManager.AppSettings["SettingName"];
// If we didn't find setting, try to load it from current dll's config file
if (string.IsNullOrEmpty(_setting))
{
    var filename = Assembly.GetExecutingAssembly().Location;
    var configuration = ConfigurationManager.OpenExeConfiguration(filename);
    if (configuration != null)
        _setting = configuration.AppSettings.Settings["SettingName"].Value;
}

This way you will always use read settings from file YourAssemblyName.dll.config which lays in your assembly's folder. It will allow you to use also another features for app.config (like appSetting's file attribute), which will no be available if you will use XPath or something like this.

Answer 2

I had the same problem. An explorer shell extension (Com visible, registered via regasm /codebase) which required an app.config file, could not find nor the connection strings neither the settings.

What I did:

string assemblyLoc          = GetType().Assembly.Location;
string configName           = assemblyLoc + ".config";
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", configName);

That assumes, that the config file is stored in the same directory as the assembly.

Answer 3

I used sputnik's answer, worked great in one IIS test environment, but not another. It turns out that after you set APP_CONFIG_FILE property, you may need to use reflection to touch the ConfigurationManager class to make the change stick. I used this function after setting the APP_CONFIG_FILE property:

    private static void ResetConfiguration()
    {
        typeof(ConfigurationManager)
            .GetField("s_initState", BindingFlags.NonPublic | BindingFlags.Static)
            .SetValue(null, 0);

        typeof(ConfigurationManager)
            .GetField("s_configSystem", BindingFlags.NonPublic | BindingFlags.Static)
            .SetValue(null, null);

        typeof(ConfigurationManager)
            .Assembly.GetTypes()
            .Where(x => x.FullName == "System.Configuration.ClientConfigPaths")
            .First()
            .GetField("s_current", BindingFlags.NonPublic | BindingFlags.Static)
            .SetValue(null, null);
    }

Beyond this, it's probably a good idea to first save off the property and then restore it when you are done:

string oldConfigName = AppDomain.CurrentDomain.GetData("APP_CONFIG_FILE").ToString();
        //do custom stuff in here
        AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", oldConfigName); //re-point to the original configuration.
        ResetConfiguration();

Answer 4

Is everything on the same folder (your dll, vb script, config file, etc)? If not, you could try to add the full path to the config file in the PATH evironment variable...

Also if you are running this VB Script inside Internet Explorer you might have some security issues (normally the IE doesn't allow you access to the hard drive). In this case you can try to put the config file in your desktop, I don't know why but that seems to be the default path when it runs an ActiveX program, so it might also be true for an VB Script.

Finally you could add some debugging to your dll, something like creating a simple text file and looking for it afterwards, this way you can see where does your system is actually running your library.