Not able to retrieve key from App.Config

In my WAP project I have a reference to another C# Project (non-web). In that C# project I have an app.config and I renamed it to [projectName].config

I then tried to grab a key from my [project].config from some code within my C# Project and it can't find it:

return ConfigurationManager.AppSettings["somekey"]

So I am wondering why it can't read my app.config. I would think that ConfigurationManager would be able to read keys form th开发者_JS百科e Web project's web.config AND my [projectName].config (app.config) file that is in my referenced project as well?

ConfigurationManager will read the configuration of the application's host. In your case, the web app is the application's host - therefore, calling ConfigurationManager will read from your web.config - even if you make calls to ConfigurationManager from a referenced dll.

If your web application references a dll, then the dll should get its configuration from the web.config. This is the best thing for the application. If the dll is referenced by multiple types of applications, the settings in the config may need to be different.

Try putting this in your web.config:

<appSettings file="externalSettings.config"/>

externalSettings.config is the other config file you want to use.

For a non web assembly, it looks for AssemblyName.dll where AssemblyName corresponds to your assembly name. Ex: if your assembly name is Com.MyProject.Library1.dll, then the config file it's looking for is Com.MyProject.Library1.dll.config.

UPDATE: I did some more research on this, and as noted here, "The ConfigurationManager will read from the configuration file that was loaded by the AppDomain when it loaded the application". So in the case of your web application, it's going to read from the web.config file if you are accessing ConfigurationManager from within your aspx code.

I think the most suitable workaround to do what you want is the workaround I've already provided, namely, to use the appSettings configuration parameter which will allow you to have a shared configuration file for your aspx app and your class library.

As an example, in your shared configuration file, you'd want something like this:

<appSettings>
    <add key="Key1" value="test"/>
</appSettings>

Let's say this file was c:\temp\shared.config. Then in your web.config, you could refer to it like this:

<appSettings file="C:\\temp\\shared.config"></appSettings>

You would put this same line in your class library's app.config.

And now you'll be able to use:

ConfigurationManager.AppSettings["Key1"]

from either your aspx app or your class library and you'll get the value.

So if you really need "common" configuration parameters shared across aspx and class libraries, this is the way to do it.

Configuration is always read from executing assembly.

So you should just place needed settings to proper *.config file. It will be just easy for everyone who need to edit this file.

As said above, you shouldn't change your application .config filename, this is not going to make any effect. The reason is that by default, the compiler copies App.config contents into Debug[AppName].exe.config. Then, when the application is loaded, the .NET CLR loads the data from [AppName].exe.config into memory then never touches it back.

There are two possibilities here:

First, as noted here in Visual Studio projects, place the .config file in the project directory and set its Copy To Output Directory property to Copy always or Copy if newer. Visual Studio automatically copies the file to the directory where it compiles the assembly.

The second possibility is (more about it here) that you explicitly load the config using the ConfigurationManager::OpenExeConfiguration method.

This will load any *.config file from your bin directory.

public Configuration DllConfiguration( string filename )
{
    var map = new ExeConfigurationFileMap {
         ExeConfigFilename = Path.Combine( AppDomain.CurrentDomain.BaseDirectory, filename )
    };

    return ConfigurationManager.OpenMappedExeConfiguration( map, ConfigurationUserLevel.None );
}

There is a good discussion about per dll .config files as a design question in the top voted answer to this question C# DLL config file