EventSourceProxy: Turning Plain .NET Interfaces into ETW Log Sources

The Boilerplate Problem in ETW Logging

ETW is the Windows-native tracing subsystem, and the .NET EventSource class is the managed way to feed it. The catch is that writing an EventSource by hand means declaring each event method, decorating it with EventAttribute, assigning opcodes and tasks, and keeping the manifest in sync. For a large interface, that is a lot of repetitive code. EventSourceProxy attacks that by generating the implementation for you. You declare an interface or an abstract EventSource, and the library emits the concrete type at runtime. The README's example is a two-method ILog interface: call EventSourceImplementer.GetEventSourceAs<ILog>() and you have a working log source. The intended audience is .NET developers on Windows who want ETW's low overhead without hand-writing every event.

Three Modes of Code Generation

The library supports three distinct usage patterns. First, it implements a plain interface as an EventSource, so any interface can become a log source with zero extra code. Second, it fills in an abstract class that derives from EventSource, letting you keep the familiar EventSource shape while ESP generates the method bodies. Third, it wraps an existing object: TracingProxy.CreateWithActivityScope<ICalculator>(calculator) returns a proxy that logs every method call on the interface when the ETW source is enabled. The proxy also exposes _Completed and _Faulted events, which is useful for tracking async or long-running operations. The README stresses that generated IL keeps overhead low and is almost nothing when tracing is off, meaning the runtime cost of the generated code is meant to be acceptable for high-frequency logging.

Transform Rules for Logged Data

Not every interface method signature maps cleanly to what you want in the log. The README shows a configuration API for reshaping parameters. For an IEmailer interface, you can tell ESP to trace only certain fields of an Email object, rename them (From becomes Sender), combine Subject and Body into a single JSON message, and ignore the when parameter entirely. The fluent syntax chains methods like .Trace(e => e.From).As("Sender") and .TogetherAs("message"). You can also add context that is not part of the method signature, such as .AddContext("user", () => SomeMethodThatChecksIdentity()). This is the feature that separates ESP from a simple proxy generator. It lets you keep the logging shape independent of the code shape, which is exactly what you need when an interface carries data you do not want in the trace.

Getting It Running: NuGet and Two Package Variants

The README points to NuGet for installation. There are two packages: EventSourceProxy for the .NET Framework's System.Diagnostics.Tracing, and EventSourceProxy.NuGet for the separate Microsoft.Diagnostics.Tracing NuGet library. That split matters because the two libraries have different APIs and versioning. The setup is minimal: reference the package, then call EventSourceImplementer.GetEventSourceAs<T>() or TracingProxy.CreateWithActivityScope<T>(instance). No configuration file is needed for the basic case. For transform rules, you configure TraceParameterProvider.Default in code, as shown in the IEmailer example. The wiki is referenced for full documentation, but the README itself gives enough to start. There is no mention of .NET Core or .NET Standard support, which is a red flag for modern projects.

Limitations: Framework Lock-In and Missing Maintenance Signals

The most obvious limitation is the .NET Framework focus. The two-package split exists because the framework's tracing library and the NuGet one diverged, and the README does not mention .NET Core at all. If you are on a modern runtime, this is likely the wrong tool. Second, the license field says NOASSERTION, which means the repository does not declare a standard open-source license. That is a legal risk for adoption, and you should resolve it before using the code. Third, the repository shows no recent releases and no last-push date in the supplied material, so maintenance status is unclear. The README references a v2.0 feature, but there is no evidence of ongoing development. For a library that generates IL at runtime, lack of updates can be a problem because it may break with new framework versions or security patches.

Alternatives: Hand-Written EventSource and SLAB

The obvious alternative is to write your own EventSource subclass by hand. That gives you full control over event definitions, keywords, and opcodes, but it is exactly the boilerplate ESP eliminates. A more comparable option is the Microsoft Enterprise Library Semantic Logging Application Block (SLAB), which the README itself recommends for consuming ETW data. SLAB is not a generator; it provides listeners that route ETW events to console, rolling files, or databases. So the two tools are complementary: ESP produces the events, SLAB consumes them. If you do not need the transformation rules, a hand-written EventSource is simpler and has no runtime code generation. If you need cross-platform tracing, look at modern alternatives like OpenTelemetry, though the README does not mention it.

Maintenance and Upgrade Considerations

Upgrade cost depends on which package you use. The framework version ties you to the .NET Framework's System.Diagnostics.Tracing, which is stable but not evolving. The NuGet version tracks Microsoft.Diagnostics.Tracing, but that library has its own release cycle and versioning, so you must match ESP's expectations. The README does not document a migration path between the two. There is also the question of runtime IL generation: any change to the .NET runtime's access rules or the introduction of obfuscation or partial-trust environments could break the generated proxies. The README does not address these scenarios. Before upgrading, you should check the wiki for version-specific notes, and test the generated code in your actual deployment environment.

Editorial conclusion

Adopt EventSourceProxy if you own a .NET Framework codebase, want to add ETW logging to existing interfaces without hand-writing EventSource classes, and can live with the NOASSERTION license. Skip it if you are on .NET Core or need a maintained, clearly licensed library. Before adopting, verify the license terms with your legal team, confirm the NuGet package still installs on your target framework, and test that the generated IL works under your obfuscator or partial-trust environment, since those are common failure points for runtime code generation.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases