Use source generator to assist EventSource initialization for SPCL EventSources

[sywhang]

EventSource suffers from reflection-heavy ops upon initialization to generate manifest for the event data where it uses reflection to look up every single event-annotated method + their attributes defined to generate the manifest data.

This issue tracks the work to assist the generation of these manifest data for EventSources in System.Private.CoreLib to use source generator. Once this is successful, we can look into expanding the set of EventSources in the BCL to use the generator.

Related issues:

49592 #45466

cc @tommcdon @josalem

[ghost]

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti See info in area-owners.md if you want to be subscribed.

Issue Details

---

EventSource suffers from reflection-heavy ops upon initialization to generate manifest for the event data where it uses reflection to look up every single event-annotated method + their attributes defined to generate the manifest data. This issue tracks the work to assist the generation of these manifest data for EventSources in System.Private.CoreLib to use source generator. Once this is successful, we can look into expanding the set of EventSources in the BCL to use the generator. Related issues: #49592 #45466 cc @tommcdon @josalem

Author:	sywhang
Assignees:	sywhang
Labels:	`area-System.Diagnostics.Tracing`, `enhancement`
Milestone:	6.0.0

[benaadams]

Once this is successful, we can look into expanding the set of EventSources in the BCL to use the generator.

For scope on other EventSources (from https://github.com/dotnet/runtime/issues/43390#issuecomment-794874647)

For a standard ASP.NET Core site + ApplicationInsights (e.g. https://themesof.net/) it creates 27 EventSources on start-up.

With all the ones not in System.Private.CoreLib.dll doing reflection to get the Guid to use for the constructor (as that overload is not available outside SPCL):

[sywhang]

Thanks for the additional info @benaadams and all the great feedback you've given us so far in the tracing space and the initial source generator work you did that I'm building on top of : )

I'm hopeful that we'll be able to get this into System.Private.CoreLib and BCL in .NET 6. I'm going to try my best to push this up the stack as much as time allows, but it may not be possible to push it up the stack before the .NET 6 deadline if other work takes over in the meantime. If that happens, I'll still push this through the next release version of .NET.

Just for context, the main challenge around the source generator work so far has been around figuring out the versioning + customer adoption story (i.e. can we ship it with Roslyn analyzers to assist developers to move towards source-generator friendly EventSources, should this ship as its own NuGet package or with the SDK, etc.), trying to come up with a reasonable public API that wouldn't break existing code written around EventSources (unfortunately self-describing EventSources are not exactly source-generator friendly with some methods allowing anonymous objects to be logged) as well as defining the set of APIs that would allow the minimal set of changes for one to move over to source-generated EventSource.

Many of these can go unanswered for BCL/System.Private.CoreLib EventSources, but to push it up the stack, some of these questions will need to be answered.