In addition to my last post where I introduced an EntLib ConfigurationConsole plugin called ‘EnvironmentalOverrides’, I would like to present some scenario’s where you might find this particularly useful. I also would like you to tell me where you would like to use this plugin for!
All examples require you to have the plugin downloaded, compiled and placed in the Enterprise Library’s bin directory. Next you should add the ‘Environmental Overrides’ node to your application by right-clicking your application, choose ‘new’ -> ‘Environmental Overrides’.
The plugin will add 3 environments by default (Test, Staging and production), the settings you enter directly in the configuration console will apply on your development environment. Environments can be added/removed or renamed, on the ‘Environmental overrides’ node under the application node.
Please note that the plugin creates different subdirectories per environment (in the image above, the subdirectory for the production environment is 'PRO'), each containing a complete set of .config files. Distribution of the configuration files is beyond the scope of the plugin. Typically a buildserver should take care of packaging the different configuration files into separate distributions.
First scenario: Your application uses different database servers on your production and staging environment
Your application uses databases, though the production database is fit for development and debugging purposes. Hopefully it is not even accessible by you, from your development environment. Every environment has its own connectionstring to the database, in this example it the “server” property is different for both the production and staging environment, the test environment is configured to use the same server as your development environment.
||[same as on Development environment]
This would look like the following in the EntLib configuration console
The value property for the 'Test environment' is grayed out and kept in sync with your configurations default (the development environment).
Second scenario: Your application uses the Caching application block, which you would like to disable on your development environment
Caching is a good thing… on production environments! It pretty much gets in your way when someone is testing your application. Ever heard yourself say: “Err…. It might be the cache you are looking at…. Why don’t you keep trying the following 300000 milliseconds?”?
The thing you might want to do is disable caching on your development and testing environment and only cache your production and staging environments. This is done by setting your ‘cache managers’ properties to do minimal caching by default and overriding the values with the actual onces for the production and staging environments.
Third Scenario: You are required to encrypt database settings on the production environments
Lucky you! Entlib can encrypt any application blocks settings out of the box. Even though you agreed to comply with this requirement, you might want to be able to edit the configuration file from any text editor on your development machine.
Add a new key/algorithm pair to your encryption settings (under the ‘Configuration Application Block’) as you would do normally. Next, select the ‘dataConfiguration’ section (just above) and leave the main ‘Encrypt’ value to ‘false’. Override the production environments settings and for the ‘Encrypt’ property, choose false.
Next you should encrypt all copies of your ‘EnvironmentConfig’ section (again under ‘Configuration Application Block’). This is because for all overridden settings, the values are stored in this configuration file.
If you failed to add a key/algorithm pair to you’re the encryption settings, this will raise a configuration error trying to save the configuration on your development environment already. Pretty convenient, huh?
Good luck playing around with the plugin! if you used the plugin for less common scenarios, please share your experiences.