Question

How can I use EL to specify trace listeners and formatters for only one subsystem (say, DLL) of a large system?

I'm writing a sub-module of a very large large application (thick client, not web app) that uses a gateway/portal model to load its various subsystems. I'd like use EL 5.0 (already in use) to manage logging/tracing configuration, but just for my subsystem. It looks like app.config is getting converted by VS to foo.dll.config. Can I convince EL to pick up the settings in foo.dll.config (at run-time) and merge them into its existing configuration data, in memory? (Not into a merged config file.)

(Looks like, based on Enterprise Library Class Library App.Config, it can't be done.)

Was it helpful?

Solution

I wouldn't recommend trying to merge configuration -- it can can get messy.

Instead, I would configure your sub-module to configure and use private references to the appropriate Enterprise Library objects you need.

I'm assuming your module is a class library that has an app.config. When compiled it generates a module.dll.config file in the output directory. To take an example of logging using Enterprise Library 6, I would create a helper class to load your own configuration and maintain a reference to your module's LogWriter. In this way your module loads its own configuration and does not interfere and is not influenced by other configuration in the application.

namespace MyModule
{
    public class MyModuleClass
    {
        public void DoSomething()
        {
            MyModuleLogger.LogWriter.Write("MyModule Test", "General");
        }
    }

    public static class MyModuleLogger
    {
        private static Lazy<LogWriter> logWriter = new Lazy<LogWriter>(() =>
            {
                FileConfigurationSource configSource = 
                    new FileConfigurationSource("MyModule.dll.config");
                LogWriterFactory factory = new LogWriterFactory(configSource);
                return factory.Create();
            });

        public static LogWriter LogWriter
        {
            get { return logWriter.Value; }
        }            
    }
}

I've used a static class but you could use a variety of approaches that may fit with your design (singleton, factory, etc.)

You will have to ensure that your dll.config file is deployed along with your assembly. You could also hit problems if there are version issues with Enterprise Library (e.g. you are using Version 6 while the application uses Version 5.)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top