Enterprise Library 5.0 Sql Configuration Source
Source: Enterprise Library 5.0 - SQL Configuration Source
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
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.
Compiling the Source
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.
Running the Tests
The tests are written using the Microsoft MSTest testing framework, and require at least the Pro SKU of Visual Studio.
In order to run the tests, you will need a local copy of Microsoft SQL Express 2008. You will need to run the CreateTestDb.cmd
batch file in the Scripts
directory to set up the test database. If you wish to use a different database for your tests, the connection strings used can be changed in the SqlConfigurationSource.Tests\TestSupport\TestDbStrings.cs
Customizing the Version of Enterprise Library to Build Against
The project is set up to build against the signed binaries released with Enterprise Library 5.0. The Enterprise Library assemblies should be automatically found by Visual Studio. There are cases where you may wish to compile the SqlConfigurationSource against a different Enterprise Library binary. For example, perhaps your organization maintains its own copy with local modifications.
If you wish to compile against a different copy of Enterprise Library, copy that version of the Enterprise Library DLLs into the ReferenceAssemblies\Entlib5
folder in the source tree. Visual Studio will pull the assemblies from there instead of from the installed Enterprise Library folder.
You may run into issues with assembly versions not matching. If you do, edit the project files and change the "Specific Version"
property for the references to the Enterprise Library DLL's from "True"
Deploying the Binaries
After compiling the project, you end up with a single DLL, Microsoft.Practices.EnterpriseLibrary.SqlConfigurationSource.dll
. This file can be found in the SqlConfigurationSource\bin\Debug
folder and is also copied to the ReferenceAssemblies\Entlib5 folder
as part of the build process. This DLL is not strong-named or authenticode-signed; if your environment requires signed binaries you must sign it yourself.
Deploying the binary is straightforward. For configuration tool use, put the Microsoft.Practices.EnterpriseLibrary.SqlConfigurationSource.dll
in the same directory as the configuration tool .exe file. It will appear as an option in the Add Configuration Source
menu in the Configuration Sources
section in the configuration tool.
Using the configuration source at runtime is equally simple; just deploy the Microsoft.Practices.EnterpriseLibrary.SqlConfigurationSource.dll
file alongside your other binaries. There's one thing to be aware of, it's very common to simply add a binary reference from your project that uses Enterprise Library to the SqlConfigurationSource DLL. If you do this, you'll see that Visual Studio will copy all the binaries of Enterprise Library into your build directory. This happens because the SqlConfigurationSource dll references the Enterprise Library design time DLL, which references every other Enterprise Library DLL. However, at run time you don't need /any/ of these DLLs, just the ones you're actually using.
To repeat: Just because Visual Studio copies all the Enterprise Library DLLs into your build directory does not mean you need to deploy them all to your production system
. You only need to deploy the core Common
DLL, the SqlConfigurationSource
DLL, and the DLLs for the blocks you're actually using.
Deploying the Database
The project ships with a batch file and SQL script, CreateConfigDb.cmd/.sql
, in the Scripts
directory, that can create the required database schema for you. It consists of a single table storing the configuration data itself, and a set of stored procedures. The table is not referenced by the production code, all access is through the stored procedures. Run CreateConfigDb /?
at the command prompt to see the options for specifying the database server and database name.
The stored procedures that are required by the SqlConfigurationSource are:
- dbo.Entlib_GetSectionByName - Returns the data about a section
- dbo.Entlib_WriteSection - Writes a section's information (or updates one that's already there) to the database
- dbo.Entlib_DeleteSection - Deletes a section from the database
- dbo.Entlib_GetCurrentRowVersion - Gets a value that determines the current state of the database (used for change polling)
- dbo.Entlib_GetUpdatedSections - Gets any sections that have changed since the given version
If you wish, you may change the implementation of these stored procedures. The names of the stored procedures are given in the SqlConfigurationSource\Sql\SprocNames.cs
file if you wish to change the names.
Behavior of the Configuration Source
The SqlConfiguration source supports a subset of the features the SystemConfigurationSource
- 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.