Compartilhar via

SQL Configuration Source for Enterprise Library

  • Artigo

SQL Configuration Source for Enterprise Library 5.0 is now available. It allows storing configuration information in a database. It’s strengthened with encryption and change monitoring.

We are shipping this as source code here: https://entlib.codeplex.com/releases/view/56812

The project is set up to build against the signed binaries released with Enterprise Library 5.0. If you wish to compile against a different copy of Enterprise Library, please read the release notes for instructions on how to customize and deploy.

We also provide a batch file and SQL script to create the required database schema for you.

Do keep in mind that the SqlConfiguration source supports only a subset of the features the SystemConfigurationSource and FileConfigurationSource do.

  • Only EntLib-specific 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.

Comments

  • Anonymous
    March 26, 2012
    Hi Grigori, I have a simple question.  You say <appsettings> is stored still in the physical configuration file and not the database.  Is this a limitation of this implementation of the SqlConfigurationSource you have created or a limitation of the technology? Many thanks

  • Anonymous
    April 02, 2012
    Yes, Shumii, it's a limitation of our implementation. There was a trade off there, with two conflicting expectations: that app settings edited with the configuration tool could be read using the framework's ConfigurationManager.AppSettings property (msdn.microsoft.com/.../system.configuration.configurationmanager.appsettings.aspx), and that the settings were stored in the configuration source. We decided that the first requirement was more important, hence the current implementation.