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.

- 18,291
- 25
- 109
- 191

- 34,517
- 56
- 153
- 221
16 Answers
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.

- 3,062
- 16
- 30

- 66,030
- 26
- 140
- 208
-
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? – Rodney May 13 '11 at 01:55
-
1@Rodney try changing `string exeConfigPath = this.GetType().Assembly.Location;` to something like: `string exeConfigPath = @"C:\MyFolder\DllFolder\ExeName.exe";` – Shadow The GPT Wizard May 13 '11 at 18:57
-
Add it as a link in the add existing item. See my answer below for how to do this – ghostJago May 16 '13 at 22:20
-
1Any idea how to do this if the dll is being copied to some unknown folder by the resharper unit testing tool? – Sandeep Datta Oct 01 '13 at 09:43
-
@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. :) – Shadow The GPT Wizard Oct 01 '13 at 09:48
-
@ShadowWizard Yeah I had a feeling I am hosed on this one :) – Sandeep Datta Oct 01 '13 at 15:32
-
13A 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. – Jeff G Jan 22 '15 at 18:49
-
I posted an exact copy of this answer but updated to be a self contained class. See my answer below. – Firegarden Feb 02 '17 at 03:57
-
Thanks @Firegarden guess it can come handy for some. – Shadow The GPT Wizard Feb 02 '17 at 07:27
-
2the app.cfg file name is very important to read the appcfg values, the file name should be "DLL_NAME.DLL.CONFIG" – SaddamBinSyed Dec 10 '17 at 05:33
-
@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! :) – Shadow The GPT Wizard Dec 10 '17 at 08:37
-
1This 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 Jun 19 '19 at 09:17
-
2Correction 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! – Zeek2 Jun 19 '19 at 09:49
-
I was overwriting the generated .dll.config with a post-build event... – andrew.rockwell Mar 03 '20 at 19:31
-
How do you handle this for config elements that are NOT controlled by your own code? For example, I need to have a
– Sean Worle Apr 06 '23 at 19:28version 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? -
@SeanWorle I don't think such thing is possible, and if it is, I don't know how to do that, sorry. – Shadow The GPT Wizard Apr 10 '23 at 16:27
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

- 10,252
- 6
- 30
- 51

- 7,033
- 14
- 43
- 71
-
6`ConfigurationSettings` is now obsolete and replaced by `ConfigurationManager`, so the equivalent would now be `ConfigurationManager.AppSettings` – iCollect.it Ltd Sep 20 '13 at 10:50
-
2down vote. the question is per dll and not per app. best solution: https://stackoverflow.com/a/5191101/2935383 – raiserle Oct 17 '17 at 11:09
-
4I suspect this suggestion won't work in the case of late-bound dlls which would have no knowledge of the executable calling them. – beanmf Feb 11 '18 at 03:15
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.

- 9,053
- 3
- 35
- 62
-
7" 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. – Joe Mar 04 '11 at 07:50
-
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. – madd0 Mar 04 '11 at 07:59
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

- 159
- 2
- 4
-
1This should be the accepted answer. Very compact and "works right out of the box". Good stuff – nmarler Apr 27 '19 at 13:18
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");

- 41
- 8

- 362
- 2
- 10
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.

- 122,218
- 32
- 205
- 338
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.

- 4,052
- 17
- 19
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");

- 5,752
- 14
- 47
- 55
-
1Brilliant! 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. – Ewan Mar 13 '19 at 09:48
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.

- 3,381
- 5
- 36
- 51
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");

- 1
- 1

- 1,254
- 15
- 28
-
Please, review the vote for deletion. My mistake was send the answer while writing it. – Matteo Gaggiano Dec 17 '15 at 11:10
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

- 4,040
- 4
- 22
- 42

- 375
- 1
- 4
- 16
-
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 – Code Pope Aug 15 '18 at 07:20
-
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. – Pedro Mora Aug 16 '18 at 12:14
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.

- 9,599
- 2
- 36
- 38
-
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 Jun 19 '19 at 09:24
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

- 868
- 13
- 16
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.

- 3,146
- 5
- 32
- 46
-
if you are using custom config sections, you can use configSource attribute:
and config file only copy with dll – Jan Remunda Mar 04 '11 at 07:47 -
I have added new questions as asked e.g about the function always returning an empty string and mail server settings > http://stackoverflow.com/questions/25123544/error-getting-a-dll-config-app-to-return-anything-but-an-empty-string and > http://stackoverflow.com/questions/25138788/how-do-i-use-the-dll-app-config-hack-for-mail-host-settings so I hope someone replies to them as I am almost on the edge of just hardcoding the values into the DLL! – MonkeyMagix Aug 05 '14 at 14:51
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");
}
}
}

- 4,411
- 2
- 36
- 74
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);

- 31
- 3