Description
When EventSourceSupport MSBuild property is set to true, the build currently errors out. It is possible to bypass this by setting _SuppressNativeLibEventSourceError property to true but there are known issues. It is not recommended to ship native libraries like this unless one can make sure no other native library (or a CoreCLR instance) with EventSourceSupport gets loaded into the process. Users might consider shipping two versions of their native library DLL and only use the one with EventSourceSupport enabled when troubleshooting a specific issue.
This is a tracking uber issue that groups the known existing problems:
- Define and implement behavior of NativeAOT EventPipe IPC if there's already another runtime in the process #88087
- (Windows only) EventPipe hangs with a shared NativeAOT library #89346
Our guidance for EventSource/EventPipe with native AOT shared libraries is as follows,
- Only use the
EventSourceSupportenabled when troubleshooting a specific issue related to shared libraries. - Any native AOT console with
EventSourceSupportenabled will always win even if the process has other native AOT shared libraries withEventSourceSupportenabled. - If there are multiple native AOT shared libraries present in a single process, then the first shared library that gets loaded will
winto emit traces. Traces from other libraries will not be seen. - [Windows] When collecting tracing in a shared library, collection should stop earlier in the application (only collect for a specific time period or use the ctrl-C option with a tool like dotnet-trace when the interesting traces are collected). Specifically, in windows, the image unload event for a shared library (or at process exit), will not make a call to shut down the
EventPipein an orderly manner, causing a corrupted trace file.
Given these challenges, it's probably best to keep the current warnings we have for shared library around EventSource support.
Metadata
Metadata
Assignees
Type
Projects
Status