Equivalent to 'app.config' for a library (DLL)

Question

Is there an equivalent to app.config for libraries (DLLs)? If not, what is the easiest way to store configuration settings that are specific to a library? Please consider that the library might be used in different applications.

Solution 1

You can have separate configuration file, but you'll have to read it "manually", the ConfigurationManager.AppSettings["key"] will read only the config of the running assembly.

Assuming you're using Visual Studio as your IDE, you can right click the desired project → Add → New item → Application Configuration File

This will add App.config to the project folder, put your settings in there under <appSettings> section. In case you're not using Visual Studio and adding the file manually, make sure to give it such name: DllName.dll.config, otherwise the below code won't work properly.

Now to read from this file have such function:

string GetAppSetting(Configuration config, string key)
{
    KeyValueConfigurationElement element = config.AppSettings.Settings[key];
    if (element != null)
    {
        string value = element.Value;
        if (!string.IsNullOrEmpty(value))
            return value;
    }
    return string.Empty;
}

And to use it:

Configuration config = null;
string exeConfigPath = this.GetType().Assembly.Location;
try
{
    config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
catch (Exception ex)
{
    //handle errror here.. means DLL has no sattelite configuration file.
}

if (config != null)
{
    string myValue = GetAppSetting(config, "myKey");
    ...
}

You'll also have to add reference to System.Configuration namespace in order to have the ConfigurationManager class available.

When building the project, in addition to the DLL you'll have DllName.dll.config file as well, that's the file you have to publish with the DLL itself.

Within the VS project, you should set the .config file "Copy to output directory" setting to "Always Copy".

The above is basic sample code, for those interested in a full scale example, please refer to this other answer.

Solution 2

Unfortunately, you can only have one app.config file per executable, so if you have DLL’s linked into your application, they cannot have their own app.config files.

Solution is: You don't need to put the App.config file in the Class Library's project.
You put the App.config file in the application that is referencing your class library's dll.

For example, let's say we have a class library named MyClasses.dll which uses the app.config file like so:

string connect = 
ConfigurationSettings.AppSettings["MyClasses.ConnectionString"];

Now, let's say we have an Windows Application named MyApp.exe which references MyClasses.dll. It would contain an App.config with an entry such as:

<appSettings>
    <add key="MyClasses.ConnectionString"
         value="Connection string body goes here" />
</appSettings>

OR

An xml file is best equivalent for app.config. Use xml serialize/deserialize as needed. You can call it what every you want. If your config is "static" and does not need to change, your could also add it to the project as an embedded resource.

Hope it gives some Idea

Solution 3

Configuration files are application-scoped and not assembly-scoped. So you'll need to put your library's configuration sections in every application's configuration file that is using your library.

That said, it is not a good practice to get configuration from the application's configuration file, specially the appSettings section, in a class library. If your library needs parameters, they should probably be passed as method arguments in constructors, factory methods, etc. by whoever is calling your library. This prevents calling applications from accidentally reusing configuration entries that were expected by the class library.

That said, XML configuration files are extremely handy, so the best compromise that I've found is using custom configuration sections. You get to put your library's configuration in an XML file that is automatically read and parsed by the framework and you avoid potential accidents.

You can learn more about custom configuration sections on MSDN and also Phil Haack has a nice article on them.

Solution 4

I am currently creating plugins for a retail software brand, which are actually .net class libraries. As a requirement, each plugin needs to be configured using a config file. After a bit of research and testing, I compiled the following class. It does the job flawlessly. Note that I haven't implemented local exception handling in my case because, I catch exceptions at a higher level.

Some tweaking maybe needed to get the decimal point right, in case of decimals and doubles, but it works fine for my CultureInfo...

static class Settings
{
    static UriBuilder uri = new UriBuilder(Assembly.GetExecutingAssembly().CodeBase);
    static Configuration myDllConfig = ConfigurationManager.OpenExeConfiguration(uri.Path);
    static AppSettingsSection AppSettings = (AppSettingsSection)myDllConfig.GetSection("appSettings");
    static NumberFormatInfo nfi = new NumberFormatInfo() 
    { 
        NumberGroupSeparator = "", 
        CurrencyDecimalSeparator = "." 
    };

    public static T Setting<T>(string name)
    {
        return (T)Convert.ChangeType(AppSettings.Settings[name].Value, typeof(T), nfi);
    }
}

App.Config file sample

<add key="Enabled" value="true" />
<add key="ExportPath" value="c:\" />
<add key="Seconds" value="25" />
<add key="Ratio" value="0.14" />

Usage:

  somebooleanvar = Settings.Setting<bool>("Enabled");
  somestringlvar = Settings.Setting<string>("ExportPath");
  someintvar =     Settings.Setting<int>("Seconds");
  somedoublevar =  Settings.Setting<double>("Ratio");

Credits to Shadow Wizard & MattC

Solution 5

public class ConfigMan
{
    #region Members

    string _assemblyLocation;
    Configuration _configuration;

    #endregion Members

    #region Constructors

    /// <summary>
    /// Loads config file settings for libraries that use assembly.dll.config files
    /// </summary>
    /// <param name="assemblyLocation">The full path or UNC location of the loaded file that contains the manifest.</param>
    public ConfigMan(string assemblyLocation)
    {
        _assemblyLocation = assemblyLocation;
    }

    #endregion Constructors

    #region Properties

    Configuration Configuration
    {
        get
        {
            if (_configuration == null)
            {
                try
                {
                    _configuration = ConfigurationManager.OpenExeConfiguration(_assemblyLocation);
                }
                catch (Exception exception)
                {
                }
            }
            return _configuration;
        }
    }

    #endregion Properties

    #region Methods

    public string GetAppSetting(string key)
    {
        string result = string.Empty;
        if (Configuration != null)
        {
            KeyValueConfigurationElement keyValueConfigurationElement = Configuration.AppSettings.Settings[key];
            if (keyValueConfigurationElement != null)
            {
                string value = keyValueConfigurationElement.Value;
                if (!string.IsNullOrEmpty(value)) result = value;
            }
        }
        return result;
    }

    #endregion Methods
}

Just for something to do, I refactored the top answer into a class. The usage is something like:

ConfigMan configMan = new ConfigMan(this.GetType().Assembly.Location);
var setting = configMan.GetAppSetting("AppSettingsKey");

View more solutions

Comments

[Jan Remunda]

if you are using custom config sections, you can use configSource attribute: <MySection configSource="mysection.config"/> and config file only copy with dll

[Joe]

" it is not a good practice to get configuration from a configuration file in a class library" - I strongly disagree with this. For example, a DAL class library should normally get configuration data such as connection strings from the application configuration file rather than having this information passed from the BLL tier. Any Framework classes that use configuration (e.g. ASP.NET Membership) work in this way.

[madd0]

I modified my answer slightly. I still stand by what I said, but you're right, I never intended to imply that configuration files should not be used at all. What I meant was that, instead of convention-based appSettings, custom sections offer a great alternative; it is pretty much what ASP.NET Membership uses after all.

[Rodney]

This works great, thanks - however, during Development I need to output this app.config to the test harness folder, NOT the dll's folder. If I copy it manually into the test harness bin folder then this code works (during publishing I am JUST releasing the dll and the config file). How can I copy the dll app.config to the test harness folder during dev?

[Shadow The Kid Wizard]

@Rodney try changing string exeConfigPath = this.GetType().Assembly.Location; to something like: string exeConfigPath = @"C:\MyFolder\DllFolder\ExeName.exe";

[ghostJago]

Add it as a link in the add existing item. See my answer below for how to do this

[Gone Coding]

ConfigurationSettings is now obsolete and replaced by ConfigurationManager, so the equivalent would now be ConfigurationManager.AppSettings

[Sandeep Datta]

Any idea how to do this if the dll is being copied to some unknown folder by the resharper unit testing tool?

[Shadow The Kid Wizard]

@SandeepDatta whoever or whatever copy the dll should also copy its config file. Otherwise you're pretty much stuck. Sounds like a bug in the "resharper unit testing tool", you better submit a bug report in their support forum if possible. :)

[Sandeep Datta]

@ShadowWizard Yeah I had a feeling I am hosed on this one :)

