Saturday, August 13, 2005 5:59 PM Olaf Conijn

3 scenarios where your EntLib configuration might differ from one environment to another

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.

EnvironmentDatabase server
Development                               DevelopmentDB
Test  [same as on Development environment]
Staging StagingDB
Production ProductionDB

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.

# Supporting multiple configuration environments using the EntLib config tool

Tuesday, August 16, 2005 5:53 PM by Tom Hollander's blog

One of the more frequent questions I have heard about Enterprise Library is how to efficiently manage...

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Tuesday, August 16, 2005 8:05 PM by Phillip Jacobs

Olaf, This was an excellent description. I've been doing something similar for about a year now. The difference is that my solution stores it's settings in a database. It was a good read, Thanks!

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Tuesday, August 16, 2005 11:36 PM by Ramon Smits

Congratulations with the entlib announcement from Tom. Now it will get the attention it deserves.

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Wednesday, September 21, 2005 7:48 AM by Joe

Olaf,

Thanks for the work in developing this and I have a question. Maybe I'm missing it somewhere in the documentation (and it was eluded to in Tom's Entry @ http://blogs.msdn.com/tomholl/archive/2005/08/16/452431.aspx) and one of the primary benefits of your Override project but how do I have a shared Configuration File for all middle tier components? Do I need to create an App.config file for every business component and set the XML File Storage Provider for each component to the same directory or is there a more efficient way I'm missing here?

Thanks.

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Thursday, September 22, 2005 1:24 PM by Olaf Conijn

Joe;
The problem you have is different than the problem this add-in solves.

this overrides thing solves a potential problem when deploying 1 application to multiple servers.

I think you are looking for a solution to share 1 configuration file over multiple applications.

Lucky you, this is also possible with EntLib.

You can create a new ConfigurationContext around a .net configuration file stored somewhere else then your app's directory.

next you pass this ConfigurationContext to the appropriate overloads on the application blocks.

use
ExceptionPolicy.HandleException(ex, "Policy", ConfigurationContext)
instead of
ExceptionPolicy.HandleException(ex, "Policy").

use
new DatabaseProviderFactory(configurationCtx).CreateDefaultDatabase();
instead of
DatabaseFactory.CreateDatabase()

HTH,
Olaf

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Tuesday, September 27, 2005 10:28 AM by Joey

I must be missing something...I see teh folders created, but I don't get the database config or caching config specific for that environment...it is not created, just one database config and one caching config.

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Wednesday, September 28, 2005 11:38 AM by Olaf Conijn

Joey,

judging from your description this seems to be a bug of some sort. Could you email (press the contact link in the header of this page) me with a way to reproduce this behavior.

thanks

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Monday, October 10, 2005 9:01 AM by Joey

[quote]
judging from your description this seems to be a bug of some sort. Could you email (press the contact link in the header of this page) me with a way to reproduce this behavior.
[/quote]
Sorry for the slow follow-up, we froze our code to work on getting all documentation and guides done for a rollout today. So, I couldn't implement your component in this version of our application but it will happen next version :) The bug was a Joey bug...human error, just getting into the EntLib components so I missed a few _obvious_ steps.

Thanks again for your work on this. Notice an entry by one of the guys with the EntLib team, did you ever get interviewed?

# Estensioni per Enterprise Library January 2006

Thursday, February 02, 2006 7:54 AM by mauros@UGIdotNET

# Enterprise Library extensions drop 2: Return of the Environmental Overrides

Wednesday, March 15, 2006 12:19 PM by ^(?:[^$]*)$ --Matches everything, captures nothing

Environmental Overrides
The ‘Environmental Overrides’ extension is back and works with...

# Enterprise Library extensions drop 2: Return of the Environmental Overrides

Wednesday, March 15, 2006 12:25 PM by ^(?:[^$]*)$ --Matches everything, captures nothing

Environmental Overrides
The ‘Environmental Overrides’ extension is back and works with...

# Enterprise Library extensions drop 2: Return of the Environmental Overrides

Wednesday, March 29, 2006 3:50 AM by ^(?:[^$]*)$ --Matches everything, captures nothing

Environmental Overrides
The ‘Environmental Overrides’ extension is back and works with...

# How to set a particular environment for the application??

Monday, August 07, 2006 7:26 AM by Digs(Digant_Desai@ml.com)

This is with reference to your Environmental overrides.

Can you please tell me how to set paeticular environment for the application.

Say I want to set Environment as "Test" for my application so that I can use all variable set in config file under "Test" environment.

# re: 3 scenarios where your EntLib configuration might differ from one environment to another

Wednesday, August 09, 2006 9:45 AM by Asif

Hey Olaf,
The config overrides work great for me.
I had one question though. When I save the main config file all the other environmental files are created from scratch without the usual .NET config values. How can I make sure that all the other web.config values get copied over to the environment specific files as is?
Thanks