By default in the .NET SDK all modules are considered InApp so displayed in Sentry (as opposed to hidden) by default except for those in InAppExclude options. That works well OOTB because most common namespaces when building .NET apps are System and Microsoft and a handful others which are already hard coded in the SDK.
A user can add more namespace prefixes (e.g InAppExclude) when initializing the SDK.
To stay consistent with the unified SDK, we'll introduce InAppInclude. This way, even if the InAppExclude processing marked the frame as InApp=false, the SDK has a chance to inspect this list and revert it back to InApp=True.
This is helpful, for example when by default excluding a whole base namespace, like:
System (which is excluded by default) but including something more specific like System.MyCustomNamespace.
By default in the .NET SDK all modules are considered
InApp
so displayed in Sentry (as opposed to hidden) by default except for those inInAppExclude
options. That works well OOTB because most common namespaces when building .NET apps areSystem
andMicrosoft
and a handful others which are already hard coded in the SDK.A user can add more namespace prefixes (e.g
InAppExclude
) when initializing the SDK.To stay consistent with the unified SDK, we'll introduce
InAppInclude
. This way, even if theInAppExclude
processing marked the frame asInApp=false
, the SDK has a chance to inspect this list and revert it back toInApp=True
.Such code would follow this: https://github.com/getsentry/sentry-dotnet/blob/a9495f4e62e24092937e27c5257749778b23769f/src/Sentry/Internal/SentryStackTraceFactory.cs#L137-L142
This is helpful, for example when by default excluding a whole base namespace, like:
System
(which is excluded by default) but including something more specific likeSystem.MyCustomNamespace
.