[MonkeyMagix]

I have added new questions as asked e.g about the function always returning an empty string and mail server settings > stackoverflow.com/questions/25123544/… and > stackoverflow.com/questions/25138788/… so I hope someone replies to them as I am almost on the edge of just hardcoding the values into the DLL!

[Jeff G]

A tip for anyone else implementing this: to automate the generation of DllName.dll.config by referencing applications, I simply renamed app.config to DllName.dll.config, and changed the "Copy to Output Directory" property to "Copy always". Also, my need was for connection strings, which can be retrieved using config.ConnectionStrings.ConnectionStrings[connStringName].C‌​onnectionString.

[Matteo Gaggiano]

Please, review the vote for deletion. My mistake was send the answer while writing it.

[Firegarden]

I posted an exact copy of this answer but updated to be a self contained class. See my answer below.

[Shadow The Kid Wizard]

Thanks @Firegarden guess it can come handy for some.

[raiserle]

down vote. the question is per dll and not per app. best solution: stackoverflow.com/a/5191101/2935383

[SaddamBinSyed]

the app.cfg file name is very important to read the appcfg values, the file name should be "DLL_NAME.DLL.CONFIG"

[Shadow The Kid Wizard]

@SaddamBinSyed true, my answer was based on the assumption Visual Studio is used, which gives such name automatically when compiling the project. Edited to clarify for those not using the Studio. Thanks! :)

