Unable to find an entry point named 'sentry_options_new' in DLL 'sentry'

[dbruning]

Environment

How do you use Sentry?
Sentry SaaS (sentry.io)

Which SDK and version?
.NET 3.8.2

Steps to Reproduce

1. My app was already using Sentry for .NET
2. Added a call to SentryMinidump.Init(), as per the sample program.cs
3. Ran my app

Expected Result

App would run

Actual Result

App exited immediately, with message: Process finished with exit code -532,462,766."
If I debug, I see that an exception is thrown by SentryMinidump.Init():
System.EntryPointNotFoundException: Unable to find an entry point named 'sentry_options_new' in DLL 'sentry'.
at sentry.sentry.__Internal.SentryOptionsNew()

If I look at my app's bin directory, I can see that sentry.dll is 359KB and has version 3.8.2.0 (and Date Modified of 7/17/2021)
If I look in the sample app's bin directory, it has sentry.dll with no version info and with size 204KB (and Date Modified of 12/27/2020)

I must admit I'm not clear on the relationship between Sentry.Minidump and Sentry nuget packages. Do I need them both, or does Sentry.Minidump replace Sentry package? If I need them both, what order should the Init's occur?

Thanks!

[bruno-garcia]

I must admit I'm not clear on the relationship between Sentry.Minidump and Sentry nuget packages. Do I need them both, or does Sentry.Minidump replace Sentry package? If I need them both, what order should the Init's occur?

This project is not a replacement to Sentry NuGet package. That's the official .NET SDK while this project is a .NET wrapper to sentry-native so you can conveniently initialize it without having to deal with P/Invoke.

It seems you've hit a limitation we have in combining both packages: The .NET SDK includes a Sentry.dll managed DLL. And this package include a sentry.dll native DLL. Ultimately the build system brings them both on the same directory and since Windows file system is not case sensitive, one overrides the other. That explains the error you had EntryPointNotFoundException.

I believe the best way around this would be for us to compile it as sentry-native.dll and ship it as such inside this NuGet package but sadly no bandwidth to make this change right now. Is this something you could contribute with a PR?

This came up before in this issue on the sentry-native repo.

One of the proposed solutions there was:

Another approach might be moving the .NET dll to a subfolder and using AppDomain.CurrentDomain.AssemblyResolve to intercept the calls and find the managed Sentry.dll in the subfolder. Or another .NET specific approach to load the Sentry .NET SDK.

[dbruning]

That makes sense, thanks for the info. I might be able to help with a PR but I need to understand a bit more architecturally first.
Why does this package need to wrap sentry-native? Could this package not just wrap Crashpad directly?

[bruno-garcia]

That makes sense, thanks for the info. I might be able to help with a PR but I need to understand a bit more architecturally first.

Sounds great. Happy to help with this part.

Why does this package need to wrap sentry-native? Could this package not just wrap Crashpad directly?

The original idea was to expose more functionality, for example passing additional options like Release and Environment but as a first release I just basically added "init". At its current form it's basically just crashpad correctly configured to upload to your Sentry project (since sentry-native deals with parsing DSN, etc.

[dbruning]

I found this document suggesting that it should be possible to have the runtime create a minidump if the app crashes, by setting an environment variable. I tried that for my WPF app - it wasn't successful, so I logged a WPF issue to ask if it should have worked.
There's also some discussion about not requiring the environment variables in future. I'm going to wait and see how that discussion pans out, because for my usage that would be better than shipping with Crashpad.

I'm also investigating whether I can use Windows Error Reporting (WER) to have Windows automatically capture dumps. That's a mechanism that already exists, so feels preferable to me than wrapping with something like Crashpad.
If I can get WER to capture dumps for me, it would be cool if Sentry could integrate with WER to pull dumps into Sentry automatically. That would make a library like this one unnecessary (or at least less necessary & at least on Windows).

[bruno-garcia]

Latest versions of .NET include minidump support that include the memory sections needed by managed extensions such as sos. So Crashpad is anyway not a good option if you want to get the managed stack traces too. For that reason after creating this experiment, I raised: #1. The goal would be for this package to use the native .NET tools and simply upload the minidump to Sentry from the device.

I'm not too familiar with WER. Does it include APIs to connect/auth and pull minidumps from it? Does the device need to be opt'ed in to create minidumps for crashes?

[dbruning]

I'm not familiar with WER yet either. I'm trying to register my app to work with it, it's not exactly straightforward.
I don't think the device needs to be opted-in; the application needs to be opted in. The device can be opted out via policy settings apparently.
As the developer wanting access to WER reports from your application, you need to register and the sign a file they provide, with the same code-signing cert you use to sign your app, to prove that the app belongs to you.
I had a look for API's just now, couldn't find any mention of them, and I get the feeling they don't exist. So WER-Sentry integration probably isn't possible.
Thanks for updating #1, I'll continue the discussion there.