Semantic Logging - Best practices for creating EventSource

Topics: Semantic Logging Application Block
Jan 23, 2014 at 9:05 PM
Edited Jan 23, 2014 at 10:48 PM
We are trying add Semantic Logging our application. I'm reading this article for a quick overview:

My question is whether we should create one custom EventSource class (inheriting from base EventSource) for each DLL in our application (assume they all need to log) or just one global EventSource class used by all DLLs in the entire application (using partial classes to break it down into multiple files if it ever becomes too big)?

The example described in the article above seems to suggested one global EventSource class per application (so the same set of keywords, tasks ids can be shared), however I noticed all the logging methods are marked as internal, which seems to suggest that EvenSource should be defined at the assembly/DLL level.

Appreciate any insight on that. Thanks.
Jan 27, 2014 at 6:53 AM
I wouldn't create an EventSource for each assembly (despite the sample code being marked as internal). One per application is probably a good place to start -- especially if the application is not particularly large. But that could depend on the application design. For example if the application had separate "modules" (for example a plug-able provider model) that could be added you might want an EventSource per "module" due to dependencies.

Also see this similar question:

Randy Levy
Enterprise Library support engineer
Support How-to