How do I create a hierarchy of lognames in the Windows event system?

Question

• I am logging messages using Enterprise Library.
• I want some of these (typically errors and warnings) to be passed to the Windows event-system). I today route these via entlib.config.

This solution works and so far, so good. But, I have more needs than what this solution provides me. I have multiple installations that should log to different logs, but I want their names to be logical and intuitive in the event-viewer. But, the Windows event-system cannot have two categories where the first 8 characters in the name are the same. The category-name can be longer, but only the first 8 letters is used to distinguish them. .Net actually outputs a warning if this happens:

Only the first eight characters of a custom log name are significant, and there is already another log on the system using the first eight characters of the name given.

Currently I have to resort to cryptical prefixes, but I am still in danger of having multiple installations "colliding" with each other in regrads to the logname, so I need a better solution.

However, in the event viewer on my computer I can see that there are also hierarchies of lognames - which is exactly what I need. Both Microsoft and Cisco obviously has found a way to do this:

But, how can I create such an hierarchy for logging, where each application may be installed a number of times? Like this:

CompanyName   ApplicationName     Installation1     Installation2 

Answer 1

.NET 4 Answer

What it looks like you are seeing are the channels from Event Tracing for Windows (ETW). You can see the relevant items in the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT.

To use those features you would have to use the new Windows Event Log functionality which supersedes the Event Logging API starting from Vista and looks like it is mainly targeted at C/C++ development. It does appear that some of this is exposed via the System.Diagnostics.Eventing Namespace.

I found a good overview of ETW to be Improve Debugging And Performance Tuning With ETW.

The good news is that it looks like you can do what you want. You will need to create an XML manifest that contains provider information as well as the events that will be logged. Then you need to use the Message Compiler (MC.EXE!) on the manifest to create header, resource files, and logging classes and then register the provider.

If you download Microsoft Windows SDK for Windows 7 and .NET Framework 4 you will find in the Samples\winbase\Eventing\Provider\Simple\CSharp subdirectory a .NET sample solution that should lead you through all the steps.

While it does meet your hierarchical requirement and is sort of cool, for a typical line of business application this might be a bit of overkill in terms of complexity. Also, the code generated by the message compiler is unsafe code so that may also be a negative.

.NET 4.5 Answer

In .NET 4.5 there is much better support for ETW using the EventSource class. See Windows high speed logging: ETW in C#/.NET using System.Diagnostics.Tracing.EventSource for an introduction. There is also now Event Log support with EventSource. See Announcing the EventSource NuGet Package – Write to the Windows Event Log for a walkthrough. Basically, at compile time a manifest and manifest DLL are generated for each EventSource and these can be registered using wevtutil.exe. With the addition of EventSource and Event Log channel support this approach now looks to be straight forward and viable.

Finally, note for those interested in ETW that the patterns & practices team has an application block Semantic Logging Application Block that can use ETW.

Answer 2

Providers must be named something of the form "Company-Product-Component". To be clear, a provider's name must include 2 '-' symbols. Documentation on this may be found here.

Channels must have their names written out in a specific way as well. Again, the MSDN's documentation explains this. You should name your channel to something of the form "Company-Product-Component/type".

Here is a fragment of a manifest I wrote for you to use as an example:

<provider name="Our Company-OurApp-Service"           guid="{4990f5dc-85a0-4660-9ce0-275e027a02d2}"           symbol="GUID_PROVIDER"           resourceFileName="C:\Program Files (x86)\Our Company\OurApp\service.exe"           messageFileName="C:\Program Files (x86)\Our Company\OurApp\service.exe"           parameterFileName="C:\Program Files (x86)\Our Company\OurApp\service.exe"           message="$(string.Provider.Name)">     <channels>         <channel chid="c1"                  name="Our Company-OurApp-Service/Operational"                  type="Operational"                  symbol="CHANNEL_1"                  isolation="Application"                  enabled="true"/>     </channels>     ... 

The folder hierarchy we see in the event viewer is an illusion. It's really just a flat list of providers and channels rendered as a rigid 3-folder deep structure. This is why several folders under Microsoft/Windows have dashes in their names rather than nesting further.