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.

Congo

Answer 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.

Ante

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? – Betaine

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

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

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

@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. :) – Ante

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

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].ConnectionString. – Assimilate

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

Thanks @Kurrajong guess it can come handy for some. – Ante

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

@Piotr 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! :) – Ante

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'. – Gatlin

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! – Gatlin

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

How do you handle this for config elements that are NOT controlled by your own code? For example, I need to have a <runtime><assemblyBinding> version redirect, so that .Net loads the correct version of a framework package. However, the exe is using its own config for this, and will not read my DLL's config. How can I set such config values for my DLL? – Unfailing

@SeanWorle I don't think such thing is possible, and if it is, I don't know how to do that, sorry. – Ante

Answer 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

Autoicous

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

down vote. the question is per dll and not per app. best solution: https://mcmap.net/q/129414/-equivalent-to-39-app-config-39-for-a-library-dll – Indigenous

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

Answer 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.

Argilliferous

" 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. – Confiscate

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. – Argilliferous

Answer 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

Cervantes

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

Answer 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");

Kurrajong

Answer 6

If you add Settings to a Class Library project in Visual Studio (Project Properties, Settings), it will add an app.config file to your project with the relevant userSettings/applicatioNSettings sections, and the default values for these settings from your Settings.settings file.

However this configuration file will not be used at runtime - instead the class library uses the configuration file of its hosting application.

I believe the main reason for generating this file is so that you can copy/paste the settings into the host application's configuration file.

Confiscate

Answer 7

I faced the same problem and resolved it by creating a static class Parameters after adding an Application Configuration File to the project:

public static class Parameters
{
    // For a Web Application
    public static string PathConfig { get; private set; } =
        Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "web.config");

    // For a Class Library
    public static string PathConfig { get; private set; } =
        Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin", "LibraryName.dll.config");

    public static string GetParameter(string paramName)
    {
        string paramValue = string.Empty;

        using (Stream stream = File.OpenRead(PathConfig))
        {
            XDocument xdoc = XDocument.Load(stream);

            XElement element = xdoc.Element("configuration").Element("appSettings").Elements().First(a => a.Attribute("key").Value == paramName);
            paramValue = element.Attribute("value").Value;
        }

        return paramValue;
    }
}

Then get a parameter like this:

Parameters.GetParameter("keyName");

Coccidioidomycosis

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. – Determiner

Answer 8

In response to the original question, I typically add the config file in my test project as a link; you can then use the DeploymentItem attribute to addit to the Out folder of the test run.

[TestClass]
[DeploymentItem("MyProject.Cache.dll.config")]
public class CacheTest
{
    .
    .
    .
    .
}

In response to the comments that Assemblies can't be project specific, they can and it provides great flexibility esp. when working with IOC frameworks.

Archy

Answer 9

assemblies don't have their own app.config file. They use the app.config file of the application that is using them. So if your assembly is expecting certain things in the config file, then just make sure your application's config file has those entries in there.

If your assembly is being used by multiple applications then each of those applications will need to have those entries in their app.config file.

What I would recommended you do is define properties on the classes in your assembly for those values for example

private string ExternalServicesUrl
{
  get
  {
    string externalServiceUrl = ConfigurationManager.AppSettings["ExternalServicesUrl"];
    if (String.IsNullOrEmpty(externalServiceUrl))
      throw new MissingConfigFileAppSettings("The Config file is missing the appSettings entry for: ExternalServicesUrl");
    return externalServiceUrl;
  }
}

Here, the property ExternalServicesUrl get's its value from the application's config file. If any application using this assembly is missing that setting in the config file you'll get an exception o it's clear that something went missing.

MissingConfigFileAppSettings is a custom Exception. You may want to throw a different exception.

Of course a better design would be for the method of those classes to be provided those values as parameters rather than relying on config file setting. That way the applications using these classes can decide from where and how they provide these values.

Locomotive

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. – Gatlin

Answer 10

Use add existing item, select the app config from dll project. Before clicking add, use the little down arrow on the right hand side of the add button to "add as link"

I do this all the time in my dev.

Candra

Answer 11

Preamble: I'm using NET 2.0;

The solution posted by Yiannis Leoussis is acceptable but I had some problem with it.

