Connection Strings and Configuration Files

Sometimes you might see a variation of the service provider design that provides its connection string as a property or requires the connection string in its constructor. This design might seem like a good idea because it allows flexibility for the data access class to be used with different data sources or login information. However, this approach also creates its share of problems:

• It introduces one more area in which the component will be susceptible to client mistakes.

• It introduces one more area where security can be compromised because each client will need to know the database user ID and password.

• It can threaten connection pooling because minor changes in the connection string result in the creation of new pools, even if the string is still functionally equivalent.

Essentially, this approach infringes on the responsibilities of the data access class, which is designed to encapsulate all database-specific details. It also breaks the component's contract. In other words, the data access component can't guarantee that it will provide reliable database access if it can't be sure that the connection string is correct.

For all these reasons, it's usually best to place the connection string in the component itself or in a configuration file that it reads from the same directory. The configuration file approach is often the preferred one because it enables you to modify the connection string without recompiling the component. However, you might also need to take extra steps to secure the configuration file, which could otherwise be read by a client on the network (although you won't need to worry about Internet access because ASP.NET automatically handles HTTP requests for .config files and rejects them).

Every .NET application can have an associated configuration file in one of two locations:

• If you're creating a Web page, a Web service, or a component hosted in an ASP.NET application, the configuration file is always named web.config and is located in the virtual directory of your application.

• If you're creating any other type of application, the configuration file must be in the same directory as the executable and will have the same name as your application, plus the extension .config. Therefore, if your application has the executable file name myapp.exe, you can create a configuration file named myapp.exe.config that .NET will process automatically when the application is launched.

The configuration file can contain a great deal of additional information. Later in this chapter, for example, we'll consider the settings it contains for resolving assembly references. Custom settings, such as a connection string, are always added to a configuration section called <appSettings>. Every custom setting has a string value and a unique string key that identifies it. You define both in the configuration file.

In the following configuration file, for example, a setting named ConnectionString is added to the application. The connection string itself is split over two lines due to space constraints.

 <?xml version="1.0"?> <configuration>   <appSettings>     <add key="ConnectionString"          value="Data Source=MyServer;Initial Catalog=MyDb;Integrated                 Security=SSPI" />   </appSettings>   <!-- Other configuration sections can go here,        but aren't necessary. --> </configuration> 

Note

The configuration file is written in XML. In XML documents, white space is collapsed (although this doesn't include the text in between quotation marks, which is why the connection string value must be placed on one line.) You can't use Visual Basic syntax (for example, using the ampersand [&] to join strings or the underscore [_] to indicate a line break) because it has no meaning in XML. XML also defines a format for comments. In the preceding example, the text note Other configuration sections can go here... will be ignored because it is enclosed in XML comment markers.

You can retrieve custom settings in the constructor method for the component using the System.Configuration.ConfigurationSettings class. This class provides a shared property called AppSettings, which is a key/value dictionary exposing all the custom configuration settings. Here is the new constructor code for the CustomerDB class, which retrieves the connection string setting from the configuration file:

 Public Sub New()     ' Retrieve the connection string and store it in the     ' private member variable.     _ConnectionString = ConfigurationSettings.AppSettings( _                          "ConnectionString") End Sub 

Note that this example assumes you've imported the System.Configuration namespace and therefore don't need to type the fully qualified name for the ConfigurationSettings class. Remember, you don't need to access the file directly by specifying a filename or a directory path. Configuration files, if they have the correct name and are located in the correct directory, are recognized and made available by .NET automatically.

Configuration files are favored over other methods of storing settings because they are never locked and can therefore be edited at any time. Configuration files are also convenient because they are tied to a particular directory, not a particular computer (as a registry setting would be). Therefore, if several clients load the same application from the same directory, they will share the same single connection string setting.

In some cases, depending on the deployment you use, a configuration file might give the client too much opportunity to modify the connection string and you might need to compile it directly in the class (as shown earlier) or retrieve it from a Web service.

Note

One potential caveat with configuration file settings is that they are associated with the host application, not the component assembly. In a simple scenario where a Windows application uses a local component, you must add any configuration settings to the configuration file for the Windows application. If you're creating a component that uses .NET Remoting, you need to add settings to the configuration file used by the server-side hosting program. Finally, in the case of a Web service, configuration settings must be entered in a web.config file in the corresponding virtual directory.

Configuration Files in Visual Studio .NET

When you create a Windows project with Visual Studio .NET, a configuration file won't be created automatically. However, you can easily add one. Just right-click on the project in Solution Explorer and choose Add, New Item. Then choose Application Configuration File under the Utility node (as shown in Figure 2-3).

Figure 2-3. Adding a configuration file to a project

The application configuration file is automatically assigned the name app.config. You shouldn't change this name. When Visual Studio .NET compiles your project, it creates the configuration file in the appropriate directory, with the correct name. This enables you to rename your executable without needing to alter the configuration file. If you want to see the configuration file for yourself, choose Project, Show All Files from the menu. When you compile your project, you'll see the appropriate file appear in the Bin directory (as shown in Figure 2-4).

Figure 2-4. The automatically generated configuration file