C# DLL config file

Question

Im trying to add an app.config file to my DLL, but all attempts have failed.

According to MusicGenesis in \'Putting configuration information in a DLL\' this should

Answer 1

you are correct, you can read the config file of a dll. I struggled with this for a day until i found out that the my config file was the issue. See my code below. it was able to run.

        ExeConfigurationFileMap map = new ExeConfigurationFileMap();
        map.ExeConfigFilename = Assembly.GetExecutingAssembly().Location + ".config";
        Configuration libConfig = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
        AppSettingsSection section = (libConfig.GetSection("appSettings") as AppSettingsSection);
        Console.WriteLine(section.Settings["dnd_shortcodes"].Value);

my Plugin1.dll.config looked as below;

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <appSettings>
  <add key="cmd_location" value="http://..."/>
  <add key="dnd_shortcodes" value="142,145,146,157,165,167,168,171,173,176,178,404,40"/>
 </appSettings>
</configuration>

I found out that my config file lacked the <appSettings> tag, so look around, your issue could have been different but not so far from mine.

Answer 2

If you're using libraries that look up a large amount of configation behind-the-scenes, such as WCF, you might consider doing this:

AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "MyWcfClientWrapper.dll.config");

Or in PowerShell:

[AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", "MyWcfClientWrapper.dll.config")

IMO this technique is a code smell and is really only suitable for use in ad hoc scripting. If you find yourself wanting to do this in production code, maybe it's time for an architectural review.

The following is NOT recommended:
As a technical curiosity, here's a variation on the theme. You can create a static constructor inside one of the classes housed in the DLL, and make this call from there. I wouldn't recommend doing this except as a last resort.

Answer 3

if you want to read settings from the DLL's config file but not from the the root applications web.config or app.config use below code to read configuration in the dll.

var appConfig = ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly().Location);
string dllConfigData = appConfig.AppSettings.Settings["dllConfigData"].Value;

Answer 4

In this post a similar problem was discussed and solve my problem How to load a separate Application Settings file dynamically and merge with current settings? might be helpfu

Answer 5

It confusing to mock a "real" application configuration file. I suggest you roll your own because it is quite easy to parse an XML file using e.g. LINQ.

For example create an XML file MyDll.config like below and copy it alongside the DLL. To Keep it up to date set its property in Visual Studio to "Copy to Output Directory"

<?xml version="1.0" encoding="utf-8" ?>
 <configuration>
  <setting key="KeyboardEmulation" value="Off"></setting>
 </configuration>

In your Code read it like this:

    XDocument config = XDocument.Load("MyDll.config");
    var settings = config.Descendants("setting").Select(s => new { Key = s.Attribute("key").Value, Value = s.Attribute("value").Value });
    bool keyboardEmulation = settings.First(s => s.Key == "KeyboardEmulation").Value == "On";

Answer 6

I know this is late to the party, however I thought I would share the solution I use for DLL's.

I am more of the K.I.S.S. school of thinking, so when I have a .NET DLL that wants to store external data points that control how it works or where it goes, etc. I simply create a "config" class that has only public properties that store all the data points it needs and that I would like to be able to have controlled external to the DLL to prevent recompiling it to make the changes. Then I use .Net's XML Serializing to save and load the object representation of the class to a file.

There are a lot of ways then to handle reading it and accessing it, from a Singleton, a static utility class, to extension methods, etc. This depends on how your DLL is structured and what method will fit your DLL best.