This project contains sample code that implements an Enterprise Library configuration source that stores configuration information in a Microsoft SQL Server database. It has been tested with SQL Server 2008, but should run without changes against 2005 or 2008 R2.
What's in the Package
This project is shipped as source code. It includes Microsoft Visual Studio 2008 .sln and .csproj files, that target the .NET Framework version 3.5 SP1. The compiled binaries will work with both .NET Framework 3.5 and .NET Framework 4.0 projects. Unit and integration tests, build and deployment scripts are also included.
You will need to have the following tools installed on your dev machine to compile the solution:
- Microsoft Visual Studio 2008 or Microsoft Visual Studio 2010
- Enterprise Library 5.0
In addition, if you want to compile and run the unit tests you will need to download a copy of the Moq mock object framework from http://moq.me. The code was built against Moq version 4.0.10827. Newer versions (if any) will probably work as well. Download the Moq binaries and unzip them into the Reference Assemblies\Moq4 folder. Be sure to maintain the folder structure inside the Moq zip file.
Behavior of the Configuration Source
The SqlConfiguration source supports a subset of the features the SystemConfigurationSource and FileConfigurationSource do.
READ THIS! Detailed Release Notes with instructions on how to customize, compile, test and deploy
- Only Enterprise Library configuration sections can be stored in the database. Other sections (for example, <appSettings>) will be stored in the physical configuration file, not the database.
- The <connectionStrings> section is treated specially. The contents of <connectionStrings> will be stored both in the configuration file AND in the database. If the two sections differ, Enterprise Library Data Access Block usage will use the settings from the database, while other data access will be pulling connection strings from the file.
- Hierarchical merging and redirected sections are not supported.
- The design assumes that a single application's configuration is stored in the database. If you wish to have multiple applications with different configurations stored in the same database, you will need to modify the code and / or database schema.
Update - 1/31/2012
Additional scripts are provided to create required database objects on a SQL Azure database (see SqlConfigurationSourcefor