Cannot hit breakpoints with Realm 4.2.0 in Xamarin.Android project

[tipa]

Goals

Use Nuget package Realm 4.2.0 in a Xamarin.Android project

Expected Results

I can debug the project and hit breakpoints

Actual Results

The app is not debuggable / is not hitting breakpoints

Steps to Reproduce

The problem was introduced with Realm 4.2.0

Code Sample

Example project: RealmDebuggerProblem.zip

Likely important:
The "debugging information" dropdown in the project properties jumps back to "Embedded" even though "Portable" or "Full" were selected previously (and that value is still correct in the .csproj file):

Version of Realm and Tooling

Android Target version: Android 10 / Q
Xamarin.Android: 10.0.3
Vistual Studio 16.3.4

[nirinchev]

Interesting... I wonder if the Fody 6 upgrade broke that. I'll need to play around with it and confirm that suspicion.

[ibrahimmd90]

same problem in Xamarin.iOS, breakpoints are not hit after upgrading to 4.2, going back to 4.1 solved the problem.

[XDarinor]

I can also confirm this issue on my build on Android and iOS. Going back to Realm 4.1.0 solved the issue. Same on Visual Studio for Mac and Visual Studio 2019. No way to let beakpoint hit with Realm 4.2.0

[fkbeys]

i m having same problem too. i had to downgrade the realm version to 4.0.0 then it s working.

[barrysohl]

Same problem for us, on both iOS and Android. Downgrading to 4.1.0 resolves the issue. Fody definitely seems to be the cause. In fact, folks that know far more about this than me suggested that Fody's use of an outdated Mono.Cecil could be the problem.

[takeshik]

I'm in trouble by this issue too. And I perhaps found a workaround of this problem. Add this to bottom of the elements of <Project> in .csproj:

<Project ...>
  <!-- blah blah blah -->
  
  <!-- Add this -->
  <PropertyGroup Condition="'$(Configuration)'=='Debug'">
    <DebugType>portable</DebugType>
    <_DebugSymbolsProduced>true</_DebugSymbolsProduced>
  </PropertyGroup>
</Project>

Without attaching, stacktrace doesn't have source path and line number yet. But when I run Xamarin.Android app on debugger, breakpoints are hit and I could debug the code.
It's very dirty workaround, so I hope the problem is completely solved.

[nagzso]

I'm in trouble by this issue too. And I perhaps found a workaround of this problem. Add this to bottom of the elements of <Project> in .csproj:

<Project ...>
  <!-- blah blah blah -->
  
  <!-- Add this -->
  <PropertyGroup Condition="'$(Configuration)'=='Debug'">
    <DebugType>portable</DebugType>
    <_DebugSymbolsProduced>true</_DebugSymbolsProduced>
  </PropertyGroup>
</Project>

Without attaching, stacktrace doesn't have source path and line number yet. But when I run Xamarin.Android app on debugger, breakpoints are hit and I could debug the code.
It's very dirty workaround, so I hope the problem is completely solved.

I have just tried this workaround and it works. Breakpoints are hit in Xamarin.Android project.

Edit: It also works with <DebugType>full</DebugType>

[tomerdomshlak]

Downgrading to 4.1.0 solved the issue here.

[Dids]

@nirinchev Might've found where this issue comes from, and it seems to be the Realm.Fody package that's the culprit.

I'd been wondering why breakpoints haven't been hitting for a while now, but finally figured out why. In short, Realm.Fody has a dependency on FodyHelpers, which apparently causes this issue, where it sets all DebugTypes it finds to embedded, which Mono doesn't support.
I'm not sure where and why Realm is using FodyHelpers, but simply removing it should be enough to fix this, as then Fody would no longer touch DebugType.

Sources:

• https://developercommunity.visualstudio.com/content/problem/825905/xamarin-development-breakpoints-not-hitting.html
• FodyHelpers.props DebugType problem for crossplatform Fody/Fody#774
• https://github.com/Fody/Fody/blob/master/FodyHelpers/build/FodyHelpers.props

[fealebenpae]

Folks, could you please give these packages a go to see if they fix the issues for you? They're built off of #1927.

[nagzso]

Folks, could you please give these packages a go to see if they fix the issues for you? They're built off of #1927.

I have just tried the Realm nuget package and it works! All the breakpoints were hit in debug mode.
We don't use Realm.Fody so I can't say anything about it.

[RealmBot]

➤ Unito Sync Bot commented:

Transition made by Unito

[RonnyBansemer]

When did you plan to release a fix for this issue existing more than three months? Not as @nagzso wrote, the issue seems to exist in normal Realm 4.2.0 package, too. But it only affects the Xamarin.Android project itself (Xamarin.iOS not tested). Debugger hits all breakpoints in netstandard2 projects using Realm 4.2.0 nuget package.

[nirinchev]

There are prerelease packages linked earlier in the issue that address the problem.

[krisztiankocsis]

I think the biggest problem is that it makes the normal development process / debugging unusable. From my point of view, it makes sense to release a hotfix version (e.g. 4.2.1), even only with this fix. After that nobody will complain here.

What do you think about this?

[RonnyBansemer]

@nirinchev Thanks, but we only use stable packages for our development, so pre-releases are not visible by default. Starting to mix stable and unstable packages is in my opinion not a good solution at all. I (and I think a lot of other developers as well) would be very grateful when releasing a hotfix as @krisztiankocsis mentioned.

[nirinchev]

I agree, there's no legitimate reason to not release the hotfix. Just pointing out that if it's a major annoyance, you can temporarily use these packages. They are as stable as the hotfix will be.

[barrysohl]

I would definitely consider not being able to use the debugger on a large project to be a major annoyance.
Unfortunately, these are the type of issues that really reaffirm how much Realm is just not enterprise caliber yet (the handling of the QBS situation being the prime example). We have been long time Realm advocates, and leveraged it heavily in a large project, but were forced to move away from it at the 11th hour.