A way to disable "sentry-native"

[maxkatz6]

Problem Statement

We are developing a NativeAOT application. And as for now, native dependencies are linked into the main executable. It also adds additional dependencies to the application, which otherwise are not used.

Normally, it wouldn't be a problem, but we are getting reports from users with less common distributives, like Alt Linux:

/lib64/libcurl.so.4: version `CURL_OPENSSL_4' not found

Sidenote, I haven't found any information on what native dependency does. But I also haven't checked the source code yet.
If sentry-native is used as a cornerstone for sending message, this request might not be worth it. But having a fully managed sentry implementation is still nice.

Solution Brainstorm

MSBuild property like DisableSentryNative would be nice. But I don't know how it affects runtime usage yet.

[jamescrosswell]

Interesting. We leverage the Native SDK to capture errors with meaningful stack traces for native code.

It is possible to disable the NDK for Android applications. We don't yet have any way to disable the Native SDK for other platforms though.

Disabling the Native SDK might be the nuclear option... and we could look at adding a way to do that so that people could use it as a workaround in similar situations to this. It might be throwing the baby out with the bathwater though.

A more optimal solution might be to try to resolve the missing dependency on libcurl.

The Platform and Feature Support docs for the Native SDK mention this dependency:

HTTP Transport is currently only supported on Windows and platforms that have the curl library available. On other platforms, library users need to implement their own transport, based on the function transport API.

Potentially we could plug in the transport from the managed SDK then (so that libcurl was no longer required). @vaind does that sound feasible (just looking for a sanity check)?

[vaind]

Potentially we could plug in the transport from the managed SDK then (so that libcurl was no longer required). @vaind does that sound feasible (just looking for a sanity check)?

this means defining a custom transport in sentry-native that would depend on runtime-defined callbacks. Definitely feasible and not all that complicated, just a bit more complex because of the places that need to change. I'd consider sticking to the original proposal, i.e. disabling sentry-native, unless there's a really big incentive (e.g. considerable number of affected users? IDK, about priorities here) to have a custom managed transport.

Letting users disable sentry-native is pretty trivial on the other hand - just support a build-time option here:

sentry-dotnet/src/Sentry/Platforms/Native/buildTransitive/Sentry.Native.targets

Line 13 in 791db47

<FrameworkSupportsNative Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net8.0')) and ('$(OutputType)' == 'Exe' or '$(OutputType)' == 'WinExe')">true</FrameworkSupportsNative>

and probably a runtime option here:

sentry-dotnet/src/Sentry/Platforms/Native/SentrySdk.cs

Line 13 in 791db47

if (!C.Init(options))

However, @maxkatz6, I'd suggest not to include the option by default in your builds (as sentry-native is useful if users use native libraries and those crash) and only suggest it to users as an escape hatch if they fail to compile the library. Alternatively, you could check for the availability of the libcurl4 devel in the system and set it automatically if it's not - to provide the smoothest user experience at the expense of some users not having native crash reporting even though they could have, just by installing libcurl4-devel

[maxkatz6]

Another benefit of having a MSBuild parameter like DisableSentryNative is integration with feature switches. When such switch is disabled compile time, with trimming/aot enabled, compiler will remove all code blocks using this condition. Potentially removing a lot of unused code.

Note, AppContext.TryGetSwitch is supported on all target-frameworks Sentry uses. And FeatureSwitchDefinition can be conditionally included only on .NET 9 builds, where these are supported (or optionally polyfilled).

[maxkatz6]

However, @maxkatz6, I'd suggest not to include the option by default in your builds (as sentry-native is useful if users use native libraries and those crash) and only suggest it to users as an escape hatch if they fail to compile the library

In this context, it's not about our libraries, but about our tools/applications. And list of dependencies we use is controlled by us. Atm, there is no other native dependencies that might crash, other than .NET or OS itself. Since Linux takes a smaller segment of users, it would be easier to disable sentry-native for linux builds, while keeping it on Windows/macOS.