[beanmf]

I suspect this suggestion won't work in the case of late-bound dlls which would have no knowledge of the executable calling them.

[Code Pope]

This will automatically create a config file for the dll. But you cannot read modified values from the config file at runtime. Finally it will show the values of your calling application. See also @Joe answer

[Pedro Mora]

No if it is configured for the user's configuration. The idea is to edit what the user needs, configure them at runtime and then save them. Then, when the user works with the library, it loads its configuration, saved in its respective user path, But only works for him.

[Ewan]

Brilliant! This helped me to get my Windows Application Driver automated tests running on target machines. The dlls in my case were from a test project. The only thing I would add is that in Win App Driver (and possibly other forms of automated testing), the BaseDirectory is actually the output folder which changes each time. I had to substring like this...AppDomain.CurrentDomain.BaseDirectory.Substring(0, AppDomain.CurrentDomain.BaseDirectory.IndexOf("TestResults")‌​). this way I could cut out the unwanted output folder as my config file was in the same folder as my test dlls.

[nmarler]

This should be the accepted answer. Very compact and "works right out of the box". Good stuff

[Zeek2]

This doesn't work for me: I'm using VS2017 and it is not writing my the content of my new App.config file to the DLL.config. Worse yet, it clears the settings that I manually set in the DLL.config as well :( [Saddam's suggest naming of file also did not work for me.] When I manually add my settings to the DLL.config my xUnit tests pick up the settings fine tho'.

[Zeek2]

Caveat to the above: when running xUnit tests on your .NET assembly DLL, xUnit will read the library's .config, at runtime. And it will ignore any App.config added to the test or DLL project.

[Zeek2]

Correction to my last comment. In my VS2017 solution, by removing my new, non-working App.config files from my test & DLL projects and just re-adding it to my test project it suddenly starting working! My App.config setting now automatically get included in the DLL.configs. What a relief!

[andrew.rockwell]

I was overwriting the generated .dll.config with a post-build event...