{
A while back I complained about configuration within Windows Forms applications, mostly because I lacked an understanding of the API. I hacked a simple xml file together wherein I could store simple name value pairs that we'd utilize for the application and surprisingly it's been the approach for quite some time.
I've been studying for the Microsoft 70-552 exam which would update my "MCAD" certification to "MCPD." I know, I know, certification is frown upon by so many people who think I should really be reading The Little Schemer to do cool parlor tricks. But this is a case where what I'd said earlier about certification rings true: it probes for weakness and exposes where you "fake it" with hacks without understanding the real structure and purpose of the technology. Case in point, configuration.
In my earlier post, I'd used Configuration.AppSettings which I now know as deprecated. Instead there's a nifty configuration/settings API one can leverage. What I've done here is based very heavily on Chris Sells's Windows Forms 2.0 Programming although I took liberty to modify some of the code to make it more reusable and generic (his intent was to show basics).
The first stop one needs to make is to add a Settings file to the project along with a reference to System.configuration (not sure why configuration is not Configuration).
Underneath the properties node if you "edit" the settings file, it's really a grid that allows you to enter settings with a key, datatype, scope, and value. The scope in here can be either as a user setting or an application setting - it's also possible to write your own section handler and extend the model.
After compiling this is converted into your app.exe.config file - the physical storage of your settings in the xml format well know to config files.
The code for retrieval is still, in my own view, a little verbose but it's easy to develop a simple accessor helper class. Even more slick in the design of the .NET Framework is that class library projects (DLLs) pull configuration settings from their hosted EXE so you the utility code here is from a DLL designed to be referenced and used from any application.
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
namespace SettingsGroperLib
{
public enum SettingType {
userSettings,
applicationSettings
}
public class ConfHelp
{
public static string GetConfSetting(SettingType settingType, string settingKey) {
// obtain current configuration
Configuration currentConfig =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// obtain section utilizing enumeration
ConfigurationSectionGroup group =
currentConfig.GetSectionGroup(settingType.ToString());
// get calling assembly settings class
string assemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
// yah, it's ugly, but it works
string friendlyName = assemblyName.Split(',')[0];
// obtain section by combining friendlyname to settings class
ClientSettingsSection section =
(ClientSettingsSection)group.Sections.Get(
String.Format(
"{0}.Properties.Settings",
friendlyName
)
);
// get setting key
SettingElement element =
section.Settings.Get(settingKey);
// return settings value as
return element.Value.ValueXml.FirstChild.Value;
}
}
}
Sorry about the format; you can download a nice formated version here.
It all seems so easy once you take the time. I think the unlearning was a big obstacle for me since working with config files was something I did all the time in .NET 1.x and old habits die hard. Oh yeah, the retrieval:
string test = ConfHelp.GetConfSetting(SettingType.applicationSettings, "DBUrl");
}
A while back I complained about configuration within Windows Forms applications, mostly because I lacked an understanding of the API. I hacked a simple xml file together wherein I could store simple name value pairs that we'd utilize for the application and surprisingly it's been the approach for quite some time.
I've been studying for the Microsoft 70-552 exam which would update my "MCAD" certification to "MCPD." I know, I know, certification is frown upon by so many people who think I should really be reading The Little Schemer to do cool parlor tricks. But this is a case where what I'd said earlier about certification rings true: it probes for weakness and exposes where you "fake it" with hacks without understanding the real structure and purpose of the technology. Case in point, configuration.
In my earlier post, I'd used Configuration.AppSettings which I now know as deprecated. Instead there's a nifty configuration/settings API one can leverage. What I've done here is based very heavily on Chris Sells's Windows Forms 2.0 Programming although I took liberty to modify some of the code to make it more reusable and generic (his intent was to show basics).
The first stop one needs to make is to add a Settings file to the project along with a reference to System.configuration (not sure why configuration is not Configuration).
Underneath the properties node if you "edit" the settings file, it's really a grid that allows you to enter settings with a key, datatype, scope, and value. The scope in here can be either as a user setting or an application setting - it's also possible to write your own section handler and extend the model.
After compiling this is converted into your app.exe.config file - the physical storage of your settings in the xml format well know to config files.
The code for retrieval is still, in my own view, a little verbose but it's easy to develop a simple accessor helper class. Even more slick in the design of the .NET Framework is that class library projects (DLLs) pull configuration settings from their hosted EXE so you the utility code here is from a DLL designed to be referenced and used from any application.
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
namespace SettingsGroperLib
{
public enum SettingType {
userSettings,
applicationSettings
}
public class ConfHelp
{
public static string GetConfSetting(SettingType settingType, string settingKey) {
// obtain current configuration
Configuration currentConfig =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// obtain section utilizing enumeration
ConfigurationSectionGroup group =
currentConfig.GetSectionGroup(settingType.ToString());
// get calling assembly settings class
string assemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
// yah, it's ugly, but it works
string friendlyName = assemblyName.Split(',')[0];
// obtain section by combining friendlyname to settings class
ClientSettingsSection section =
(ClientSettingsSection)group.Sections.Get(
String.Format(
"{0}.Properties.Settings",
friendlyName
)
);
// get setting key
SettingElement element =
section.Settings.Get(settingKey);
// return settings value as
return element.Value.ValueXml.FirstChild.Value;
}
}
}
Sorry about the format; you can download a nice formated version here.
It all seems so easy once you take the time. I think the unlearning was a big obstacle for me since working with config files was something I did all the time in .NET 1.x and old habits die hard. Oh yeah, the retrieval:
string test = ConfHelp.GetConfSetting(SettingType.applicationSettings, "DBUrl");
}