97

I cannot see a app.config file generated for a class library by the VS2008 wizard. In my research I found that in an application only one app.config exists.

Is it a bad thing to add an app.config manually to a class library or are there any other methods which will serve the purpose of an app.config in class library?

I need to store log4net config information inside the app.config file.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
logeeks
  • 4,849
  • 15
  • 62
  • 93

10 Answers10

122

You generally should not add an app.config file to a class library project; it won't be used without some painful bending and twisting on your part. It doesn't hurt the library project at all - it just won't do anything at all.

Instead, you configure the application which is using your library; so the configuration information required would go there. Each application that might use your library likely will have different requirements, so this actually makes logical sense, too.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
  • 2
    I have a Selenium WebDriver class library that I run from NUnit for all of my test cases. I'd rather not have to worry about setting configuration in NUnit. How can I bend and twist to get this done? :-) – JustBeingHelpful Jan 30 '12 at 16:42
  • 3
    Figured it out... If using NUnit, name your app.config file with the same name as your *.nunit project filename. So for example, if you called your project "ClassLibraryA.nunit", then name your class library configuration file "ClassLibraryA.config". They also need to reside in the same folder/directory. NUnit is actually using this as the main configuration file .... add a reference to System.Configuration (in .NET tab) .... and use this code: string settingValue = ConfigurationManager.AppSettings["settingName"]; – JustBeingHelpful Feb 02 '12 at 21:48
  • 2
    How would you recommend setting things up when having integration tests? For me it seems logical to have an app.config in that test library with the connection string. – Tomas Jansson Feb 27 '13 at 11:21
  • 2
    What if you can't configure the application because you don't own it. – Voltage Spike Feb 19 '16 at 18:55
  • @MacGyver When I run unit tests (MSTest), I just add a normal `app.config` file to my project and it gets copied to `bin/$(Configuration)/$(AssemblyName).dll.config`. The test runner loads it in such a way that the test runner uses its own config but my own code sees my own config. – binki Jul 02 '18 at 15:39
  • There's no painful bending and twisting needed to use the app.config of a class library. It can't be use as it is but throughout development it is useful. Plus it doesn't directly answer the question: "adding an app.config manually bad, good are there any ways of doing it in a non manual way?". – Mircea Ion Jun 14 '19 at 14:24
  • The accepted answer s is totally incorrect. Been using app.config files in class libraries for years. – JasonDWilson Aug 17 '21 at 17:45
  • For another view, sometimes you need to add ".config" or ".runsettings" files into your class libraries like UnitTestClassLibrary. Then, the simplest way is to add a notepad into the Class library folder and Save As in the format you wish. Then add it as an Existing item to the Class Library. – blackman Sep 09 '21 at 13:30
54

I don't know why this answer hasn't already been given:

Different callers of the same library will, in general, use different configurations. This implies that the configuration must reside in the executable application, and not in the class library.

You may create an app.config within the class library project. It will contain default configurations for items you create within the library. For instance, it will contain connection strings if you create an Entity Framework model within the class library.

However, these settings will not be used by the executable application calling the library. Instead, these settings may be copied from the library.dll.config file into the app.config or web.config of the caller, so that they may be changed to be specific to the caller, and to the environment into which the caller is deployed.

