Developers can employ EventSource APIs when publishing for AOT targets to be able to use .NET tracing capabilities

[mjsabby]

EventSource is a common logging abstraction in .NET but it uses reflection to generate the schema for an EventSource definition. The source generator would do this at build time and make using EventSources reflection free.

[MichalStrehovsky]

EventSource used to have a hookup point for this that was used in .NET Native. It looked like this:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 646 to 663 in dbcea6b

	internal virtual void GetMetadata(out Guid eventSourceGuid, out string eventSourceName, out EventMetadata[] eventData, out byte[] manifestBytes)
	{
	//
	// In ProjectN subclasses need to override this method, and return the data from their EventSourceAttribute and EventAttribute annotations.
	// On other architectures it is a no-op.
	//
	// eventDescriptors needs to contain one EventDescriptor for each event; the event's ID should be the same as its index in this array.
	// manifestBytes is a UTF-8 encoding of the ETW manifest for the type.
	//
	// This will be implemented by an IL rewriter, so we can't make this method abstract or the initial build of the subclass would fail.
	//
	eventSourceGuid = Guid.Empty;
	eventSourceName = null;
	eventData = null;
	manifestBytes = null;
	return;
	}

It was nuked in the meantime (latest sources don't have it anymore).

[7sharp9]

How would this be consumed by non C# languages?

[benaadams]

How would this be consumed by non C# languages?

It would affect all the EventSources in the runtime and aspnet so all languages would get benefits (reduced startup; increased trimability etc)

• ConcurrencyLimiterEventSource
• HostingEventSource
• KestrelEventSource
• CertificateManagerEventSource
• HttpConnectionsEventSource
• LoggingEventSource
• System.Net.NetEventSource
• DependencyInjectionEventSource
• CDSCollectionETWBCLProvider
• DataCommonEventSource
• DiagnosticSourceEventSource
• PLINQETWProvider
• HttpTelemetry
• NameResolutionTelemetry
• NetSecurityTelemetry
• SocketsTelemetry
• ArrayPoolEventSource
• TplEventSource
• FrameworkEventSource
• NativeRuntimeEventSource
• RuntimeEventSource
• PortableThreadPoolEventSource
• XmlSerializationEventSource
• DataflowEtwProvider
• ParallelETWProvider
• TransactionsEtwProvider

Whether or not you enable the EventSources they do a reflection based initialization step to see whether they are Enabled; which is expensive in startup.

It will also mean exposing runtime apis for EventSources that other languages can use if they also wish to implement similar source generators; or can manually use.

[vitek-karas]

How would this be consumed by non C# languages?

On top of the benefits with framework event sources mentioned by @benaadams, this could be used for any other event source as well.

If the API is exposed as public any language could be used to implement it. For the C# source generator to actually work it would need to be public anyway.

The C# source generator would make it easier (do it automatically), but it would still be possible to implement the same functionality manually in any other language.

[samsp-msft]

Dropping the priority as we don't have early AoT customers depending on it.

[benaadams]

A whole lot of startup going into generating EventSource manifests and Guids etc for a standardish ASP.NET Core app with ApplicationInsights, e.g. this is https://themesof.net/

Couldn't fit it all on one screen, here's the rest

[benaadams]

For https://themesof.net/ looks like 27 EventSources are created on startup, most of them probably just to check .Log.IsEnabled() and get false back... 😅

With any not in System.Private.CoreLib.dll doing reflection to get the Guid to use

[iSazonov]

It is an issue for PowerShell startup too.

[tommcdon]

@LakshanF @davmason do you know of any unresolved issues related to using EventSource on NativeAOT?

[LakshanF]

Any payload that uses complex data types in EventSource, that in turn depends on unbound reflection for serialization, will be problematic for NativeAOT applications (primarily due to trimming). The long-term solution is to use a source generator for such cases. These scenarios would cause both Roslyn analyzer (when the application project file indicate intention to use NativeAOT) and ILCompiler to generate warnings, and developers should not ignore these warnings.

All Framework EventSource providers should work without problems, as well as payloads with primitive data types.