I have seen lots of posts from people in the newsgroups trying to figure out what the deal is with the new config options in .net 2.0.
The main reason people run into problems is due to MS making a number of changes, including changes between the beta and the RC product, resulting in different answers based on how early you encountered the issues.
You can still do things the way you did with .Net 1.x.
<add key=“MyKeyName“ value=“somevalue“/>
and then you can access it with:
Dim myvalue As String = System.Configuration.ConfigurationSettings.AppSettings.Item(“ConnectionString”)
However, if you try this, VS.Net will warn you:
This method is obsolete, it has been replaced by System.Configuration!System.Configuration.ConfigurationManager.AppSettings
It is important to note that the “!” above indicates that the fully quallified class listed, is located in the System.Configuration assembly, which of course you have to add to your project.
So unlike previous versions, you need to manually add a reference to System.Configuration in order to make this new call.
Now, .net 2.0 and vs.net 2005 have teamed up to offer a new option for storing user settings which may seem more complicated at first if you don’t know exactly what you are doing. In the project properties you can select a “Settings” tab where you are able to modify application settings, which are in turn stored in app.config. These settings can either be “User” settings, or “Application” settings.
Application settings are stored in the app.config (or web.config), and are read-only. User settings have a default value that is stored in the app.config, but your application can overwrite these default values as needed, and the users settings will be stored in:
%USERPROFILE%Local SettingsApplication Data<Company Name><appdomainname>_<eid>_<hash><verison>user.config. (non roaming)
%USERPROFILE%Application Data<Company Name><appdomainname>_<eid>_<hash><verison>user.config (roaming)
The other nice feature of the 2.0 way of accessing these settings is that the settings are saved as a specific type from a wide collection of available types (String, System.DateTime, System.Drawing.Color, System.Guid, Bool, StringCollection etc) and when you access them from your code they are available in intellisense.
This may seem like it isn’t important, but it means you can’t mistype a setting key, or accidently try an invalid cast from one of your settings. Also, storing a collection was a real pain in 1.x. Now you can create a collection quickly and it will be added to the user settings like this:
<setting name=“MyCol“ serializeAs=“Xml“>
<string>I am first</string>
<string>I am number four</string>
To access these properties you have 2 different ways depending on if you are using VB.Net or C#.
For VB.Net you use the “My” namespace and access it like this:
Dim mySetting As String = My.Settings.MySetting
For C# you access these settings through the “Properties” object
string mySetting = Properties.Settings.Default.MyUserSetting;
Thanks man!! this example helped me to go one step forward in my vs2005 journy.
No problem, thanks for the comment.
I read lot of app.config google results, yours made the sense.
Thanks. I had spent some time trying to directly change the web.config file and auto complete wouldn’t pick up the reference. After reviewing this, I change the project settings, it automatically added it to the web.config and i was done.
No problem Joe. Thanks for leaving the comment.
Nice! Why couldn’t anyone else explain it so clearly! So frustrated, was i, at the change from appSettings to applicationSettings that i wrote my own deserializing logic to read settings, i can now go back to settings files. Thanks.
Dave, thanks for the comment.
Someone must be linking to this article because I have been getting a lot of comments on this post lately.
Glad to help.
But how does one get the array of strings read out of the settings file in order to use in the application?
Thanks. Good Article. Save me lot of trouble.
If you put a Connection String (as a type) in My Settings this will automatically go in as an Application setting, and you cannot change it, which then means, you cannot modify it – as in when your user installs and sets up your software! This has always baffled me – why give us a type of Connection String and then presume we would know the connection string BEFORE the software has even been purchased, let alone shipped to the user???
The only way we have found to modify (just after install) is to copy, and re-write the entire app.config file. When I read through Microsoft’s own documentation on this, I was stunned to find lots and layers and layers of complexity – but this simple thing, not addressed.
Did I miss something? Are we all connecting to the same SQL database these days?
This entire overly complex configuration stuff makes me long for the days of simple INI files. But yeah, I know those days are long gone – still, I have a legacy app I have to support and cannot re-write – so how the heck do I deal with this other than constantly re-writing app.config anytime a SQL connection string changes?
Simple? Thats what MS says… But these are guys who bend over backwards to tie their shoes… I dont consider that, or this stuff all that simple…
Thanks for your article none the less.