This is how it has been with .NET since Day 1.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 2
    But what should i do if i need to call webserice functionality from the class library? VS created a default app.config but my application crashed when trying to call webservice function - it can not find config entries... – Laserson Oct 29 '11 at 10:32
  • 1
    You have to copy the elements that were placed in the class library app.config into the app.config or web.config of the caller of the class library. This allows the caller to be in control of the configuration. For instance, the caller now can change the URL of the service that your class library calls, and your class library won't even know about the change. – John Saunders Oct 29 '11 at 11:49
  • 7
    @John Saunders: "may need" are exactly the right words. So there might be situations where configuration settings differ only per server (e.g. connection strings) and it is more convenient to have the dll have it's own configuration than copy it plenty times around for every assembly that uses the dll. In my opinion Microsofts/.NET preferred usage is not a holy grail. It depends really, what is most convenient in a deployment scenario. There is no need to tell Todd off, his opinion is as important as yours or Microsofts. –  Jul 17 '12 at 10:49
  • I'm really interested in this solution - it sounds ideal to me. It makes sense that the library would carry default settings, while the application would have the ability to override them. Would you expand on how settings can be propagated from the library's app.config to the executing assembly's app.config, or direct me to a relevant resource? – crush May 06 '14 at 13:10
  • @crush: It's called "copy and paste". The strongly-typed Settings feature of .NET can help a bit, as it bakes default values into the assembly. – John Saunders Jun 09 '14 at 23:38
  • 1
    @user1531508 As someone who's had to take over "special" code that didn't want to follow Microsoft/.Net "preferred usage" (aka best practices) I'd say no. Following best practices is a holy grail compared to the alternative. And no, Todd's opinion is not as important as Microsoft's. – RMuesi Jun 12 '17 at 17:42
53

Jon, a lot of opinion has been given that didn't correctly answer your question.

I will give MY OPINION and then tell you how to do exactly what you asked for.

I see no reason why an assembly couldn't have its own config file. Why is the first level of atomicy (is that a real word?) be at the application level? Why not at the solution level? It's an arbitrary, best-guess decision and as such, an OPINION. If you were to write a logging library and wanted to include a configuration file for it, that would be used globally, why couldn't you hook into the built-in settings functionality? We've all done it ... tried to provide "powerful" functionality to other developers. How? By making assumptions that inherently translated to restrictions. That's exactly what MS did with the settings framework, so you do have to "fool it" a little.

To directly answer your question, simply add the configuration file manually (xml) and name it to match your library and to include the "config" extension. Example:

MyDomain.Mylibrary.dll.Config

Next, use the ConfigurationManager to load the file and access settings:

string assemblyPath = new Uri(Assembly.GetExecutingAssembly().CodeBase).AbsolutePath;
Configuration cfg = ConfigurationManager.OpenExeConfiguration(assemblyPath);
string result = cfg.AppSettings.Settings["TEST_SETTING"].Value;

Note that this fully supports the machine.config heierarchy, even though you've explicitly chosen the app config file. In other words, if the setting isn't there, it will resolve higher. Settings will also override machine.config entries.

Todd Beaulieu
  • 627
  • 6
  • 7
  • I should also mention that you could have a post-build event that renamed app.config to the final filename, but unit tests would copy the app.config file instead of the final final and wouldn't see the settings. – Todd Beaulieu Aug 31 '11 at 20:27
  • Ugh. Sorry so sloppy. One more thing: you should flag the config file as ALWAYS COPY and set it to CONTENT. – Todd Beaulieu Aug 31 '11 at 20:27
  • 4
    -1: Your opinion, per se, is not important. Facts would be important. .NET, since Day 1, was created so that the callers of a library determine the configuration of items within the library. It's the only thing that makes actual sense for configuration, as different callers of the library may need different configurations. – John Saunders Aug 31 '11 at 20:29
  • 23
    @JohnSaunders "different callers of the library may need different configurations." Exactly, they "may" need different configurations, and your logic makes perfect sense in all cases where the configuration does depend on the caller. But there are several cases where the configuration is used internally for the class library, and the configuration is exactly the same, no matter what the caller is. If you have 10 applications consuming a library, it has to be worse to copy and paste the exact same configuration into 10 config files. – wired_in Jan 23 '14 at 04:01
  • 4
    @ToddBeaulieu: I think the word you want is 'atomicity'. – nicodemus13 Feb 20 '14 at 12:28
  • 4
    In a plugin architecture, it makes indeed sense if all plugins have their own config file. – Davatar Dec 01 '16 at 02:27
  • 1
    @wired_in "But there are several cases where the configuration is used internally for the class library, and the configuration is exactly the same, no matter what the caller is." Sounds like this isn't configuration at all. If it never changed, then why does it need to be configured? I'd say make that stuff const or readonly variables, instead of configurations in a config file. – RMuesi Jun 12 '17 at 17:36
  • 4
    @RMuesi Noone said it never changes, just that it doesn't depend on the caller of the library. Config can change depending on whether you are debugging the library versus a production release. It can change depending on the environment you are building for, etc. – wired_in Jun 13 '17 at 15:22
  • If you name your file `app.config` it automatically gets renamed correctly by VS. At least with version 2013 (IIRC) and newer. Did this really not happen in the past? – binki Jul 02 '18 at 15:41
  • 1
    In our use case, having the library use its own .config file makes sense. We have created a C# library that is accessed via COM+ through a legacy ASP application. there is no "app.config" because the application using the library is not .NET. I'm going to give this a try and see if it meets our requirements. – Justin May 30 '19 at 14:59
  • Thanks this is exactly what I wanted. And it is really logical. – Spongebob Comrade Jan 07 '22 at 00:48
  • 1
    Nice! This was an elegant solution – steb Jan 19 '23 at 14:37
  • I have to qualify the obvious choices for using this, here. For instance, we prepare a lot of applications to run internally in our organisation. There are standard database connections for sections of applications that *should not* be left open to the developer's choice - they need to reflect what is. They also need to be flexible enough, however, to change when needed. Personally, I would take this a stage further and either create a configuration that can localise settings from a server, or have the settings stored in one central location on a server that the class can reference. – Paul Jun 21 '23 at 09:18
