Microsoft.Diagnostics.Tracing.EventSource is now RC on NuGet.org

Microsoft.Diagnostics.Tracing.EventSource is now RC on NuGet.org

Rate This
  • Comments 24

We are announcing the RC of the EventSource NuGet package, which enables fast app tracing to the Windows Event Log, including in production. This post was written by Cosmin Radu, a software developer on the .NET Runtime team.

Over the past several months we’ve been working on addressing feedback and extending the value proposition delivered by the EventSource NuGet release. Today I’m happy to announce the RC release of the EventSource package, and its new companion package EventRegister.

So, what’s new in RC?

Here’s a summary of the changes we’ve made:

  • EventSource build-time validation for everybody: with this release we’re including a new NuGet package, EventRegister. It enables build time validation for projects containing all variations of event source.

  • EventSource incremental improvements: improved handling for formatting strings, additional validation rules, and transparency attribute parity with mscorlib.

EventSource build-time validation for everybody

We’ve received feedback that the build-time validation included in the beta release of EventSource was providing a significant benefit to anybody that was defining their own event source. This feedbackw as the same for users of the EventSource NuGet package version and the system one (System.Diagnostics.Tracing.EventSource). As a result, we have released this functionality in the EventRegister NuGet package, which can be referenced from any project that uses some variation of EventSource. And, in order to maintain a seamless experience for the users of the NuGet EventSource package, EventSource is a dependent on EventRegister, so you’ll only need to add a reference to the EventSource package, and you’ll get validation/registration pulled in transparently.

We’ve also improved the validation experience. EventRegister will now report all validation failures for each event source type defined in your projects, instead of simply stopping at the first error it encounters. Here’s some sample output you may get in your error tool window:

EventSource validation results showing up in Visual Studio

And while we were working on the build system we’ve made some changes to the targets file to improve the clean build and incremental build experience. Extensibility points are now provided for projects that use EventRegister, so you can customize the behavior of the validation tool by defining relevant properties in the referencing project. Please find the details in the _EventRegisterUserGuide.docx included with the package.

Another notable improvement for the EventRegister package is that it now supports additional project types, in particular Portable Class Library projects and Windows Store projects.

EventSource incremental improvements

This release of EventSource adds other improvements:

  • Supports EventRegister’s full type validation
  • Addresses string formatting issues for the EventAttribute.Message property
  • Enforces more EventSource validation rules
  • The transparency attributes on the NuGet version of EventSource were changed so that it corresponds to the in-box version System.Diagnostics.EventSource. This fixed some cases where our security system wouldn’t let you use the NuGet version while you could use the in-box version. For more details, see MSDN.

What else does EventSource do?

Everything that was covered in the original Beta announcement relating to the EventSource core functionality still applies. Here are the highlights:

Sending Events to the Windows Event Log

Event log support is a new feature provided with this NuGet package. It enables you to specify one additional destination for EventSource events – an application-defined event log. That means that all of your events will show up in a part of the event log that is specific to your app.

In the screenshot below, you will see an area highlighted. That’s the part of the event log that our demo code writes to -- “Samples\EventSourceDemos\EventLog” – and yours would be similar. Your app events might show up under a node such as: “MyCompany\MyApp”

EventLog Demo showing in Windows Event Log

The following code is an example of an ETW event definition that takes advantage of this new feature.

[EventSource(Name = "Samples-EventSourceDemos-EventLog")]
public sealed class MinimalEventSource : EventSource
{
    public static MinimalEventSource Log = new MinimalEventSource();

    [Event(1, Message="{0} -> {1}", Channel = EventChannel.Admin)]
    public void Load(long baseAddress, string imageName)
    {
        WriteEvent(1, baseAddress, imageName);
    }
}

To use this feature, you specify the ETW channel you want to write to in the Channel property of the Event attribute. The Event attribute is associated with the ETW event method your event source defines. In the class above, that’s the Load method.

The NuGet package supports the four predefined ETW channels that the Windows Event Log defines: Admin, Operational, Analytics and Debug (see the ETW channel documentation for more information). You can see how those show up in the screenshot above. We also used an existing ‘Message’ attribute to create a formatted string for our message.

With the above definition (and a registration step detailed later), the “Load” event will write an event to the “Admin” event log each time it is called. This log can be found in the “Event Viewer” tool under the node “Applications and Services Logs / Samples / EventSourceDemos / EventLog”. Notice that the three-element name specified in the EventSourceAttribute determines the location of the log.

In order for the windows event viewer to know that there is a new source of events to log, it is necessary that you register your EventSource with the operating system, typically when your application is deployed or installed. This operation requires administrator permissions. The artifacts needed for registration (a manifest file and a resource DLL) are generated at build time through a build step injected in your project (when you add the NuGet package reference).

