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.
bruno-garcia
commented
5 years ago
By default in the .NET SDK all modules are considered
InAppso displayed in Sentry (as opposed to hidden) by default except for those inInAppExcludeoptions. That works well OOTB because most common namespaces when building .NET apps areSystemandMicrosoftand 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 theInAppExcludeprocessing 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.