10

In fact, the class library you are implementing, is retrieving information from app.config inside the application that is consuming it, so, the most correct way to implement configuration for class libraries at .net in VS is to prepare app.config in the application to configure everything it consumes, like libraries configuration.

I have worked a little with log4net, and I found that the one who prepared the application always had a section for log4net configuration inside main app.config.

This configuration for example has a log4net section.

Kissaki
  • 8,810
  • 5
  • 40
  • 42
Amedio
  • 895
  • 6
  • 13
  • 4
    +1 Exactly; The `app.config` is loaded from the actual program that eventually runs... not the individual class libraries. It is frankly a bit confusing how many don't know this very basic fact. – Andrew Barber Apr 15 '11 at 16:43
  • Maybe people come from Java language and there you have a log4java.properties and a separate properties file for your application. – Amedio Apr 16 '11 at 11:10
6

If you want to configure your project logging using log4Net, while using a class library, There is no actual need of any config file. You can configure your log4net logger in a class and can use that class as library.

As log4net provides all the options to configure it.

Please find the code below.

public static void SetLogger(string pathName, string pattern)
        {
            Hierarchy hierarchy = (Hierarchy)LogManager.GetRepository();

            PatternLayout patternLayout = new PatternLayout();
            patternLayout.ConversionPattern = pattern;
            patternLayout.ActivateOptions();

            RollingFileAppender roller = new RollingFileAppender();
            roller.AppendToFile = false;
            roller.File = pathName;
            roller.Layout = patternLayout;
            roller.MaxSizeRollBackups = 5;
            roller.MaximumFileSize = "1GB";
            roller.RollingStyle = RollingFileAppender.RollingMode.Size;
            roller.StaticLogFileName = true;
            roller.ActivateOptions();
            hierarchy.Root.AddAppender(roller);

            MemoryAppender memory = new MemoryAppender();
            memory.ActivateOptions();
            hierarchy.Root.AddAppender(memory);

            hierarchy.Root.Level = log4net.Core.Level.Info;
            hierarchy.Configured = true;
      }

Now instead of calling XmlConfigurator.Configure(new FileInfo("app.config")) you can directly call SetLogger with desired path and pattern to set the logger in Global.asax application start function.

And use the below code to log the error.

        public static void getLog(string className, string message)
        {
            log4net.ILog iLOG = LogManager.GetLogger(className);
            iLOG.Error(message);    // Info, Fatal, Warn, Debug
        }

By using following code you need not to write a single line neither in application web.config nor inside the app.config of library.

Rahul
  • 1,070
  • 3
  • 21
  • 47
  • 2
    i felt this is the best answer...rather than discussing whether configuration file should be allowed for a library...this answer answers the OP's question of using Log4net – saurav Jan 18 '17 at 09:47
  • 2
    Even though the question used log4net as an example, the actual question is about configs in general. I’d say that answers about log4net are actually irrelevant. – binki Jul 02 '18 at 15:43