Registering your EventSource

When you install the EventSource NuGet package, the build step previously mentioned generates the following files for each EventSource in your application:

  • <AssemblyName>.<EventSourceTypeName>.etwManifest.man
  • <AssemblyName>.<EventSourceTypeName>.etwManifest.dll

These files need to be registered with the operating system to enable channel support. To do this you run the following command after the files are in their final deployed location:

wevtutil.exe im <EtwManifestManFile>
    /rf:"<FullPathToEtwManifestDllFile>"
    /mf:"<FullPathToEtwManifestDllFile>"

Once this registration command is executed, all subsequent calls to MinimalEventSource.Log.Load(), from any process on that machine, will automatically result in events in the Windows Event log.

Note: you can provide localized strings for your EventSource by using the LocalizationResources property on the EventSourceAttribute associated with your EventSource type.

Sample code

This release includes an update for the EventSource samples NuGet package. The easiest way to use the samples is to create a new console application called ‘DemoEventSource’ in Visual Studio and then reference the EventSource Samples NuGet package from that project. The source code is part of the package and the Readme.txt file will tell you how to wire up your main program to the sample code.

What next?

Today, we’ve shipped the release candidate of Microsoft.Diagnostics.Tracing.EventSource and Microsoft.Diagnostics.Tracing.EventRegister packages. We plan to release a stable 1.0 package by the end of the year, but that will depend on the feedback we receive based on this RC release.

As always we’re looking forward to your feedback, so please let us know what you think. Let us know what works well for you and what other capabilities you’d like to see in the future in either of the packages released.

Leave a Comment
  • Please add 1 and 4 and type the answer here:
  • Post
  • Very interesting and useful

  • Very good, I will use a lot!

  • What were the Message string formatting issues that were addressed?  BTW is there a way to get the format string to display numbers in hex?  Quite often we want to see numbers in hex like an HResult where we can identify the hex number more quickly.

  • Hey,

    If you know anyone looking for perm or contract work or a recruiter for your teams in the Midlands area let me know. Kayleigh :-)

  • @Andre.Ziegler:

    Andre, I'd be interested to understand what you mean by "the captured stack is bad". Is it that the symbols are not correctly resolved, or that it's not appropriate for some purpose specific to your application?

    Regarding the issue with the event name "Crimson:{GUID}", can you send me repro steps (offline) so I can take a look? -Thanks!

  • @Keith Hill:

    > [...] this drop does more EventSource validation at build time.  Are these checks different than the checks that the PnP SLAB EventSourceAnalyzer perform?

    Yes, we have indeed added more validation to the EventSource class. However, since EventSource attempts to perform validation without running any of the user's code, while SLAB does not have this constraint, the set of checks EventSource performs is different from set performed by the SLAB EventSourceAnalyzer.

    > What were the Message string formatting issues that were addressed?

    The Windows EventLog API specification for formatting strings is fairly complex. EventSource will now produce correct strings for most cases (it handles some special characters in both "grammars": {, }, %, !).

    > is there a way to get the format string to display numbers in hex?

    We've made a conscious decision to limit the formatting supported in order to maintain a low level of complexity. One way around this is to specify the "hex number" as a string parameter that you format before passing it to the [Event] method.

  • @Loïc:

    > So, in consequence, the package is really usefull when creating new event provider, but hard to use to interact with third party manifests.

    Indeed EventSource was meant to be used for the first situation above; the second scenario was not a design goal the EventSourceand is unsupported!

    > By the way, I wonder why the couple Opcode/Task have to be unique?

    This is a "best practice" for ETW manifests, that unfortunately is not always followed. Since the EventSource package targets *new* ETW providers we considered the cost is small in order to ensure users follow these best practices from the beginning.

    > anyway this version in far much better than the one provided by the Framework, and I'm now really close to convince my colleagues to use it instead of Log4Net or NLog :) Good job guys!

    Thanks for the kind words, Loïc, we're glad when we can make live easier for our users :).

  • @CosminRadu

    the stack includes too much noise (native stuff which I don't Need).

    The "Crimson:{GUID}" Thing is easy to repro. Simply try to activate user mode stackwalking for the EventSource classes. Instead of proper names I see this Crimson:{GUID}.

  • FYI - EventSourceProxy.NuGet now supports using Microsoft.Diagnostics.Tracing.

    Get all of the benefits of the new EventSource without having to write any of the tedious code.

    www.nuget.org/.../EventSourceProxy.NuGet

    Enjoy.

Page 2 of 2 (24 items) 12