You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In NativeAOT, EventPipe library is not included by default in applications due to size considerations. This means that when applications enable EventSource support, developers have a choice to include this library as shown in the table here. .NET applications do not have this option since EventPipe library is always included in .NET.
There could be cases where developer might just want to get in-proc events and do not need to enable EventPipe library since they do not need these events sent out-proc (to listening clients like dotnet-trace) or want to keep their application size small while getting some event data. Currently in NativeAOT, the only option for EventSource support is also to include EventPipe library. This is due to existing code that is shared with CoreCLR do not distinguish between managed/native separation when EventSource support is enabled and calls the EventPipelibrary.
We need to do the following in NativeAOT
Pick the right default for EventPipe library support when EventSource support is enabled.
Fix the existing issue when EventSource is enabled and EventPipe is disabled. The work should also include the current code we have that assumes EventPipe can be disabled when EventSource is enabled. For example, removing methods in DisabledEventPipeInternal.cpp
The text was updated successfully, but these errors were encountered:
In NativeAOT, EventPipe library is not included by default in applications due to size considerations. This means that when applications enable EventSource support, developers have a choice to include this library as shown in the table here. .NET applications do not have this option since EventPipe library is always included in .NET.
There could be cases where developer might just want to get in-proc events and do not need to enable EventPipe library since they do not need these events sent out-proc (to listening clients like dotnet-trace) or want to keep their application size small while getting some event data. Currently in NativeAOT, the only option for EventSource support is also to include EventPipe library. This is due to existing code that is shared with CoreCLR do not distinguish between managed/native separation when EventSource support is enabled and calls the EventPipelibrary.
We need to do the following in NativeAOT
Pick the right default for EventPipe library support when EventSource support is enabled.
Fix the existing issue when EventSource is enabled and EventPipe is disabled
In
NativeAOT
,EventPipe
library is not included by default in applications due to size considerations. This means that when applications enable EventSource support, developers have a choice to include this library as shown in the table here. .NET applications do not have this option since EventPipe library is always included in .NET.There could be cases where developer might just want to get in-proc events and do not need to enable
EventPipe
library since they do not need these events sent out-proc (to listening clients like dotnet-trace) or want to keep their application size small while getting some event data. Currently inNativeAOT
, the only option forEventSource
support is also to includeEventPipe
library. This is due to existing code that is shared withCoreCLR
do not distinguish between managed/native separation when EventSource support is enabled and calls theEventPipe
library.We need to do the following in NativeAOT
EventPipe
library support whenEventSource
support is enabled.EventSource
is enabled andEventPipe
is disabled. The work should also include the current code we have that assumes EventPipe can be disabled whenEventSource
is enabled. For example, removing methods in DisabledEventPipeInternal.cppThe text was updated successfully, but these errors were encountered: