How bad can it get?

NMackayNMackay GBInsider, University mod

The last stable VS studio release hangs the VS IDE after one compile, the subsequent Alpha release fixed that but you could no longer set a breakpoint.

In the stable release you still have no breakpoints rendering the product useless as you loose one of Xamarin's major USPs, iOS barely works now and is incredibly unstable but breakpoints work after a fashion.

There is a limit to peoples patience when your paying $1900. Seriously.......utterly fed up with Xamarin at the moment.

There seems to be a wall of silence from Xamarin, same applies for Forms.

Posts

  • MihaMarkicMihaMarkic SI ✭✭✭✭
    edited May 2015

    Hm, I don't have such issues at all (granted, not doing much iOS lately) being in beta channel.
    Don't misunderstand me, I'm not disputing your issues.
    I am curious - is this happening with blank projects? Something particular? Have a repro?
    Forms is another story :)

  • NMackayNMackay GBInsider, University mod

    @MihaMarkic

    Debugging seems to work in blank projects although that doesn't help me. I'll contact the support guys once I've calmed down a bit :smile:

  • HaithemHasniHaithemHasni CAMember ✭✭

    @NMackay did you manage to get an answer for your issue. I have the same problem here.

    Thank you.

  • JohnRowseJohnRowse GBMember ✭✭

    It is disgusting. Since Dec 2014 I have not been able to debug Async methods without the debugger losing connection and getting a frame error. Xamarin have confirmed the bug, and suggested 'use XS". Not what i paid for!

  • NMackayNMackay GBInsider, University mod
    edited May 2015

    @Haithem

    No, they suggested uninstalling everything and going back to Xamarin for Visual Stuidio ver 3.9.547. I'm pretty sure this version caused my issues with iOS compilation so I can't go down that route. It does work for new projects which should be a clue for them where to start looking. If I get a resolution I'll post it here but I think we're all in the same unhappy boat.

    @JohnRowse
    We're not interested in using Xamarin studio, we use Visual Studio for all our dev, even Telerik's app builder integrates (which we used before).

  • JohnRowseJohnRowse GBMember ✭✭

    I am not using XS either. I am just saying the situation is so bad, their own tech departement have to advise not using VS as the extention is failing like this.

  • NMackayNMackay GBInsider, University mod

    @JohnRowse

    Yeah, it's worrying.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    @JohnRowse What bug is that? I mean is it on bugzilla? Is there a simple repro?

  • JohnRowseJohnRowse GBMember ✭✭

    @MihaMarkic Yeah, it is here: https://bugzilla.xamarin.com/show_bug.cgi?id=25356

    There is a simple TestProject attached in the report. It mentions about how Async Void is normal use is bad, but it is just for testing (it happens with Async), and it was used for a click event anyway. The simplified test project was created by Brendan, who is happy the test is valid.

    An email stating their current status (over a month ago):

    Jon Douglas
    APR 08, 2015 | 01:18PM EDT
    Hi John,

    I do not have an update for this issue other than the fact that the bug has been confirmed by the team. It is also on an internal prioritization board. Other than that, the current workaround unfortunately would be to use XS until this is resolved. I really do apologize for the length of time on this bug, but I believe the issue is a bit more complicated than a simple fix for our VS team.


    When you read all the new features in the above threads, I always get the impression loads of new buggy feature development takes higher president than fixing the core platform, which is so disaapointing.

  • JohnRowseJohnRowse GBMember ✭✭

    (it happens with Async Task)

  • NMackayNMackay GBInsider, University mod
    edited May 2015

    Jeez.

    I'll have to debug in iOS in the interim. Breakpoint's still don't trigger in Android with the latest Alpha release.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    @JohnRowse Does it happen only with async void or with async Task as well?

  • JohnRowseJohnRowse GBMember ✭✭

    @MihaMarkic It happens with Async Task as well. Turning on every possible exception break type in VS helps somewhat, but then it brings its own set of issues. Try/Catch is ignored for example, so anything that causes this to catch, halts the debugger as if it had not been caught, so you are trapped not getting to the issue you are trying to debug further on in the code, untill resolved. Even then, as per @NMackay, hitting breakpoints is a bit hit and miss.

  • JohnRowseJohnRowse GBMember ✭✭

    @MihaMarkic lots of others are experience the same crippling issue too: http://forums.xamarin.com/discussion/27308/debugger-doesnt-work-frame-not-in-module

    For anybody readings these threads deciding whether paying the extra for VS extention; it is totally unusable. I wish Xamarin would admit they are not interested in fixing bugs, but chasing new money with new buggy features.

    @Brendan you never make any reference to any of the debugging issues (including the latest breakpoint issue), in your ongoing update of 'outstanding issues' in the recent updates... Are they even being looked at? I repeate, VS extention is pretty much unusable without debugging capabilities!

  • JohnRowseJohnRowse GBMember ✭✭

    @MihaMarkic lots of others are experience the same crippling issue too: http://forums.xamarin.com/discussion/27308/debugger-doesnt-work-frame-not-in-module

    For anybody readings these threads deciding whether paying the extra for VS extention; it is totally unusable. I wish Xamarin would admit they are not interested in fixing bugs, but chasing new money with new buggy features.

    @BrendanZagaeski you never make any reference to any of the debugging issues (including the latest breakpoint issue), in your ongoing update of 'outstanding issues' in the recent updates... Are they even being looked at? I repeate, VS extention is pretty much unusable without debugging capabilities!

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    At the moment, I am curating those bug lists by hand. I created the lists when the Xamarin.Android 5.1 release was first published to Alpha/Beta, and then have updated them based on customer replies in those threads. If you want me to see the report of issue, check on whether it's a regression, and follow-up on it, then please add a link to the bug report in the appropriate release thread (ideally the most recent thread where the problem can be observed). Thanks!

    All that said, I think there is some confusion here:

    1. I have discussed a related intentional breaking change in Xamarin.Android 5.1 several times in the release threads:

      • Due to the new Cross-VM Exception Propagation in Xamarin.Android 5.1, unhandled C# exceptions will by default not break on the original C# exception. They will instead break on a Java.Lang.RuntimeException, and the C# local variables will not be available at any position within the call stack. To access the local variables, you can do one of the following:

        • Set the IDE to break on all exceptions. This will allow the debugger to break on the original C# exception, but it also means the debugger will break on all other exceptions of the same type, even if they are handled.

        • Temporarily disable the new exception propagation by setting the XA_BROKEN_EXCEPTION_TRANSITIONS environment variable to true.

    2. The Bug 25356 that has been linked so far in this forum thread is not a regression, and therefore is unrelated to any changes seen in Xamarin.Android 5.1, and is not something I would attempt to track in the release threads (since that would eventually lead to duplicating the entire list of open bugs in Bugzilla on the release threads). Bug 25356 is a limitation of exceptions that has existed since at least Xamarin.Android 4.20, and (as far as I know) has always existed. In fact, the new exception propagation discussed in point #1 makes more unhandled exceptions behave in this same way by default (although as mentioned in point #1, there is a way to temporarily disable that new behavior) . I'm not entirely sure (I'm a member of the Support team, not a developer), but I believe the limitation with exceptions from async methods is a technical limitation due to the interoperation of the Mono runtime and the Java runtime. It is not self-evident that that limitation has a practical solution.

    3. The original topic of this forum thread was about breakpoints. Bug 25356 is about exceptions. Given points #1 and #2, it sounds like this issue with breakpoints might be the more interesting thing for the Xamarin QA team to investigate in this new release. The most direct way forward would be for someone who has seen the breakpoint problem to file a bug report. In particular, if anyone is hitting this issue fairly often and has an answer of "yes" to either of the "File a bug if..." questions on the bug filing KB article, please do file a bug report that follows the "best practices" from the KB article as far as possible. (If the KB article link redirects to the top-level kb.xamarin.com/ page the first time you click it, try clicking it once more.) When the bug report is ready, feel free to post a link to it in the appropriate corresponding release announcement on the forum. Thanks!

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    To make one slightly "wild" guess about the original problem with breakpoints, I have seen one non-public bug report (filed by the Xamarin developers themselves) described as:

    Xamarin.Android debugger won't hit unless Shared Runtime is used and Linker is disabled

    That issue was assigned directly to the developers to investigate, so the QA team didn't get a chance to check whether it was a regression. But since it was only reported recently, it seems at least possible that it could be a regression.

    As a related follow-up for folks on this thread who might be hitting the original topic of the thread about breakpoints not working, do breakpoints start working if you enable the Shared Runtime, and disable the Linker (the default settings for the "Debug" configuration on a new Xamarin.Android project)?

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    Right, linking has a real effect on debugging but without linking pretty much works, at least I haven't noticed any problems lately. It is good enough for me.

  • NMackayNMackay GBInsider, University mod

    @BrendanZagaeski

    Shared runtime is enabled and linker set to "None". Just tested with the latest Alpha.

    It's a Forms PCL solution. Interestingly breakpoints in App.xaml.cs and class ctors now fire but code with a command such as RelayCommand never triggers a breakpoint but it did pre 3.9x.

    public RelayCommand<Vessel> SelectCommand { get { return _selectCommand ?? (_selectCommand = new RelayCommand<Vessel>( ves => { try { if (!_selectCommand.CanExecute(ves)) { return; } _navService.NavigateTo(ViewModelLocator.PageKeyVesDetails, ves); } catch (Exception ex) { _dialogService.ShowMessage(ex.Message.ToString(), ResourceConstants.PopupDialogGeneralError, ResourceConstants.PopupDialogOkButton, null); } }, ves => ves != null)); } }

    Put a breakpoint in _navService.NavigateTo and it never triggers. As it's a XAML pure MVVM forms app RelayCommand is used extensively.

    Still some progress which I will feedback to the support & VS dev team who are helping me.

  • MihaMarkicMihaMarkic SI ✭✭✭✭
    edited May 2015

    @NMackay Just a note that here you are showing lambda, not async issues (nevermind that NavigateTo is an async method) as test project @JohnRowse mentioned. Would you mind creating a simple repro?

  • NMackayNMackay GBInsider, University mod

    @MihaMarkic

    Actually NavigateTo is not Async in this navigation service wrapper class I'm using.

    I have passed a repo project on to the Xamarin guys which will hopefully reproduce the issue I'm having. As it had some licensed components I can't share it publicly.

    I will feedback progress on this.

    Thanks.

  • JohnRowseJohnRowse GBMember ✭✭

    @BrendanZagaeski

    1) "The original topic of this forum thread was about breakpoints." No, this post was about "How bad can it get", regarding the state of the VS extension and lack of apparent support for it (until today). @MihaMarkic was pointing out his latest despair regarding it (if I am wrong about this Miha, please correct me for assuming), which was to do with breakoints.

    2) "It is not self-evident that that limitation has a practical solution.". Is that why an engineer originally marked the bug report as 'fixed' (see last comment in the report), as they had done it for the XS extension, and didn't realise it was also affecting the VS extension. As both use the same runtimes, I can't see how this is valid.

    3) "it sounds like this issue with breakpoints might be the more interesting thing for the Xamarin QA team to investigate" I am sorry that the bug is not interesting enough to warrant the attention, in your opinion. Do you speak for the whole of Xamarin on that one, and would it be shared at all levels within the company?

    Thankfully Ian from the VS team has stepped in, and by the sounds of it may help to get to the bottom of these ridiculous issues.

  • JohnRowseJohnRowse GBMember ✭✭

    i of course mean @NMackay pointed out (sorry Norman), regarding point 1.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @JohnRowse, ah ha. I think the one key piece of missing information is this: Bug 25356 is not specific Visual Studio. The test case from that bug behaves identically for me in the latest versions of both Xamarin Studio and Visual Studio (and, as far as I know, has behaved in that (admittedly unfortunate) way in all versions of Xamarin.Android). If you have a test case that behaves differently under Visual Studio compared to Xamarin Studio, then definitely feel free to file that test case on a new bug (and contact the support team via email to ensure it is properly prioritized) (if this link redirects to the top-level kb.xamarin.com/ the first time you click it, try clicking it once more).

    David's comments about "I'm closing this as duplicate" were unfortunately actually not directly related to Bug 25356. They were instead related to the new behavior for unhandled exceptions outside of async methods (i.e., the breaking change in Cross-VM Exception Propagation). That's one reason I included a snippet about that new propagation behavior in my previous reply. So his comments at the end of that bug will unfortunately only cause confusion when studying the async unhandled exception problem.

    this post was about "How bad can it get", regarding the state of the VS extension and lack of apparent support for it (until today)

    Fair point. I might have painted with slightly too broad of a brush in my previous reply or misunderstood NMackay's original intentions when he started this thread. I was mostly trying to offer some flavor for why Bug 25356 in particular would not have appeared in the release threads. The reason is that that bug is not a regression. In contrast, the issue described by NMackay's in the first post in the thread about breakpoints was described as a regression, so that would absolutely be the kind of thing I'd try to document in the release threads (as soon as possible after being made aware of it). The fact that it's a regression also means it's a bug that the QA team would want to prioritize to ensure we don't break something new in the next release.

    The bigger discussion of "how will Xamarin improve bug response times to ensure that bugs don't go inactive for many months?" is a more complicated question, and one that the Product Management team is actively working on. Hopefully that team might have some news to share on that front in the near future. My knowledge about that the details of that work is fairly limited since I'm a member of the Support team.

  • JohnRowseJohnRowse GBMember ✭✭

    @BrendanZagaeski agreed that originally it was affecting both, and your original report makes that clear. It was just that David suggested he [the team] had fixed it for XS (which i have no reason to doubt, as i never use it), but still affects VS. If this is not actually the case, then i stand corrected.

    You may also remember that you created the test project (which was v similar to mine). It obviously uses async. After living with this bug for so long, I have gone "debugger blind", and now I could swear it is not limited to async. If you take the async out of the test project, and turn it into a regular method, it still shows the "Frame not in module". I have so many async methods in my production project that it wasn't obvious at first, but i had to test a preview today and used the test project for it, and only when [attempting] confirming that async is the root cause, is it just happening full stop. Can you confirm the same behaviour when changing the method back to regular?

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited May 2015

    @JohnRowse, ah yup yup. I think we're on the same page now. Thanks to this discussion, I realized I should hide David's comments on Bug 25356 to prevent confusion in the future. I've taken care of that now.

    If you take the async out of the test project, and turn it into a regular method, it still shows the "Frame not in module" ... Can you confirm the same behaviour when changing the method back to regular?

    Indeed I can reproduce that behavior. In particular, if I remove async from the test case on Bug 25356, then I get the Cross-VM Exception Propagation issue. As a quick "hack" to avoid that problem when debugging unhandled exceptions, I've started using the following steps in my Android app projects:

    1. Add an Environment.txt (the file can have any name).

    2. Add the following line within the file:

      XA_BROKEN_EXCEPTION_TRANSITIONS=true

    3. Set the build action of the file to "AndroidEnvironment".

    That's one way to set the XA_BROKEN_EXCEPTION_TRANSITIONS environment variable as in the second workaround for "access the local variables":

    Temporarily disable the new exception propagation by setting the XA_BROKEN_EXCEPTION_TRANSITIONS environment variable to true.

    In case it's helpful to know, these new inconveniences for debugging non-async unhandled exceptions were an intentional trade-off made to fix several older bugs such as Bug 7634 and Bug 8900. See also: http://forums.xamarin.com/discussion/comment/121782/#Comment_121782, http://forums.xamarin.com/discussion/comment/122435/#Comment_122435.

  • i_NateCooki_NateCook USMember ✭✭

    @BrendanZagaeski You mention "quick hack" and "temporarily". Is there any way to conditionally set XA_BROKEN_EXCEPTION_TRANSITIONS just for debug builds? Is it ok to do something like the following?

      <ItemGroup Condition=" '$(Configuration)' == 'Debug' " >
        <AndroidEnvironment Include="Environment.txt" />
      </ItemGroup>
    

    Is that supported? Does switching the build configuration in the drop down menu properly detect the inclusion or exclusion of the AndroidEnvironment file?

Sign In or Register to comment.