9

I'm writing a class library as an abstraction to use for logging in any application, service, etc. that I write. I'm making it decently robust by making it very configurable to suit my needs for most application/service logging scenarios that I come across.

The config is designed to specify things such as:

  • What logging level to write
  • Write to one log file for all levels
  • Write to separate files per level
  • Logging cutoff (periodic, app event, byte size restricted)
  • Log file expiration (delete log files after file age)
  • Write as flat text or XML
  • Log file name format specification
  • Whether to prefix filename with date
  • Parent app's name
  • etc, etc, etc...

I've read some other stackoverflow questions regarding configs for DLL assemblies and it causing conflict between the app.config for the hosting assembly/app. I believe that my assembly has just cause to provide a config file.

Is this a good scenario for that occasion? Is it perhaps a better idea to bake my own config into my project so that my logger reads from XML files to retrieve config values?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Jeff LaFay
  • 12,882
  • 13
  • 71
  • 101
  • 2
    Have a look at existing logging libs, e.g. apaches log4net http://logging.apache.org/log4net/index.html - this one can also be extended easily. Maybe it's not worth writing a completely new logging library. – Igor Lankin Jul 15 '10 at 13:26
  • @bja, thanks for the suggestion. I've written a good deal of logging code for a project I'm working on at work and decided to use most of the code as a base for future applications. I did try working with a logging framework previously and was frustrated because my dept. wants to use .Net 4.0 and I had problems getting a lib or two to work with it. So I ended up implementing my own lightweight logging. Thanks very much for the suggestion however, I normally agree with that idea but it doesn't yield a reason to not reuse my own code. – Jeff LaFay Jul 15 '10 at 13:32
  • @jlafay I'd suggest looking at them anyway -- not to reuse their code -- but to see how they implement being configured via the App.config file -- it's very common for a logging framework to be configured via the App.Config file, and you can follow the same practice with your own framework. :-) – BrainSlugs83 Jul 19 '16 at 02:30

4 Answers4

9

What you could do is

  • create a custom configuration section (using e.g. the COnfiguration Section Designer tool)

  • put your assembly's configuration into a separate MyAssembly.config file

  • reference that assembly config file from your host app's config:

    <configuration>
   <configSections>
       <section name="YourAssembly" 
                type="YourAssembly.ConfigSection, YourAssembly" />
   </configSections>

   <YourAssembly configSource="MyAssembly.config" />
</configuration>

That way, you can "externalize" your configuration into a separate config file which you have only once (in your assembly's project), and any project needing it just needs those settings in its own config file.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • +1 for the link. I've been manually writing ConfigurationSection and ConfigurationSectionGroup classes for years. This tool looks like a lifesaver! – Toby Jul 15 '10 at 13:47
  • I think this is the best solution to my config needs. Thanks for the link to the config section designer too! – Jeff LaFay Jul 15 '10 at 14:23
3

Sounds like a custom config section would work well in your case. Many libraries, such as the Enterprise Library do exactly this. Check out the MSDN article about creating one.

wsanville
  • 37,158
  • 8
  • 76
  • 101
3

The .NET config mechanism is not meant to handle configuration files for DLLs. You should configure your application with appropriate settings and pass them on to the class you are instantiating from the DLL.

It is possible to add settings to a DLL project as you'd usually do for applications. All you then need to do is copy the relevant sections and entries into the application's app.config manually and it will work.

It is, however, still true that there's no point copying the DLL's config file. It will not be read.

Thorsten Dittmar
  • 55,956
  • 8
  • 91
  • 139
  • 1
    Since I'll be using this for a wide array of software applications, wouldn't it be better to config it on the fly with a config file I could hand edit quickly rather than populating properties when instantiating a logger in the host app? – Jeff LaFay Jul 15 '10 at 13:28
  • @jlafay - no, then you're adding a hidden dependency to your DLL. You can still make a config file - just make your *applications* read the config file (or a portion of that file that you copy into their configs) and pass the settings to the classes from your DLL. (and +1.) – Jeff Sternal Jul 15 '10 at 13:51
  • Err..., lots of dlls require .config file changes (especially logging framework dlls). You just add the relevant config sections to your app.config, and it all works without extra code changes. – BrainSlugs83 Jul 19 '16 at 02:21
2

Another mechanism is to have a seperate configuration file (*.dll.config) for your assembly. The technique is shown here: http://blog.rodhowarth.com/2009/07/how-to-use-appconfig-file-in-dll-plugin.html

The above, imitate the standard app.config technique for assemblies.

In my opinion the dll configuration reading code should only exist in the corresponding dll and in a seperate class - with single responsibility of reading configuration entries from the *.dll.config. This is a nice way of having configuration file for an assembly in a way similar to the configuration file (app.config) an executable can have.

Anand Patel
  • 6,031
  • 11
  • 48
  • 67