Remove AnonymousType ILLinkTrim entry for EventSource

[eerhardt]

Instead of using an anonymous type to do the logging, just pass the string directly.

Contributes to #35199

It seems reasonable to allow a string to be used as a top-level object in an event, and change StringTypeInfo to use "message" as the name of the field. Thoughts?

I tried a different approach to fixing this. However, that approach ran into dotnet/linker#1218, which prevented it from working. If you prefer to wait for the linker to fix this and use that approach, let me know.

[brianrob]

I'm not actually sure this will work for tracelogging style events. Were you able to confirm that ETW events produced via this path are consumable?

[eerhardt]

Were you able to confirm that ETW events produced via this path are consumable?

I'm not sure how to test that. Can you tell me? I did run the System.Diagnostics.Tracing tests, which found that I needed to change StringTypeInfo.

As far as I can tell, this path is only used in error cases in ReportOutOfBandMessage.

[brianrob]

System.Diagnostics.Tracing tests are probably sufficient if you hit an error. There are tests for error paths, and I believe they iterate through the different ways to log events. The one thorny issue is that if you don't run the tests as admin then they don't run the ETW tests - that's the one that I'm most concerned about here.

As you point out, this is used for error paths, so what you'll want to do is trigger an error and then make sure that the error event and any subsequent events can be properly parsed. Here's a test that you can use: https://github.com/brianrob/tests/tree/master/managed/eventsource_error.

Before you run the test, make sure that you're capturing a trace using the following command:

PerfView.exe collect /Providers=*BrokenEventSource,*FunctionalEventSource

Once the app completes (should be quite fast), stop collection and open the Events view. If you filter to just eventsource events and select the two events that we care about, this is what it should look like:

The key is that both the error message and the arg="Hello World!" show up properly. This confirms that parsing after the error continues to work properly all the way through the ETW pipeline.

Let me know if you run into any issues with this and I can help.

[eerhardt]

That test worked with my change

Note that I changed "Hello World" to be typeof(object).Assembly.Location to ensure that I was using the System.Private.CoreLib.dll from my artifacts folder.

From what I can tell, the reason this works is because if (SelfDescribingEvents) is true for these error events.

[brianrob]

LGTM