views:

212

answers:

3

Simple question: see title. I'm using .NET 3.5.

Elaboration: I'm building a plugin that will be loaded into a 3rd party application at runtime. The main application uses log4net as its logging framework. However, it doesn't expose the root logger so we're unable to log. (I've raised this issue with the upstream developers and they'll be fixing it for a future release so in the meantime I need to come up with something else)

Another limitation of the system is that when it receives notification that it should load a plugin which doesn't exist on the local system, it will pull down that plugin from a server it is connected to (if it exists on the server), but it can only pull down the assembly where the plugin lives. This means no external assemblies and no .config or any other files can be deployed with the plugin.

That leaves me with only built-in .NET assemblies and everything in my plugins' assembly. However, I don't want to be reinventing the wheel by building myself Yet Another Logging Framework so I'd like to know what the best approach to this problem would be.

I'd prefer logging to a file and would like to avoid dumping stuff into the Windows event log.

+9  A: 

Two main options are out there:

The Trace and Debug classes which are part of the .NET framework (within the System.Diagnostics namespace) are probably your best bet. These provide the tools to do lightweight logging to a variety of runtime configurable listeners, that can write to file, eventlog and several other places.

It sounds like you can't add any extra classes to your application, but if you can then I'd recommend the Microsoft Enterprise Library, which while being an external logging framework, is provided by Microsoft and tends to play nicely with .NET code.

David Hall
I was thinking about the Enterprise Library originally too, but after confirming my suspicions that it was an external library I stopped pursuing that train of thought.I'll try Trace and Debug for now. Cheers. :)
alimbada
A: 

+1 for Trace and Debug. You might ask the upstream developers to implement a TraceListener that forwards your messages into Log4Net so that everything will end up in a single file.

They might also consider Gibraltar for viewing and analyzing the log4net data. In fact, if the upstream developers integrated Gibraltar it would merge the log4net and Trace data together automatically.

Jay Cincotta
+2  A: 

You might take a look at the Common.Logging infrastructure. It's a facade around logging frameworks, such as log4net and LAB.

Steven