I just download Enterprise Library 3.1 and created an example app with a custom listener. Everything works great but I need to show the ability of being able to manually make a change to the Configuration File and have the application automatically pick
up that change. For example change the filtering level so certain events don't get logged. I have been searching around and haven't been able to find a good example in C# using the current Enterprise Library 3.0 or 3.1.

Does anyone know where I can find a quick example? I just need to monitor the app.config and have the application pick up those changes on the fly. The reason for this is I cannot bring down my application and restart it to pick up changes to the config file.
I know log4Net has this ability but would prefer to use Enterprise Library.

You just need to modify the .config and EntLib will pick up the change auto-magically.

Im just getting started and have verified this using the testing app's Ive created by changing the config in various ways while my app was cycling a for loop 100k times. I did not add a file watcher or anything else to my app, just refed EntLib and coded some
using(new Tracer()) and Logger.Write() stuff :)

Also, there is a "quick start" showing how to keep the config in a sql db (which is what I will be employing so I can not only change values, but provide a different config depending on the requester of our service).

I tried just making a change to the config file and see if it would be picked up and it wasn't. I want to be able to edit the config file and change the priority on the fly so additional events could be logged based on the new priority without restarting
my application.

I made sure I was running the program from the Debug and also tried release folders and not from Visual Studio. I also made sure I was changing the right config file in those folders. But still the changes I made to the config file were not being picked
up by the running application.

The basic scenario I am trying to prove is I have a Debug category set to priority 0 that messages will get routed to. I also have an Event category set to priority 3 that other messages get routed too. When I start up my application I have a priority filter
set to min value 3 and max value 5. Doing this will only pick up the events and not the Debug messages. I want to be able to change the config file priority level to min of 0 and max of 5 without having to restart the application so that it will start reporting
debug messages as well as the events in case a problem arises. That is basically the scenario I need to show that the enterprise library can handle before I can get approval to implement it.

I did some more testing and trying things out this morning and got it to work. What I didn't realize was there is a delay before the new changes take affect. I was making a change to the config file then going to the test app and firing off a logging event
and it wouldn't show up so I thought it wasn't working. But if I fired the logging event off a couple more times it would start showing up. The same behavior happens in the quickstart demos. This is not a big deal now that I kow there is a delay before the
changes to the config file will take affect in the running application.

If you look that the source file you can see you currently cant change the value through any public method. There are test methods that allow the changes, but these are not publicly accessible. If it is critical to change the polling you could compile
the EL your self with your own changes - that is the beauty & power of the source code :-)

However I imagine that a max 150sec delay under normal project scenarios is a reasonable default for changing a runtime logging level. At some point you will be burning CPU cycles just checking if anything needs to change.

That all being said it may not be a bad addition for the next release of EL. As developers we like to control everything, and this would appear simple enough to add.

Changing the default polling time is accessible in Ent Lib 3 and 4. An example is below. It is a public static method so you can call it without having to instantiate anything. I believe it must be called before your first call to anything Logger related
since the polling time gets set when the configuration is first read.