Tuesday, December 22, 2009
Friday, December 18, 2009
Thursday, December 17, 2009
Wednesday, December 16, 2009
Using the File attribute of the appSettings element of a .NET config file
If you need to share configuration settings among multiple .NET assemblies, the practice of maintaining separate config files for each assembly can quickly become tedious. For instance, if you have multiple executables within a directory that all need a 'ConnectionString' entry in their config file, the traditional method in .NET would be for each executable to have its own config file. This can become a burden in an enterprise environment when you need to change the connection string, as you would be forced to change each individual config file. Fortunately, there is a better approach. This better approach involves using the File
attribute of the .NET config file's appSettings
element. This attribute should contain the relative path to a custom config file, which all other applications can share. The description from MSDN on the appSettings
File
attribute follows:
Specifies a relative path to an external file containing custom application configuration settings. The specified file contains the same kind of settings that are specified in the
<add>
,<remove>
, and<clear>
elements and uses the same key/value pair format as those elements. The path specified is relative to the main configuration file. For a Windows Forms application, this would be the binary folder (such as /bin/debug), not the location of the application configuration file. For Web Forms applications, the path is relative to the application root, where the web.config file is located.
Note that the runtime ignores the attribute if the specified file can not be found.
Essentially, each executable's config file will contain an entry such as:
xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings file="settings.config"> </appSettings> </configuration>
where "settings.config" is a custom config file which looks something like this:
<appSettings> <add key="Setting1" value="This is Setting 1 from settings.config" /> <add key="Setting2" value="This is Setting 2 from settings.config" /> <add key="ConnectionString" value="ConnectString from settings.confg" /> </appSettings>
When you run your application, you simply use the AppSettings
property from System.Configuration.ConfigurationSettings
to reference the configuration setting, such as:
Dim s As String = _ System.Configuration.ConfigurationSettings.AppSettings("ConnectionString")
In this case, if there is a 'ConnectionString
' key in the individual config file, that value will be used. Otherwise, the value will be retrieved from the shared "settings.config" file.
As indicated above, if you choose, each individual config file can also define the keys which are present in the shared config file. In that case, the individual config file settings will take precedence over the shared config file. That could be useful in a situation where you want to quickly test a new setting without disrupting the other applications which are using the shared config file.
Monday, December 14, 2009
The Human’s Guide To Running Google Chrome OS
By Gina Trapani on December 3, 2009 at 4:00 AM
Two weeks ago Google released the source code of their upcoming Chrome OS operating system, and thanks to some fast and hard-working developers, you don’t have to be a coder to try it out.
While Google’s official word is that you have to build Chromium OS from source to try it out on your computer, several developers have released installable builds that save you the trouble. Let’s take a look at how to take Chromium OS out for a spin without typing make or build."
Friday, December 11, 2009
Hosting WCF Services (Very nice article)
Windows Communication Foundation (WCF) Services can be hosted with Internet Information Services (IIS); with the new Windows Activation Service (WAS) installed with IIS 7.0; or with any managed application process including console, Windows Forms, Windows Presentation Foundation (WPF), or managed Windows service applications. Selecting the right hosting environment for your services is a choice driven largely by deployment requirements related to transport protocol and operating platform."