Design problems in using semantic logging in a real-world application

Topics: Semantic Logging Application Block
May 28, 2014 at 4:20 PM
I started to play around with the semantic logging application blog a while ago and even though I am very impressed by its capabilities, I begin to stumble over a myriad of design problems after trying to incorporate the application in a real world enterprise application.

My first problem regards module segregation and information hiding. All examples of the semantic logging application block seem to assume that there's only one big event source class for the whole application. I don't see how it is possible to use such a thing in a strictly layered architecture, assuming that a cross-cutting component like logging should not have any information about the nature and contents of the application layers.

I tried out to create a seperate EventSource class for each layer (using the same application name for all EventSources), which technically works, but throws exceptions reminding me that the EventSource GUID gets reused. This isn't useful at all in an application that gets debugged frequently.

My second problem arises when installing different applications of our application product line on the same machine. Since these application share common components, but should log into distinct log files (using out-of-process logging), so I need to use different event sources for each application. Which in turn I can't, since the reused modules all rely on the same event source (determined at compile time) regardless of their runtime context. The only way I found so far to work around this to use a very awkward and tedious dependency injection involving massive amounts of copied code for all my logging calls.

Can anyone provide me with hints how to solve these problems?

Jun 2, 2014 at 5:29 AM
You can create one EventSource for your application but if you do find that more than one is necessary you can create multiple. Also, you can use the EventSource name to uniquely identify the EventSource but bear in mind that each EventSource name should be globally unique. EventSource name is typically contains 3 categories. For example [EventSource(Name = "MyCompany-MyApplication-AnotherCategory")]. So you could use an event source per layer if it makes sense. So, in a way, it's similar to the Logging Application Block where you would define logging categories up front (what those categories were was a small design decision).

One thing to bear in mind is that the Semantic Logging Block is built on top of System.Diagnostics.Tracing which hooks into ETW so some of the design is constrained by those designs.

You might want to take a look at the Microsoft EventSource Library on NuGet. It has some additional features that look like they might be useful to you (read the downloaded Word document). For example, having an EventSource implement an interface or having a hierarchy of EventSource (i.e. base class). This is probably not a silver bullet but the combination of interfaces and code reuse can help address some design issues. Note that the EventSource NuGet package does not work with the out of the box Semantic Logging Block but can be used instead of the BCL version in a custom SLAB build.

For the out-of-process scenario would it be helpful to be able to filter by process name?

Randy Levy
Enterprise Library support engineer
Support How-to