-
-
Notifications
You must be signed in to change notification settings - Fork 120
DllNotFoundExceptions and SecurityException when using with Mono #278
Comments
It's trying to get .NET Framework installation through The code does have a guard: raven-csharp/src/app/SharpRaven/Utilities/RuntimeInfoHelper.cs Lines 40 to 43 in 952adea
Could you please describe your app a bit? what version of the framework you are using? |
I guess I haven't seen this again. |
That's good to know. |
I already explained in some other github issue I think: doesn't have Xamarin.iOS support. |
There was an update to that thread because of other customers reporting they use it with Xamarin iOS and Android but if things are working fine for you as is, makes sense to stay. I hope we get to focus on Xamarin for a bit to make sure the experience is good. Likely releasing |
Exactly, especially taking in account that sentry-dotnet seems to only be better than raven-csharp in one aspect: storing exceptions when app is offline, to send them later. IMO this is a feature that I would rarely benefit from. Make sentry-dotnet more compelling, and I might evaluate it myself on Xamarin platforms. |
I believe you think there's no compelling feature then because offline mode is not there yet. We would do that as part of the Xamarin support. IMHO (a bias one) there are many reasons to change. Main ones I can think of are:
I understand many of those do not apply to you. I'm still trying to push to get proper Xamarin support (send device data automatically etc) in which case I'll be updating that other issue and hopefully have a compelling reason to have you move over. |
Hey I've seen this issue again, it should be reopened. Can we get a hotfix? If running on Linux it should not call |
New stacktrace:
|
I think this is the more narrowed culprit:
|
Hi @knocte The first stack trace seems to hit It happens here: raven-csharp/src/app/SharpRaven/Utilities/RuntimeInfoHelper.cs Lines 39 to 44 in 952adea
Finally, it seems this just gets logged out to console but no crash happens, is that correct? raven-csharp/src/app/SharpRaven/Data/Context/Runtime.cs Lines 91 to 101 in 952adea
|
Ubuntu 18.04 LTS
F# desktop app on Linux running Mono 6.6.0.161
How can I know that?
Yes true, but the error is not sent to Sentry. |
@knocte Have you tried the |
In other words, what's blocking you to move over to the new SDK where it's more active development and bugfixes etc? |
I'd like to move/test that for separate reasons than this bug which should be simple to fix. |
@bruno-garcia can you reopen this please? |
Hi @knocte I'm happy to merge a PR and make a release for this. Are you using Xamarin.iOS? Also Xamarin.Android? |
@knocte, I cannot reproduce the test failures with either Runtime, Device or OperatingSystem on my local build of the develop branch (updated with Cake 0.37, see PR #283) For OperatingSystem, the error in the trace above is in I am testing that function using
If you look at the OperatingSystemTests.cs, it does call I also tried with the net35 version, it still works. (tests pass) The same applies to Device, which I have tested using
The same also applies to Runtime, which I have tested using
I also tried swapping out my built Can you reproduce the failure by running the test? Maybe it fails if you build on Windows and use the built dll on Mono, or something? |
@ysangkok did you try to reproduce this problem exactly how it's explained in the first comment? That is, throw an exception somewhere in the app (after the SharpRaven event subscription happens), push your change to some branch, let gitlab generate an artifact, grab those artifacts and try to run the app in Ubuntu 18.04. |
Last git tag in this repository is 2.4, which matches with the nuget package last version: 2.4.0. The last commit in this tag is in May2018 so there's a chance that the develop branch maybe has a fix for this that has not been released? try building this tag to confirm...
Actually, first thing I would try is reproducing the problem from the nuget package, not with a local build. After you have reproduced it with the nuget package, try a local build to fix it, however, if with a local build you cannot reproduce it, there's a high chance that the culprit is because, I'm guessing, the nuget package gets built & uploaded from a Windows box. So maybe there's some behaviour in this lib that is determined by the OS/Platform that is being built from, instead of run from? |
As mentioned, i have also tried with the released 2.4.0 dll. Regarding doing subscriptions first, i don't understand how that could make a difference since we are talking about exceptions in static initializes that depend on build flags. So the thing to ensure is that the right build flags are getting set. I will try building on Windows and testing that build on mono. |
With this, I mean, very specifically, this method being called first: https://github.com/nblockchain/geewallet/blob/master/src/GWallet.Backend/Infrastructure.fs#L85
I don't understand what you mean by this ^ |
Sorry, what build flags? If this behaviour is based on build flags, then this is actually the culprit. SharpRaven should detect, at runtime, not at compile time, in which environment it's on. |
Don't try that yet. You have to try with the 2.4.0 nuget but if with |
yes
if you look at Device.cs, it only calls into InteropServices.RuntimeInformation if the preprocessor flag HAS_RUNTIME_INFORMATION is set. |
Ok, this means that the environment where SharpRaven's nuget package is built, that build flag is defined, so? Not sure what you're getting at. I don't think you can work on this problem until you've reproduced it with the nuget pkg. Did you try console-frontend or GTK? if the former, try the latter. |
rereading your messages, it seems you have only tried running unit tests? please try the real thing, running geewallet (first console frontend, if that doesn't bomb, try the GTK frontend after) |
which mono version are you testing with? |
Mono 6.6.0.161, as said in #278 (comment) My gut feeling is that the way to fix this is something like this diff that I'm just creating by hand:
|
My gut feeling is that the way to fix this is something like this diff that I'm just creating by hand:
That is not fixing fixing the root cause, it is just changing out the mechanism which the library uses to select the implementation to a optimistic Exception based approach, giving on up compile time flags altogether. While it might work, it is changing a major component of how the library works, and should be done consistently across the whole codebase instead of just here.
|
Why do you think compile time flags are important? The nuget is built in some cloud computer we don't know/care about, and then that binary is the one consumed by all the platforms; therefore these kind of checks have to be done at runtime, not at compile time.
This library is deprecated, so no big changes are going to be allowed. I say we apply this patch for the case we know it's crashing for us. |
When testing my app in Ubuntu 18.04, I've seen these stacktraces when SharpRaven apparently tried to send reports to Sentry:
The text was updated successfully, but these errors were encountered: