I am creating one class library project.
Now by default I have one App.Config file so that I am putting all environment specific data in that Config file.
Now based on the Environment (whether Dev / Test / Production), I am planning to have three App.Config files in VS 2010 such as
App.Dev.Config
App.Test.Config
App.Prod.Config
Wondering how would the application know which config file to use.
Anyone implemented this scenario. Any Code samples / Articles would be helpful.
Thanks
The app will use the config file named YourExcecutable.exe.config which is by default the file App.config included in your (executable) project.
Note, that .NET only loads one config file for the whole application. You cannot use multiple configuration files (i.e. one per library project) without coding.
Option: You can use postbuild events and different solution configurations to copy one or another App.Config file to the output folder
Option: You can use the ConfigurationManager Class to load an alternate config file by code.
Loading a different application configuration file at run time can be done using the concept of mapped configuration file. To start with, you need to add reference to System.Configuration.dll in your project.
Set the value of Copy to Output Directory property to Copy if newer (Refer screenshot). This has to be done only for non-default configuration files e.g. App1.config, App2.config, etc. Leave the default configuration file namely App.config as it is . Due to this change, all the non-default application configuration files will be available in the project output directory (\bin\debug) when the project is built. Default value of this property is Do not copy.
Here is the code snippet on how to read configuration data from non-default configuration files:
ExeConfigurationFileMap configFileMap = new ExeConfigurationFileMap();
configFileMap.ExeConfigFilename = "App1.config"; // app1.config should be present in root directory from where application exe is kicked off
// Get the mapped configuration file
var config = ConfigurationManager.OpenMappedExeConfiguration(configFileMap, ConfigurationUserLevel.None);
//get the relevant section from the config object
AppSettingsSection section = (AppSettingsSection)config.GetSection("appSettings");
//get key value pair
var keyValueConfigElement = section.Settings["appSettingsKey"];
var appSettingsValue = keyValueConfigElement.Value;
If you have multiple application (aka app) configuration files then you can keep a setting in default App.config file with the help of which you can make a decision at run time about which non-default configuration file to load e.g. App1.config
Note: Now look at below code:
ConfigurationManager.AppSettings["DeployEnv"]
This code will still read the data from the default App.config file. This behavior can't be changed. There is no way to prohibit the Loading of default App.config file. You have to use alternate means as discussed in this post to read the data from non-default configuration files
Now there is an even better solution: SlowCheetah - XML Transforms
Related
I'm trying to understand Application Settings / AppSettings.
My understanding is that AppSettings (which are within the app.config file) are accessed via ConfigurationManager.AppSettings, and this is considered deprecated functionality.
I understand Application Settings are accessed via Properties.Settings.Default, and are usually created as .settings files (in Visual Studio this can be done in Project Properties).
If this is correct (please confirm), my question is why do all projects in Visual Studio automatically create an App.config file? Can / should I delete this file and create a Settings.settings file instead? Should I use both? (why?) Can I access the app.config file using Properties.Settings? If so, how?
Also, if Properties.Settings.Default accesses the "default" settings file, how / why would you access a file other than the default one?
Edit: This question is not answered by the AppSettings vs Application Settings threads, because my specific question is why I need an App.Config file.
ApplicationSettings are preferred over AppSettings as they are strongly typed, but there are times (such as in Azure) where AppSettings are preferred as they can be set from the Azure control panel on an instance by instance basis.
That said, let's look at the other part of your question relating to Settings.Default vs. App.Config.
I would not remove the App.Config from every project, as it gets automatically updated when you update your settings. The settings file has the default values in code, but the App.Config file can override those at runtime. This is nice to be able to copy the relevant sections to new applications (into their app.config or web.config) that are going to consume a library.
The only app.config file from your projects that gets executed is the startup project, and the values in that app.config (or web.config as it may be) are the ones used at runtime.
Hopefully this clears up some confusion around the relationship of the files.
Sample Structure of Configuration Files:
ProjectA
- ProjectA.Settings
- App.Config // VS syncs with Settings file
ProjectB
- ProjectB.Settings
- App.Config // VS syncs with Settings file
ProjectC (Startup Project
- ProjectC.Settings
- App.Config
// Can contain override settings for ProjectA.Settings and ProjectB.Settings
I'm trying to use application settings with a C#.NET project I am working on. But I can't seem to get it to return anything other then the default values. Through the project properties I've added a single setting, DBConnectionString, and set its value to a connection string I want to use. Its scope is set to "application".
Doing this created a number of files including Settings.settings, Settings.Designer.CS, and app.conifg. From what I understand the two Settings.* files define a custom Settings class that derives from ApplicationSettingsBase. The Settings class then has custom, type safe, properties that can be used to set and retrieve each setting. The app.config file is a XML file that stores the actual settings values.
When I build my project it looks like the app.config file is copied to the target directory as MyApplication.dll.config. My program runs fine and is able to use the default connection string.
Next I tried to edit the MyApplicaiton.dll.config file to change the connection string. I ran my program again, but it continued to use the default value. I noticed that in my Settings.Designer file there is a DefaultSettingValueAttribute with the original default string. I tried removing this attribute, but then when I tried to retrieve the connection string setting it just returned null.
This is the code I'm using to read the connection string.
string conn = Properties.Settings.Default.DbConnectionString
What am I doing wrong? How can I get it to return the value in the settings file and not the default value?
Update:
Sorry I should have mentioned this. I'm actually writing a plug-in for another application through a public API. So my project is a DLL not an EXE.
You cannot read settings from *.dll.config files. If you library needs any special settings you need to put them in your app.config or web.config files.
EDIT: You can include the external config files in the main application or web config file. Look here for details.
This question discusses how to manage configuration files for large projects.
Settings files and .config files are different things (I do not know why VS automatically added a .config when you created a Settings file). But, the settings file is compiled into a class and is referenced like you said. If you decompile the dll with .NET reflector the Settings class will be in there. It is used for holding constant values or external resources. For example: error message strings, icons, or images.
The config file is for settings which can change frequently or between environments (dev, test, prod). For a connection string you should use the <connectionStrings> section of the config file. And the property can be referenced using System.Configuration.ConfigurationManager[ "connectionStringName" ].
However, from your original post it looks like your .dll is going to be used in a larger project (either an .exe of web project). One thing to note is that all projects only use one .config file. And that is the config file for the main project. Websites the web.config file, and exe's use XXX.XXX.XXX.exe.config (as you saw, *.exe.config files are renamed copies of the app.config files). dll's do not have usable config files. All dll's will look at the main project's .config file to retrieve information.
If your connection string is never going to change then by all means use the Settings file. Otherwise, use a config file and let the developer of the main project determine what to populate the connection string with.
When I try and use code that makes use of the Enterprise Library Caching Block I get the following error:
The "cachingConfiguration" section is not available in the supplied configuration source.
The section is in my app.config file for that particular assembly though. If I copy the file into the unit test assembly that makes use of the afore mentioned code everything works. Is there any way that I can force it to use the app config that exists in the referenced library so I don't need to duplicate it in every assembly that makes use of it?
Yes.
Select an app.config file to be your master config file (a good choice would be the one in the project of the main application executable).
Now go to your other project (fx. the unit test project). Right-click and select Add Existing Item. Point to the master app.config file and add using the "As link" option:
Add as link http://blog.codevelop.dk/pics/AddAsLink.png
Now you only need to manage one app.config file, and the other projects will 'reference' this file.
Option 2: If you wan't to control what config file the Enterprise Library uses for caching configuration, use:
var fileSource = new FileConfigurationSource(configFilePath);
var factory = new CacheManagerFactory(fileSource);
ICacheManager manager = factory.CreateDefault();
The dll config file that you see in the IDE (if you are using the designer to add settings etc) is largely for convenience. The runtime won't look for it; it wants the file from yourexename.config. Some components provide the facility to specify a separate config file path - I don't know if this is the case for entlib.
Alternatively if you are spawning your own AppDomains you can specify the config file path. And finally some config sections can be referenced in from other files rather than using the file completely (see configSource here) - but in general (and especially for tests) it is easier to just copy the configuration section into the top-level app's config file (or the unit test's config file in this case).
I have a config file in my C# class library called MyLibrary.config, in vs 2008.
I created another project, say a simple console app, add reference by "Browsing" the MyLibrary.dll in the bin directory of the class library project, and when I compile, the MyLibrary.config is not including in the bin directory of the output in the console app.
How can I set it so I can include it when I reference the dll?
Cheers
You can't. Your console application is expecting to find a config file with prefix the same as the name as the console application (MyConsoleApplication.exe -> MyConsoleApplication.exe.config.).
In some situations you can share a config file by using the file attribute on the appSettings element:
<appSettings
file="path">
</appSettings>
Note that path is relative to the executing assembly.
As a side note, DLLs do not even use the config file that you've defined in the project. Again, configuration information is read from the a config file with prefix the same as the executing assembly. Thus, even when MyLibrary.dll tries to yank configuration information out of a config file, it will be reading the config file for the executing assembly, not MyLibrary.dll.config.
For more on how config files work, see MSDN.
The standard way to use a config file is to have it the same as the executable, adding a reference to a dll will not include its config file and as far as I know dll's don't load config files on their own, rather they rely on the executable that reference them.
Beyond not being able to do this, I would also advise against this approach.
Rather than trying to tighly couple your settings to the DLL library, consider more of a "Dependency Injection" type approach - i.e. where you pass in the value dependencies (i.e. settings) to the code you are calling (i.e. the library).
The advantage in this is you are not tied to a single method of storing settings. You can then use a database, different config file formats... even hard-coding. It also makes unit testing easier by removing the external file dependency.
There are different ways to implement this, however one example is to pass the configuration settings into the constructor of the class(s) that uses them.
I have a .NET 3.5 class library I built that reads an App.config file for values it needs. It can pull the config values just fine when I test it in Visual Studio. To test it, I just change the project to a console application and execute a method call.
I have the need to call this class library from many other .NET programs, and I want the class library to be self sufficient (I should be able to call it from any other program, and it should use its own config file, not know about any calling config file etc.).
I can add a reference to the dll (since I am still development I am using VS 2008, haven't thrown anything into the GAC yet) but the App.config that the class library is reading is from the calling program's App.config, not the class library's App.config.
The class library dll has it's config file in the same directory, so it should be able to find it just fine, and the calling application is named differently. I am using the standard key value pairs in the App.config (e.g. name of config file myClassLibrary.dll.config) and getting values out with the following line of code:
String myVal = ConfigurationSettings.AppSettings["myConfigSetting"];
Does anyone know how to fix this?
An app domain in C# can have only one assembly level app.config file. See here on MSDN. An executable will always start up an AppDomain and by default look for a config file with name: EXECUTABLE_NAME.config. For example, SampleApp01.exe will look for SampleApp01.exe.config as its configuration file.
you can place your configs in the machine.config file inside the framework folder by this way you can globally use your configuration in all .Net applications running in that machine,
I believe app.config will always be used by the executable. Just drop it in that directory.
They would do that to ensure the dll can be shared and not have to share the same .config file.
You might be able to create a link from the executable .config file
<appSettings configSource="\lib\app.config">
Or change its name, i don't understand how you can have both app.config files in the same directory..don't they have the same name?
<appSettings configSource="\lib.app.config">
I can't find a way to avoid getting the app.config for the calling dll/exe etc. The only way I have found is to use a hardcoded path and load it that way. Here is code I am using to do that:
using System.Configuration;
...
public static KeyValueConfigurationCollection getAppSettingsFromAppConfig(String appConfigPath) {
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = appConfigPath;
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
AppSettingsSection section = config.AppSettings;
KeyValueConfigurationCollection appsettings = section.Settings;
return appsettings;
}
You then have a collection of KeyValueConfigurationElement, which you can use .Value to get the string from config file with.