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
Issue description
Developers can also use feature switches to get additional size benefits when they trim an application. One such feature switch is turning off generated events from an application (through the feature switch, EventSourceSupport) which can be confusing to consumers of the applications since event support has been always present in .NET applications. For example, a customer using dotnet-trace on the trimmed application that has this feature switch turned on (set to false) will not get expected behavior from the application.
We don't expect mainline server scenarios to use this feature switch but for those who do (primarily client side applications looking to run in size constrained environments), documenting the impact is an important strategy we plan to adopt for end-users to check when their .NET application doesn't generate events. This issue comment discusses the planned behavior but a high level overview is the message quoted in that issue, "if you do X, all events will be disabled". We plan to fix our diagnostics tools (for example, see this issue where external tracing tools will get some notification of events being turned off) but as mentioned above, documentation of the behavior is a critical part for users.
Target framework
.NET
[Edited to add document details]
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
ID: a1a6f297-c659-3770-42d9-d277895b5d25
Version Independent ID: 3061aedd-2264-90da-b244-b8ed7bf416fc
Issue description
Developers can also use feature switches to get additional size benefits when they trim an application. One such feature switch is turning off generated events from an application (through the feature switch, EventSourceSupport) which can be confusing to consumers of the applications since event support has been always present in .NET applications. For example, a customer using dotnet-trace on the trimmed application that has this feature switch turned on (set to false) will not get expected behavior from the application.
We don't expect mainline server scenarios to use this feature switch but for those who do (primarily client side applications looking to run in size constrained environments), documenting the impact is an important strategy we plan to adopt for end-users to check when their .NET application doesn't generate events. This issue comment discusses the planned behavior but a high level overview is the message quoted in that issue, "if you do X, all events will be disabled". We plan to fix our diagnostics tools (for example, see this issue where external tracing tools will get some notification of events being turned off) but as mentioned above, documentation of the behavior is a critical part for users.
Target framework
[Edited to add document details]
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: