dsym and Xamarin.iOS
uioporqwerty
Posted on
Jan 24 2021
I've seen this blog post from the Raygun team regarding native reporting and dsyms with Xamarin.iOS: https://raygun.com/blog/raygun-for-xamarin-ios-supports-unified-api-and-native-error-reporting/
It is a bit outdated as that API for attaching no longer exists, but we are currently reporting native errors. However our sample errors looks something like this:
System.Linq.Enumerable.Single[TSource](System.Collections.Generic.IEnumerable1[T] source, System.Func
2[T,TResult] predicate) in
So there are no line numbers or any good information here other than the class namespaces. If I generate a dsym file and upload it to Raygun, I'm not getting any more information. Shouldn't Raygun report the line number where that linq exception occurs? Am I supposed to upload dsyms for Xamarin.iOS apps and how much, if at all, would it deobfuscate the stack traces? Currently I generate the dsyms by adding the --dsym=true argument for my release build, build the app, zip up the dsym, upload it to Raygun, then generate a test error as above. I saw the following link under the Apple section that talks about why some more stack trace detail might not be available but is this relevant to Xamarin.iOS apps? https://raygun.com/documentation/language-guides/apple/crash-reporting/advanced-setup/#why-are-my-stack-traces-not-symbolicated
Deleted User
Raygun
Posted on
Jan 25 2021
Hi,
Thank you for getting in touch. The error you are referring to is actually an error report generated by managed code (C#) and not a native error (Objective-C). The dSYM files will only be applied to native iOS error reports that originate in Objective-C code. They will not be able to symbolicate the error report you are referring to.
Xamarin does not include line numbers in Release builds and we currently do not have the functionality to symbolicate Xamarin error reports originating in C# code. My recommendation would be to open a feature request in our forum (https://raygun.com/thinktank/forum/2) and we will be able to prioritise this work on our roadmap.
Thank you, Mitchell.