Add RuntimeProperties Trace Event #690
Conversation
As part of dotnet/core-setup#4112, this change adds the RuntimeProperties event. This event during fired on startup, and publishes all properties passed by the host to the runtime. Known properties are explicitly called out by the event template. Other properties are accumulated into the "Others" string. Currently, due to EventPipe’s attach only nature, a test using event-pipe may miss the event. So, this change doesn't include an automated test. The recommended method for testing the event was using ETW. I'll send out a PR to the PerfView repo to add this event to TraceEvent.
| LPCWSTR fxProductVersion = nullptr; | ||
| LPCWSTR jitPath = nullptr; | ||
| LPCWSTR fxDepsFile = nullptr; | ||
| LPCWSTR appPaths = nullptr; |
There was a problem hiding this comment.
appNIPaths is deprecated and not used anywhere. Do we really need to log it?
I would rather delete it.
| { | ||
| fxProductVersion = propertyValues[i]; | ||
| } | ||
| else if (wcscmp(propertyNames[i], W("JIT_PATH")) == 0) |
There was a problem hiding this comment.
JIT_PATH is also not relly used for anything.
| @@ -710,6 +710,43 @@ | |||
| </UserData> | |||
| </template> | |||
|
|
|||
| <template tid="RuntimeProperties"> | |||
| <data name="ClrInstanceID" inType="win:UInt16" /> | |||
| <data name="TrustedPlatformAssemblies" inType="win:UnicodeString"/> | |||
There was a problem hiding this comment.
There is nothing Trusted nor Platform about these. Should we use this as an opportunity to come up with more sensible name that does not need 5 minute explanation?
There was a problem hiding this comment.
I agree, we should choose a better name, since it is just a list of assemblies from which we resolve dependencies by default. I spoke to @richlander about this, he said he'll suggest a better name.
There was a problem hiding this comment.
I have heard about the TPA list for many years, but I don't know how it fits into frameworks and other .NET Core-isms. Can you describe what it means to you?
There was a problem hiding this comment.
- Is is a list of assemblies that the application is composed of.
- It is a list of assemblies that are (logically) pre-loaded into default assembly load context.
Some naming ideas: Assemblies, DefaultAssemblies
There was a problem hiding this comment.
Good suggestions. Those help. They are also a bit misleading. For example, DefaultAssemblies doesn't align with the default AssemblyLoaderContext. That would be confusing to me.
When a dependency needs to be resolved from a non-default ALC by the default ALC, I assume assemblies other than the TPA ones would be candidates. Is that right?
I take it that the TPA is basically the set of "pre-bound assemblies." How about ApplicationAssemblies.
There was a problem hiding this comment.
When a dependency needs to be resolved from a non-default ALC by the default ALC, I assume assemblies other than the TPA ones would be candidates
Maybe I'm missing what you mean by this, but if the default ALC needs to resolve a dependency that is not on the TPA list, the runtime would not know where to look for that assembly? The user would need to have added some sort of event handler (AssemblyLoadContext.Resolving or AppDomain.AssemblyResolve) to do the resolution themselves.
There was a problem hiding this comment.
When a dependency needs to be resolved from a non-default ALC by the default ALC, I assume assemblies other than the TPA ones would be candidates. Is that right?
When an assembly is loaded into non-default ALC, the ALC's load method tries to resolve the assembly using custom logic in its Load() overrides. If the assembly cannot be resolved that way, the resolution defers to the default-ALC, which tries to resolve the assembly using the TPA list. So, the TPAs are closely associated with the default-ALC.
How about
ApplicationAssemblies.
ApplicationAssemblies sounds like a good name, because typically the application's assemblies are loaded into the default-ALC, while the plugins are loaded into custom-ALC.
There was a problem hiding this comment.
I think @elinor-fung used the term DefaultAssemblies in the other PR, which I actually like better. There are two sets of assemblies which are typically present in the TPA:
- The frameworks
- Application assemblies
Both are equally important when dealing with plugins and such. Calling it just ApplicationAssemblies might mean to someone that it's just the app stuff, not the shared frameworks.
But it's still much better than TPA :-)
|
Do we have an idea what this logging will look like if/once we implement https://github.com/dotnet/core-setup/issues/7112 ? |
|
cc @vitek-karas |
|
This PR hasn't seen any activity in 3 months. It's still in progress? When do we expect it to be moved forward? Thanks. |
|
I was planning to come back to this in a couple of weeks, after my current stream of work. |
ghost
locked as resolved and limited conversation to collaborators
As part of dotnet/core-setup#4112, this change adds the RuntimeProperties event.
This event during fired on startup, and publishes all properties passed by the host to the runtime.
Known properties are explicitly called out by the event template.
Other properties are accumulated into the "Others" string.
Currently, due to EventPipe’s attach only nature, a test using event-pipe may miss the event.
So, this change doesn't include an automated test.
The recommended method for testing the event was using ETW.
I'll send out a PR to the PerfView repo to add this event to TraceEvent.