4

Actually, for some rare case you could store app.config in class libraries (by adding manually) and parse it by OpenExeConfiguration.

 var fileMap =
    new ExeConfigurationFileMap {ExeConfigFilename = 
    @"C:\..somePath..\someName.config"};
 System.Configuration.Configuration config =
    ConfigurationManager.OpenMappedExeConfiguration(fileMap, 
    ConfigurationUserLevel.None);

You should really estimate the real need of this. For abstract data its not the best solution, but "Config Sections" could be very usefull!!

For example, we organised our N-Tier WCF architecture decoupled, without any metadata, simply by using Unity Container and Injection Factory based on Channel Factory T. We added externall ClassLibrary dll with just [Service Contract] Interfaces and common app.config in order to read endpoints from clientsection, and easily add/change them at one place.

Community
  • 1
  • 1
Roma Borodov
  • 596
  • 4
  • 10
3

You do want to add App.config to your tests class library, if you're using a tracer/logger. Otherwise nothing gets logged when you run the test through a test runner such as TestDriven.Net.

For example, I use TraceSource in my programs, but running tests doesn't log anything unless I add an App.config file with the trace/log configuration to the test class library too.

Otherwise, adding App.config to a class library doesn't do anything.

Daniel A.A. Pelsmaeker
  • 47,471
  • 20
  • 111
  • 157
3

Your answer for a non manual creation of an app.config is Visual Studio Project Properties/Settings tab.

When you add a setting and save, your app.config will be created automatically. At this point a bunch of code is generated in a {yourclasslibrary.Properties} namespace containing properties corresponding to your settings. The settings themselves will be placed in the app.config's applicationSettings settings.

 <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
        <section name="ClassLibrary.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
</configSections>
<applicationSettings>
    <ClassLibrary.Properties.Settings>
        <setting name="Setting1" serializeAs="String">
            <value>3</value>
        </setting>
    </BookOneGenerator.Properties.Settings>
</applicationSettings>

If you added an Application scoped setting called Setting1 = 3 then a property called Setting1 will be created. These properties are becoming at compilation part of the binary and they are decorated with a DefaultSettingValueAttribute which is set to the value you specified at development time.

     [ApplicationScopedSetting]
    [DebuggerNonUserCode]
    [DefaultSettingValue("3")]
    public string Setting1
    {
        get
        {
            return (string)this["Setting1"];
        }
    }

Thus as in your class library code you make use of these properties if a corresponding setting doesn't exist in the runtime config file, it will fallback to use the default value. That way the application won't crash for lacking a setting entry, which is very confusing first time when you don't know how these things work. Now, you're asking yourself how can specify our own new value in a deployed library and avoid the default setting value be used?

That will happen when we properly configure the executable's app.config. Two steps. 1. we make it aware that we will have a settings section for that class library and 2. with small modifications we paste the class library's config file in the executable config. (there's a method where you can keep the class library config file external and you just reference it from the executable's config.

So, you can have an app.config for a class library but it's useless if you don't integrate it properly with the parent application. See here what I wrote sometime ago: link

Mircea Ion
  • 658
  • 5
  • 20
1

There is no automatic addition of app.config file when you add a class library project to your solution.

To my knowledge, there is no counter indication about doing so manualy. I think this is a common usage.

About log4Net config, you don't have to put the config into app.config, you can have a dedicated conf file in your project as well as an app.config file at the same time.

this link http://logging.apache.org/log4net/release/manual/configuration.html will give you examples about both ways (section in app.config and standalone log4net conf file)

Bruno
  • 1,944
  • 13
  • 22
0

I would recommend using Properties.Settings to store values like ConnectionStrings and so on inside of the class library. This is where all the connection strings are stores in by suggestion from visual studio when you try to add a table adapter for example. enter image description here

And then they will be accessible by using this code every where in the clas library

var cs=  Properties.Settings.Default.[<name of defined setting>];
sishanov
  • 141
  • 2
  • 9