question about WinForm projects, System.Configuration.ConfigurationManager,and Connection Strings

[kellygreer1]

Does anybody know why you have to add the reference to
System.Configuration.dll to able to access the
System.Configuration.ConfigurationManager object? I use this to get at
Connection Strings.
If the older methods are deprecated, why isn't this a standard part of
WinForm projects? Just curious.

Thanks,
Kelly Greer
(e-mail address removed)
Replace nospam with yahoo

 

[Morten Wennevik [C# MVP]]

Does anybody know why you have to add the reference to
System.Configuration.dll to able to access the
System.Configuration.ConfigurationManager object? I use this to get at
Connection Strings.
If the older methods are deprecated, why isn't this a standard part of
WinForm projects? Just curious.

Thanks,
Kelly Greer
(e-mail address removed)
Replace nospam with yahoo

Hi Kelly,

Without knowing this for sure, my guess is that you don't really need it
unless you absolutely want to do it the "old fassioned way". The Settings
file wraps configuration in a typesafe way and is an easy way to manage
application/user settings, including connection strings.

Try adding a Settings file and add a setting of type connection string.
your app.config/web.config should update itself with the appropriate values
when you save the settings.

 

[kellygreer1]

Hi Kelly,

Without knowing this for sure, my guess is that you don't really need it
unless you absolutely want to do it the "old fassioned way".  The Settings
file wraps configuration in a typesafe way and is an easy way to manage
application/user settings, including connection strings.  

Try adding a Settings file and add a setting of type connection string.  
your app.config/web.config should update itself with the appropriate values
when you save the settings.

I guess I'm confussed...
Even the latest Linq-to-SQL DBML stuff puts your Connection String in
the <connectionStrings> tag.
The same way that Typed DataSets and ASP.NET SqlDataSource Control
"wizards" do.
Heck, even the Enterprise Data Library from the Microsoft Patterns and
Practices group uses the <connectionStrings> tag.
How is this "old fashioned"?

More info:
http://blogs.x2line.com/al/archive/2005/11/06/1304.aspx
Lowercase "c"... Negative 10 cool points.

Thanks,
Kelly

 

[Morten Wennevik [C# MVP]]

I guess I'm confussed...
Even the latest Linq-to-SQL DBML stuff puts your Connection String in
the <connectionStrings> tag.
The same way that Typed DataSets and ASP.NET SqlDataSource Control
"wizards" do.
Heck, even the Enterprise Data Library from the Microsoft Patterns and
Practices group uses the <connectionStrings> tag.
How is this "old fashioned"?

More info:
http://blogs.x2line.com/al/archive/2005/11/06/1304.aspx
Lowercase "c"... Negative 10 cool points.

Thanks,
Kelly

I may have expressed myself somewhat unclearly. The application
configuration file and its content, including connection strings is not at
all old fassioned, and is a vital part of .Net Framework functionality. What
I meant is with the Settings file, you can wrap the contents of the
configuration file on a type safe manner. If you add settings to the
Settings file an app.config or web.config file will be created if you haven't
done so already. The settings will be stored inside the configuration file,
but the Settings file lets you access these settings with intellisense and
type support.

Typically you would do something like this at a windows client startup

this.BackColor = Settings.Default.UserPreferredBackgroundColor;

where UserPreferredBackgroundColor is the name of the setting in the
Settings file and the app.config will look like

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="userSettings"
type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="WinTest.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<userSettings>
<WinTest.Properties.Settings>
<setting name="UserPreferredBackgroundColor" serializeAs="String">
<value>Yellow</value>
</setting>
</WinTest.Properties.Settings>
</userSettings>
</configuration>

You may notice userSettings instead of the usual appSettings section. This
means when this setting is changed at runtime a user.config file will be
created in
C:\Documents and Settings\<user>\Local Settings\Application
Data\WinTest\WinTest.exe_Url_<guid>\<version>. So user preferences can be
stored very easily and exclusively per user. Application settings are
created the same way but cannot be changed at runtime.

Settings.Default.UserPreferredBackgroundColor = Color.Red;
Settings.Default.Save();

The Settings file takes care of the setting type and makes it unecessary to
cast to/from System.Object, and as mentioned you get intellisense support and
all settings listed when you type Settings.Default. (You may have to add a
using <namespace>.Properties if you use the default settings file).

Likewise do you have connection string support. By adding a settings key
with the type (connection string) you get Connection Properties support to
create the connectionstring or you can type any connection string as you
like. the app.settings file will get updated with a connectionStrings section

<connectionStrings>
<add name="WinTest.Properties.Settings.DBConnection"
connectionString="Data Source=localhost;Initial
Catalog=AdventureWorks;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>

You also get Settings support across projects although you may have to
manually add the appropriate section to the primary project's app.config.
The name of the sections and keys includes the project name.

This is usually all the configuration you need, making it unecessary to
manually read the configuration file using ConfigurationManager and
ConfigurationSection.