Can a class library have an App.config file?

Here is what my solution is looking like at the moment:

In the Tutomentor.Branding project, I'd like to save branding information in the App.config file, like names, colors, etc.

In the Tutomentor.Data project, the App.config was created when I added an entity .edmx model file.

Is this possible? Any recommendations?

When deploying, will the output COMBINE these App.config files into a single one?

Solution 1:

No, class libraries can hold setting files, but their values will be defined in the application configuration (web.config, app.config...).

That's because of configuration settings overriding feature.

You'll need to declare the assemblies' configuration sections in the app.config or web.config of your application (WPF, SL, ASP.NET...) and define a value for a particular number of settings defined in the proper assembly settings.

EDIT: Add a setting file to your project and add a setting with application scope, and your assembly would have something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="Assembly1.Settings1" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <Assembly1.Settings1>
            <setting name="settingA" serializeAs="String">
                <value>a value</value>
            </setting>
        </Assembly1.Settings1>
    </applicationSettings>
</configuration> 

Now you'd need to go to your application, and you need to copy-paste the section group, and section declarations, and the definition of the values for the settings. That's all.

Solution 2:

While this is an older thread, It does warrent another look.

It seems you may want to look at the issue in a different way.

Class libraries by nature are supposed to be portable. So, any configuration needed should be passed to the class, instead of residing with the library. Things like connection strings are by nature transitory, so it makes sense to put them in the owning application.

When utilizing the methods contained in the library, you pass any needed information as part of the method's signature, or as a public property in the class. I suggest you create public properties for your configuration items, and pass them when you instantiate the class.

Now you have no issues with an app.config for the DLL, and the DLL is then truly portable.