EntLib 6 suggests using Programmatic configuration but does this not prevent changes without recompiling?

Topics: Exception Handling Application Block, Logging Application Block
May 15, 2013 at 12:44 PM
Just a little background first, I've known of the Enterprise Library in previous versions but found that it looked quite complicated and appeared to be quite a large dependency for an app when I was only interested in the exception handling and logging.

I decided to come back to it because I want to find a consistent way to deal with exception handling in a new application I'm writing. At this point I've found out that EntLib 6 has been released and appears to improve the library a lot.

Short version:

Is using programmatic configuration going to require recompiling and redeployment of an app to change things like exception handling policies?

Long version:

I'm currently reading the Reference Docs that can be downloaded here. In the section 'Configuring Enterprise Library' (in 'Developing Applications with Enterprise Library') it states this:

"The recommended approach is to use the new programmatic configuration approach"

A common theme with the EntLib is that it allows you to change things without affecting the rest of your application code, so the exception handling block allows changes there that affect the applications way of handling exceptions.

In the section 'Administering Enterprise Library' (In 'Developing Applications with Enterprise Library') it has a part titled 'Changes to the Run Time Environment ' that states the following:

"The flexibility and configurability of Enterprise Library makes it easy to change the behavior of the application without requiring redeployment"

that part continues to talk about configuration files and that makes sense since you could change them without needing to recompile or redeploy your applications. But if the new recommended method is to use programmatic configuration I don't see how it would be possible to change the configuration without recompiling and redeploying.

Can anyone help me to understand this issue please?

I'm going to continue reading the docs to see if I can figure this out but I thought I would start a discussion to see if someone can easily point me to the right part of the documentation to explain this. This blog post states that a reference implementation and further documentation will be available this month, maybe that will help to answer this question.
May 15, 2013 at 6:08 PM
The short answer to your question is that "documentation is preliminary and subject to change". :) So perhaps, in the final release this can be clarified.

You are right, of course, that if you are using programmatic configuration then you cannot change the behavior of the blocks without recompiling and deploying. The docs also say "you should review your requirements to determine which configuration approach is most suitable for your specific scenarios". So, if you are already using XML configuration or feel that the need for the flexibility of configuration that can be easily changed without deployment is important then using XML configuration is probably the best approach. That said, I've seen many situations where misconfiguration in production has caused issues. Also some blocks, such as Exception Handling would probably be fairly static in their configuration. (I actually find the idea of silently swallowing exceptions via a small change in the config file a bit scary.)

Have you read the Developer's Guide Preview? IMO, it's the best place to start to get (re-)acquainted with the blocks.

Randy Levy
Enterprise Library support engineer
Support How-to
May 15, 2013 at 7:03 PM
Good point about it not being final :-). I did start reading the dev guide but I felt it went through things a bit quickly. I've not used the EntLib in long enough to not remember that much so I was almost starting from scratch. I found the dev ref to be easier to read though I think some of the content is either very similar or identical.

I think it might have helped that the dev ref was split into sections and cross referenced so it was easy to jump between bits. I'll go back and look at the dev guide again though and see if it helps.
Jun 18, 2014 at 4:00 PM
Hi there!

Almost one year late...
Same questions here actually, with same infos available before posting. Is there any more recent version of the Guide? I still can find only the preview.

I totally agree with Randy about the little change in config files that would make apps silently swallow exceptions.
But is it a all or nothing case? I mean, is config to be all done programmatically or all done config file-based?

I ve been watching, lab-ing and even small app developping with EntLib Exception Handling and Logging blocks, I'm a huge fan, but this major philosophical change about config and bootstrapping blocks has me confused even a bit more than between 4 and 5 releases ; )


Jun 20, 2014 at 3:55 AM
You can get the Developer's Guide to Microsoft Enterprise Library, 2nd Edition: http://www.microsoft.com/en-ca/download/details.aspx?id=41145 .

You can configure each of the blocks individually. So you could use programmatic configuration for one block and XML configuration for another.

Randy Levy
Enterprise Library support engineer
Support How-to
Jun 20, 2014 at 1:43 PM
Edited Jun 20, 2014 at 1:48 PM
Hi Randy,

Thank a lot for your answer. Sorry about the guide, I could find it a few hours later, my bad.
But about the initialization, I still have some questions:

I'm currently working only with logging and exception handling blocks, just focusing on the basics, will integrate other later, after having read the whole guide ;)
As you answered, indeed each block can be initialized independantly, and differently (one programatically, another using configuration).
And it is said that none of the blocks depends on one another.

But, I 'm initializing both the logging application block and the exception manager using XML configuration Console, and, as suggested in the guide, store each of these 2 blocks main entry point objects in a static global variable (static class ExManager wrapping the XML config initiliazed ExceptionManager, and static class LogManager storing the XML config initialized Logger. These 2 public static classes initialize the EntLib objects in a private static initializer)

My issue is that I can't have the Exception Handling block working correctly UNLESS I have a call to the LogManager BEFORE any call to the ExManager.HandleException method (which simply wraps the private static exManager ExceptionManager.HandleException method)

So how come there is a specific order in the first calls to these objects as there should be no dependency between them? I must be missing something, and/or maybe (probably) my design should be reconsidered.

Would this be the answer?
Jun 22, 2014 at 5:04 AM
Edited Jun 24, 2014 at 11:51 AM
And it is said that none of the blocks depends on one another.
I'm not sure it says that exactly. The base functionality for each block is independent of each other but there are NuGet packages where functionality from other blocks is leveraged which does introduce a dependency.

For example, you can use the Exception Handling block on it's own with no other dependencies (except for Common). However, if you want to have the Exception Handlers log then you would use the functionality of the Logging Application Block. And if you wanted to log to a database then the Logging Application Block would use the functionality of the Database Application Block. So there can be inter-dependencies between blocks.

In your specific scenario the link you referenced is the answer. Use the static Logger.SetLogWriter(logWriterFactory.Create()); to set the instance of the logger for the Exception Handling Block to use. Actually, since you are also using logging you would probably do something like this:
IConfigurationSource configurationSource=ConfigurationSourceFactory.Create();

LogWriterFactory logWriterFactory = new LogWriterFactory(configurationSource);
this.logger = logWriterFactory.Create();

ExceptionPolicyFactory exceptionFactory = new ExceptionPolicyFactory(configurationSource);
this.exceptionManager = exceptionFactory.CreateManager();    
Randy Levy
Enterprise Library support engineer
Support How-to
Jun 24, 2014 at 8:50 AM
Thank you for your feedback.

I read a bit too fast, it is clearly said that there are some optional dependencies. And that makes perfect sense now.
And thanks again for validating / improving my scenario.