Xamarin Android 7.3.0 breaks debugging

JustinTothJustinToth USMember ✭✭

I just upgraded to Android 7.3.0, and now no breakpoints are hit in my app. I tried cleaning my project, rebuilding, restarting xamarin studio, even restarting OSX, but no luck. Has anyone else seen this? I'm about to downgrade back to 7.2.0, this new version doesn't seem to be ready for primetime...

Posts

  • flchauxflchaux FRMember ✭✭

    Same bug here after the 7.3.0 upgrade.

  • JustinTothJustinToth USMember ✭✭

    The strange thing is that even after downgrading to 7.2, I still can't debug. Does downgrading work for you?

  • vardthomasvardthomas UMMember

    I'm getting the same thing. Unable to hit breakpoints after upgrading to VS 15.2 yesterday. I'm one Win10 though. It seems to be a platform agnostic issue.

  • TheGX2TheGX2 USMember ✭✭

    Same here. Can't debug Android after upgrading.

  • ClaudioRediClaudioRedi USMember ✭✭

    Same here, installed visual studio to give it a try and good bye Android debugging... how this can make it to the stable channel?

  • voidvoid DKBeta ✭✭✭

    @ClaudioRedi said:
    .. how this can make it to the stable channel?

    Microsoft Build 2017.

  • ClaudioRediClaudioRedi USMember ✭✭
    edited May 2017

    This seems to be related to mono 5.0 https://bugzilla.xamarin.com/show_bug.cgi?id=56231

    Solution (from Brendan Zagaeski )

    Alternate possible temporary workaround for users who have hit this issue after updating (as opposed to a fresh install on a new machine)

    (For users who might wish to continue to use Xamarin Studio 6.3 for a little while before transitioning completely to Visual Studio for Mac.)

    1. Set "Project > Active Runtime" to "Mono 4.8.0 (8f6d0f6) (/Library/Frameworks/Mono.framework/Versions/4.8.0)".

    2. Rebuild the Android app project.

    Explanation

    By default the Mono 5.0 installer will leave the Mono 4.8 tools installed alongside the new Mono 5.0 tools. When the Xamarin.Android build process runs under Mono 4.8, it will generate the old .mdb debugger symbol file format for user assemblies, so the Xamarin Studio debugger will be able to use those symbols. Do note though that the framework debugger symbols files for Xamarin.Android are all shipped as portable .pdb files starting with Xamarin.Android 7.3, so stepping into framework code (as opposed to user code) still would not work as expected.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited May 2017

    Bugzilla cross-reference

    (Thanks to Justin for the bug report to help raise visibility to the Xamarin engineering team as a suspicious behavior after the update.)

    Some information from the bug report so far

    The first recommended step to try to resolve this issue would be to update to Visual Studio for Mac for compatibility with the new portable PDB debugging format that is used starting in Xamarin's "15.2 Release". A new version of Xamarin Studio has also just been published to the Stable channel that will show a dialog that recommends the update to Visual Studio for Mac. See the Xamarin 15.2 release blog post for some other information about moving to Visual Studio for Mac.

    Alternate possible temporary workaround for users who have hit this issue after updating

    (For users who might wish to continue to use Xamarin Studio 6.3 for a little while before transitioning completely to Visual Studio for Mac.)

    1. Set Project > Active Runtime to Mono 4.8.1 (22a39d7) (/Library/Frameworks/Mono.framework/Versions/4.8.1).

    2. Rebuild the Android app project.

    Explanation:

    By default the Mono 5.0 installer will leave the Mono 4.8 tools installed alongside the new Mono 5.0 tools. When the Xamarin.Android build process runs under Mono 4.8, it will generate the old .mdb debugger symbol file format for user assemblies, so the Xamarin Studio debugger will be able to use those symbols. Do note though that the framework debugger symbols files for Xamarin.Android are all shipped as portable .pdb files starting with Xamarin.Android 7.3, so stepping into framework code (as opposed to user code) still would not work as expected.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited May 2017

    Unable to hit breakpoints after upgrading to VS 15.2 yesterday. I'm one Win10 though. It seems to be a platform agnostic issue.

    This unfortunately sounds like a separate issue. The issue you are seeing might match Bug 56189, where it seems that the debugger symbols can under certain circumstances be mismatched with the source lines for library projects.

  • TheGX2TheGX2 USMember ✭✭

    I installed VS for MAC and Android is debuggable again for me.

  • MohamedElhefnawyMohamedElhefnawy USMember ✭✭

    Dear @BrendanZagaeski, When this issue will be solved ? is there due date to solve this issue ?

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @BrendanZagaeski switching Xamarin (globally) to Mono 4.8.1 is OK as a workaround, but we have multiple projects on our computers that all target different NuGet packages. Some we can't update at the moment because of other issues either in Xamarin itself or Forms or some dependencies that get in the way. But for the rest, which are compatible with Mono 5, we're now forced to downgrade them to Mono 4 as well.

    So it might be OK as a temporary stopgap, but we really need to be able to tie a project to a given version of Mono - otherwise we're going to get into a situation where we're backed into a corner we can't get out of. I updated Xamarin Studio yesterday to 6.3, which installed (and selected!) Mono 5 on my computer. But my Xamarin Forms DLLs are stuck at 2.0.something because a key part of Forms that we use is broken in later versions. So when I went to compile the project, I found this error about being unable to locate the .MDB file.

    I find it hard to understand how this can happen. It seems to me that if Xamarin is introducing a breaking change of any kind anywhere in the toolchain, this should be an opt-in feature rather than (as here) opt-out.

    I have been campaigning for as long as I have been using Xamarin for the entire development ecosystem to be sandboxed per version because of this kind of thing.

    This set of problems you guys are trying to solve is really hard and I would strongly prefer it if you were to take a more cautious approach. Xamarin people introduce a new feature that they think is going to be good for everyone, but there's always something that stops it from working perfectly on day 1.

    I can't tell you how stressful it is to be in an environment where any update we do to try and improve our software tools also risks breaking something really fundamental like this one did. Here's the thing:

    Without changing a single line of code my project went from "working" to "broken".

    If the new features had been "opt-in" as I would prefer, we could systematically turn them on one by one and establish very easily whether our code is compatible with the new shiny. As it is, we are left completely in the dark and utterly helpless to diagnose the failure. Moving back down a version after an update is such a painful process that I'm surprised you're still recommending it as a solution to anything.

    With a properly sandboxed development toolchain, this kind of problem would be impossible. I realise it would eat up lots of disk space, but disk space is way cheaper than my + your time and energy (not to mention stress) sorting out this kind of "shouldn't happen" problem.

Sign In or Register to comment.