locked
Is the debugger getting worse? RRS feed

  • Question

  • User435 posted

    Hi,

    I have been putting up with the debugger for some time, but now it seems that the Xamarin Studio debugger, especially when dealing with the iOS simulator, though the device has its issues too, has been getting worse. It seems that 70% - 90% of the time when launching my application the debugger loses its connection and then I have to retry. Often it starts on the second go but may still need a couple tries to get it to "stick" so I can actually run my application.

    More recently I have been running into issues, on occassion but more frequently than before, where variables stay evaluating when I try to inspect them. In some cases when I am trying to step through the code a dialog pops up asking me to either wait or stop. It seems that often it is getting stuck on .ToString() calls which is what the debugger is saying even though the code isn't executing a .ToString() at the time. I assume this is to get details about object.

    I have a a couple apps and they both do this. They are both map heavy and I have always had the "feeling" that perhaps it has something to do with the map initializing though I don't have an evidence of this.

    Anyone else noticing issues like this?

    Cheers, Clint

    Wednesday, February 26, 2014 4:02 PM

Answers

  • User181 posted

    I have never had a good experience with the Xamarin debugger. It sometimes causes the app to hang on launch, randomly detaches itself, crashes the app and/or itself, interprets "step over" or "step out" as "continue", breaks in the wrong location, refuses to break at all in certain places, etc., etc. I often have to resort to printing to the console.

    This is one of many examples of large, glaring problems that Xamarin seems to be ignoring in favor of developing big shiny new features. While I like the idea of making Xamarin Studio look nicer and having a fancy new UI editor, in my every day life Xamarin could help me way more by getting the things they already do to work reliably every day first.

    • Marked as answer by Anonymous Thursday, June 3, 2021 12:00 AM
    Wednesday, February 26, 2014 4:59 PM

All replies

  • User181 posted

    I have never had a good experience with the Xamarin debugger. It sometimes causes the app to hang on launch, randomly detaches itself, crashes the app and/or itself, interprets "step over" or "step out" as "continue", breaks in the wrong location, refuses to break at all in certain places, etc., etc. I often have to resort to printing to the console.

    This is one of many examples of large, glaring problems that Xamarin seems to be ignoring in favor of developing big shiny new features. While I like the idea of making Xamarin Studio look nicer and having a fancy new UI editor, in my every day life Xamarin could help me way more by getting the things they already do to work reliably every day first.

    • Marked as answer by Anonymous Thursday, June 3, 2021 12:00 AM
    Wednesday, February 26, 2014 4:59 PM
  • User49366 posted

    With the latest Xamarin Studio 5.8.3 on OSX, targeting an Android device, more than 50% of the time the debugger loses its connection as soon as the app starts when I try to debug my app.

    Saturday, April 11, 2015 1:09 PM
  • User57638 posted

    Noticing the same issues. I can't even connect the debugger to my device anymore and with the simulator it doesn't hit breakpoints 50% of the time and when I restart I get an error that the debugger was unable to terminate one or more processes.

    Very frustrating

    Monday, April 13, 2015 1:58 PM
  • User42331 posted

    Trying to debug in the simulator works maybe 1/5 of the time for me. 3/5ths of the time the simulator goes to a black screen and crashes (no stack traces or anything, Xamarin Studio just quietly turns the stop button in the top left back into a go button). Another one fifth of the time the app will launch normally but crash silently not long after. Debugging on the device is generally a lot more stable.

    There are regions of code where I've learned not to put breakpoints, because they will crash the debugger. I've learned that if I have a resolved breakpoint in a certain place and that breakpoint does not get hit, that doesn't necessarily mean that the code didn't execute. The immediate window often can't tell me the value of something that's clearly in scope, and occasionally gives me a different value than a writeline in the same place.

    Monday, April 13, 2015 2:30 PM