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.
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.
You might take a look at the Common.Logging infrastructure. It's a facade around logging frameworks, such as log4net and LAB.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With