First, the static AppSettingsSection AppSettings = (AppSettingsSection)myDllConfig.GetSection("appSettings"); returns null. I had to change it to static AppSettingSection = myDllConfig.AppSettings;

Then the return (T)Convert.ChangeType(AppSettings.Settings[name].Value, typeof(T), nfi); doesn't have a catch for Exceptions. So I've changed it

try
{
    return (T)Convert.ChangeType(AppSettings.Settings[name].Value, typeof(T), nfi);
}
catch (Exception ex)
{
    return default(T);
}

This works very well but if you have a different dll you have to rewrite every time the code for every assembly. So, this is my version for an Class to instantiate every time you need.

public class Settings
{
    private AppSettingsSection _appSettings;
    private NumberFormatInfo _nfi;

    public Settings(Assembly currentAssembly)
    {
        UriBuilder uri = new UriBuilder(currentAssembly.CodeBase);
        string configPath = Uri.UnescapeDataString(uri.Path);
        Configuration myDllConfig = ConfigurationManager.OpenExeConfiguration(configPath);
        _appSettings = myDllConfig.AppSettings;
        _nfi = new NumberFormatInfo() 
        { 
            NumberGroupSeparator = "", 
            CurrencyDecimalSeparator = "." 
        };
    }


    public T Setting<T>(string name)
    {
        try
        {
            return (T)Convert.ChangeType(_appSettings.Settings[name].Value, typeof(T), _nfi);
        }
        catch (Exception ex)
        {
            return default(T);
        }
    }
}

For a config:

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

Use it as:

Settings _setting = new Settings(Assembly.GetExecutingAssembly());

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

Conventicle

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

Answer 12

Why not to use:

• [ProjectNamespace].Properties.Settings.Default.[KeyProperty] for C#
• My.Settings.[KeyProperty] for VB.NET

You just have to update visually those properties at design-time through:

[Solution Project]->Properties->Settings

Montreal

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 @Confiscate answer – Wit

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. – Montreal

Answer 13

As far as I'm aware, you have to copy + paste the sections you want from the library .config into the applications .config file. You only get 1 app.config per executable instance.

Innards

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

I have added new questions as asked e.g about the function always returning an empty string and mail server settings > #25124044 and > #25139288 so I hope someone replies to them as I am almost on the edge of just hardcoding the values into the DLL! – Flemings

Answer 14

use from configurations must be very very easy like this :

var config = new MiniConfig("setting.conf");

config.AddOrUpdate("port", "1580");

if (config.TryGet("port", out int port)) // if config exist
{
    Console.Write(port);
}

for more details see MiniConfig

Rutilant

Answer 15

I took a look at the AppDomain instead of the assembly. This has the benefit of working inside static methods of a library. Link seems to work great for getting the key value as suggested by the other answers here.

public class DLLConfig
{
    public static string GetSettingByKey(AppDomain currentDomain, string configName, string key)
    {
        string value = string.Empty;
        try
        {  
            string exeConfigPath = (currentDomain.RelativeSearchPath ?? currentDomain.BaseDirectory) + "\\" + configName;
            if (File.Exists(exeConfigPath))
            {
                using (Stream stream = File.OpenRead(exeConfigPath))
                {
                    XDocument xdoc = XDocument.Load(stream);
                    XElement element = xdoc.Element("configuration").Element("appSettings").Elements().First(a => a.Attribute("key").Value == key);
                    value = element.Attribute("value").Value;
                }
            }

        }
        catch (Exception ex)
        {
                
        }
        return value;
            
    }
}

Use it within your library class like so;

namespace ProjectName
{
     public class ClassName
     {
         public static string SomeStaticMethod()
         {
             string value = DLLConfig.GetSettingByKey(AppDomain.CurrentDomain,"ProjectName.dll.config", "keyname");
         }
     }
}

Roshan

Answer 16

Several answers above work If using Shadow wizard from a static class in your DLL then replace

string exeConfigPath = this.GetType().Assembly.Location;

With

string exeConfigPath = typeof(MyClassName).Assembly.Location;

If using yiannis-leoussis (on Windows at least) replace

static Configuration myDllConfig = ConfigurationManager.OpenExeConfiguration(uri.Path);

With LocalPath

static Configuration myDllConfig = ConfigurationManager.OpenExeConfiguration(uri.Uri.LocalPath);

Platinous