Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Async methods do not debug at all in PCL projects.
The following code does not trigger a breakpoint on the Busy flag set:
public RelayCommand PerformanceCommand
?? (_prefCommand = new RelayCommand(
async () =>
Busy = true; << breakpoint here does not trigger
// Check if already navigated to avoid multiple taps on the handset
if (_navService.CurrentPageKey == ViewModelLocator.PageKeyVesPerf) return;
await _navService.NavigateTo(ViewModelLocator.PageKeyVesPerf, SelectedVessel);
catch (Exception ex)
Busy = false;
() => !_busy));
} << breakpoint triggers here on page load
Instead the breakpoint triggers at the end of the get when the page is instantiated.
Essentially it is impossible to debug an Forms PCL MVVM app when using async (which in my case is 80%+ of the code).
Also cleaning the solution and deleting ob and bin folders in all projects and rebuilding makes no difference.
I have checked this issue with Xamarin.Forms.18.104.22.16847 and able to reproduce this issue with the help of attached project in https://bugzilla.xamarin.com/show_bug.cgi?id=34676#c2.
OBservation: I observed that breakpoints do not hit in an async RelayCommand with iOS debugger in xamarin.Forms.
However I checked the same with android debugger and observed that breakpoints gets hits.
Android : http://www.screencast.com/t/KwkYusmMQxUI
iOS : http://www.screencast.com/t/XzEvrupH
IDE log: https://gist.github.com/Arpit360/6917caf48e9d7774c78b
Microsoft Visual Studio Professional 2013
Version 12.0.40629.00 Update 5
Microsoft .NET Framework
Installed Version: Professional
Windows Phone 8.1 SDK Integration 1.0
This package integrates the tools for the Windows Phone 8.1 SDK into the menus and controls of Visual Studio.
Workflow Manager Tools 1.0 1.0
This package contains the necessary Visual Studio integration components for Workflow Manager.
Xamarin 22.214.171.1241 (22caadd)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin.Android 126.96.36.199 (f94dc5b)
Visual Studio plugin to enable development for Xamarin.Android.
Xamarin.iOS 188.8.131.52 (7bcf0da)
Visual Studio extension to enable development for Xamarin.iOS.
@Jares, so everything works as expected if the linker is disabled?
I need to verify it with this bug. With others that were identical, it worked with linker disabled.
I'm still using the candidate release on a daily basis due to much better performance in both Android and iOS. I have observed the same behavior debugging in Android sometimes.
I have just verified with no linker and the behavior is the same, so my initial estimate seems off. I'm dumping mdb right now to see if lines match what I expect them to be there.
All the relevant information is here: https://gist.github.com/joj/3baed9d4a32a05cab0b7
What I'm seeing is that the breakpoint is set in the correct location (in debugger output) but then the line number on the call stack when the breakpoint is actually hit is wrong.
Proving path for the dlls look off, though. I need to verify that.
Doesn't look like a iOS/runtime bug, but a second-level PCL bug. Trying a fix.
I have created PR#4411 to address the mdb generation for second-level PCL, but I'm still observing the bug. We need runtime support at this point.
This happens with Android debugging as well:
async () =>
// breakpoints inside here do not work properly. They seem to hit somewhere outside the lambda.
This is definitely a 2nd level PCL issue. Referencing the .Data project from the main android app allows the .mdb to be generated and the debugging works.
Fixed in version 184.108.40.2062 (master)
Author: Jose Gallardo
Commit: 176dbdecd00a42e84899b06df7b5f13ff4611c08 (xamarin/XamarinVS)
I have pushed a change made by Dean to our targets that should also fix this for Android.
Created attachment 13711 [details]
XVS log files for 220.127.116.118 verification
Hello all, I have verified that the fix for the x.iOS issue using the attached project and following the reproduction steps. This was using build 18.104.22.1688 (a6bf8166) from the xvs-win-cycle6-34676 branch and XI 22.214.171.124 on the build host.
In addition to following the reproduction steps, I used a freshly unzipped project and added the PCL projects to be built in the Solution Configuration.
I've also attached the logs from this session.
Also before testing this, I ensured that I was able to reproduce the issue using a build without the fix. This was using build 126.96.36.1991 (22caadd) from the xvs-win-cycle6 branch and XI 188.8.131.52 on the build host.
In accordance with the other session, this was with a fresh unzip and included the PCL projects in the Solution Configuration.
I also tried to reproduce this using the current stable XVS 3.11.1589 but was unable to hit any breakpoints.
Per c#21, marking this as verified.
Fixed in version 184.108.40.206 (cycle6)
Author: Jose Gallardo
Commit: 7f653bc081175322a49c6382c691a4f221f861a2 (xamarin/XamarinVS)