Skip to main content

Configuration namespace and reading settings from the Configuration file,app.config,web.config

This one always catches me out.
There are a few different ways to read settings in from a .config file.
The confusion for me occurs when reading from certain sections and from config files other than ones for the currently running application.

The easiest example is reading settings from the currently running application, from within it's own code.
You can access the AppSettings Section
<configuration><appSettings>
<add key="hostname1" value="localhost"/><add key="hostname2" value="othername"/></appSettings></configuration>
using:

NameValueCollection appSettings = ConfigurationManager.AppSettings;
foreach(string key in appSettings.AllKeys)
Console.WriteLine(key + " " + appSettings[key]);

So now you've all the keys in the AppSettings section i.e. "hostname1" and "hostname" and all their values accessed with appSettings[key].
Note: First you must add a reference to 'System.Configuration.dll' to your project and also include the namespace 'using System.Configuration;' You'll also need 'using System.Collections.Specialized;' in order to use the 'NameValueCollection' type.

Similarly but slightly more tricky you can access the settings of another assembly by using the following:

Configuration config = ConfigurationManager.OpenExeConfiguration(@".dll");
KeyValueConfigurationCollection kvpCollection = config.AppSettings.Settings;
foreach (string key in kvpCollection.AllKeys)
Console.WriteLine(key + " " + kvpCollection[key].Value);


You'll see the Settings collection is access in the same way and can be enumerated in the same way but the 'value' of the AppSetting must be accessed using the .Value property?
This is because the former call to AllKeys returns a NamedValueCollection and the latter returns a KeyValueCollection, this means that for one you have access to the values as strings themselves and the other you have access to the type KeyValueConfigurationElement, if you want to get the string value you additionally need to call the Value property!



Open a config for a dll, a dll being referenced by an exe

This reads the config file that's in the location that the exe is referencing the dll from, actually it makes a copy of the dll to the exes bin dir, so you have to add your dll's config file to the exe's bin directory and withing the dll's code add the following

//Only finds copy of the assembly as it's added as a reference to the exe.
System.Reflection.Assembly ass = System.Reflection.Assembly.GetAssembly(typeof(Class1));
System.Reflection.AssemblyName assName = ass.GetName();
string codeBase = assName.CodeBase;
int length = "file:///".Length;//remove the "file:///" from the string
string result = codeBase.Substring(length);
config = ConfigurationManager.OpenExeConfiguration(result);//open the dll's config
kvpCollection = config.AppSettings.Settings;
value = kvpCollection["hostname1"].Value;

Comments

Popular posts from this blog

dotNET - Debugging

Debugging with .NET MSIL assemblies Visual Studio and debugging the CLR are different, I'll talk about both. MSIL Assemblies Assemblies compiled with .NET tools such as the CLR compiler are compiled into a file which contains MSIL (Microsoft Intermediate Language). At runtime the contents of the assembly are loaded into the CLR and ran as machine code. When you compile an assembly in debug a PDB file is generated alongside the DLL or EXE you've just created. The link between these 2 files is that the PDB contains the line numbers of the methods and classes as well as the file names of the original source code that created the assembly. When you launch the debugger in Visual Studio the assembly is loaded into the Debugger (similar to the CLR) along with the PDB file. The debugger now uses your PDB file contents to match the running code found in the assembly to locations in source files (hopefully in your present project). CLR CLR Inside Out (msdn magazine) .NET Framework Tools:...

Installer CustomAction, Debugging the CustomAction, InstallState

Custom Action The Custom Action is added to the Setup Project, select the Project node and hit the Custom Action button. This allows you add an Action to a particular phase in the Installation. But first you must create the Custom Action. To Add a Custom Action you must first have a Custom Action created, this is usually in the form of a Installer Class, this should be created in a seperate project, the Installer Class is actually one of the File Templates in the C# Projects. So it's File->New Project and select Visual C# Projects. Then add a Class Library, this will prompt you for the Class Library Types , select "Installer Class". Walkthrough - Creating Custom Action (msdn). Also here's a more comprehensive document on Setup/Installer implementations, it delves into the Registry etc Getting Started with Setup Projects (SimpleTalk). Visual Studio Setup Projects and Custom Actions (Simple Talk). Create your Installer Class and then add it as a Custom Action to the ...

dotNET - Use app.config ApplicationSettings and UserSettings

When using Settings in an Assembly or .exe you can use the Settings Designer to generate a config file using Settings. The Settings Designer provides a wrapper class which allows you to provide defaults and access the config data using Properties. But what if you're not working inside that Assembly or .exe? this presents a problem. If your loading the Assembly externally and want to access that Assembly's .config file you'll probably wish to use something in the System.Configuration namespace... unfortunately it's not of much use if you've created the .config file from the Settings Designer in Visual Studio!! This is because the Designer creates Sections and ApplicationSettings and UserSettings, the System.Configuration namespace does not provide a method to access these (it has a method to access AppSettings which are a different thing. Below I've written a workaround which locates the app.config and accesses the ApplicationSettings and UserSettings using XML i...