Bug 56225 - Visual Studio 2015 Update 3 not hitting breakpoints while debuing XF app on Android with HAXM
Summary: Visual Studio 2015 Update 3 not hitting breakpoints while debuing XF app on A...
Status: VERIFIED FIXED
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: General ()
Version: 4.5.0 (15.2)
Hardware: PC Windows
: Normal normal
Target Milestone: 15.4
Assignee: Bugzilla
URL:
Depends on: 56238
Blocks:
  Show dependency tree
 
Reported: 2017-05-11 13:57 UTC by Eder
Modified: 2017-07-26 09:59 UTC (History)
11 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
VERIFIED FIXED

Description Eder 2017-05-11 13:57:34 UTC
Install Visual Studio 2015 Update 3 (14.0.25431.01);
Install Xamarin for Visual Studio 4.5.0.443;
Install Haxm;
Create and Android Emulator targetting Android 7.1.1
Set a breakpoint on visual studio and run the application.


# Expected behavior
The Visual studio to stop on breakpoint

# Actual behavior
The app runs but Visual Studio 2015 doesn't hit the breakpoint

# Supplemental info (logs, images, videos)


# Test environment (full version information)
Comment 1 Ruben Buniatyan 2017-05-11 16:53:32 UTC
Same here. Wondering whether Xamarin team tests thoroughly before labeling updates as stable.
Comment 2 Piotr Szymczak 2017-05-15 08:23:55 UTC
I'm in the same boat, any Android app doesn't hit any breakpoints with Xamarin Android 7.3. How is that even possible?
Comment 3 Eder 2017-05-15 11:59:49 UTC
Just downgraded the Xamarin for Visual Studio 2015 plugin and it worked again. So this is definetly a Xamarin for Visual Studio 4.5.0.443 bug.
Comment 4 Brian Macomber 2017-05-15 17:19:53 UTC
I'm having the same issues in VS 2017 15.2 UWP app.  My main PCL lib the app is based on will stop at breakpoints...another referenced PCL in the same solution will not.

I think Xamarin messed up this whole release
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2017-05-15 18:58:41 UTC
## Possible next steps to check for users watching this bug

Based on Bug 56238, Comment 4, it appears that one cause of this issue for Android can be a change in the behavior of the `$(Optimize)` MSBuild property for Xamarin.Android.

Users on this bug report can try setting Optimize to `False` for the affected Debug configurations by editing those configurations in the Android app project's .csproj file (in a text editor), and adding the following element to the PropertyGroup for those configurations:

<Optimize>false</Optimize>
Comment 6 Piotr Szymczak 2017-05-15 20:45:00 UTC
Well after around 2 hours of playing around I've managed to fix the issue by changing project properties. 
New and old properties:
https://pastebin.com/ne5291vh
Optimize didn't help in case of failing set.

Slight offtopic... (should this be new issue?)
When I was searching for clues I found (bug?) in properties regarding MultiDex
Xamarin 7.3:
    <AndroidEnableMultipleDex>true</AndroidEnableMultipleDex>

I'm getting "Java exited with code -2" meaning that Dex file exceeded 65k methods and MultiDex just doesn't work. This is generated by new checkbox.

Previous version:
    <AndroidEnableMultiDex>true</AndroidEnableMultiDex>

If I add this line which was generated by checking chekbox in previous version of properties everything works in 7.3.

.targets file doesn't mention "AndroidEnableMultipleDex" either
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2017-05-15 20:58:23 UTC
> New and old properties
> ...
> Optimize didn't help in case of failing set.

Thanks for that additional information.  To make a guess, the other important property change in the comparison of the before and after might be the change from:

<Debugger>Xamarin</Debugger>

to:

<Debugger>.Net (Xamarin)</Debugger>

I will briefly check on the effect of that setting locally, and follow-up with an additional bug report if appropriate based on the results.




> should this be new issue?
> ...
> <AndroidEnableMultipleDex>
Yes, that issue is covered separately in Bug 56192.
Comment 8 Joaquin Jares 2017-05-22 15:59:31 UTC
Debugging with <Debugger>Xamarin</Debugger> works. Xamarin is the default, so any value different to C++ will be considered "Xamarin". I think this is the Optimize bug. The difference is that <Optimize>false</Optimize> which is explicit in the new settings. The rest can be left as is. 

@Brendan, do you have that bug number handy for reference? 

@Eder and others, can you try that explicit setting? That bug was fixed recently, though, so it should no longer be an issue.
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2017-05-22 16:57:32 UTC
> That bug was fixed recently, though, so it should no longer be an
> issue.
To provide additional details, Bug 56238 has a candidate fix, but it has not been released yet.  It is currently on track for release within the next couple of business days.  So for the moment, please continue to make sure <Optimize>false</Optimize> is explicitly specified in the affected Debug configurations.


> @Brendan, do you have that bug number handy for reference? 
I was able to hit breakpoints successfully when using the "previous version" properties from Comment 6 (after adding the `<Optimize>` element), so I did not create a follow-up bug report.  To make a guess, there might have been a clean/rebuild issue in the original observation in Comment 6 that obscured the effect of the `<Optimize>` element.

If another user sees a scenario where explicitly setting the Optimize property to `False` does not resolve the issue, but changing some other settings _does_, please do file a new bug report with those details and your version information to share the information with the Xamarin team.  Thanks!
Comment 10 Ruben Buniatyan 2017-05-23 14:37:53 UTC
This is still an issue for me for Xamarin.iOS on Windows. Nothing helps.
Comment 11 Brendan Zagaeski (Xamarin Team, assistant) 2017-05-23 15:10:16 UTC
> This is still an issue for me for Xamarin.iOS on Windows

The exact issue with <Optimize>False</Optimize> only applies to Xamarin.Android.  I have seen a few comments about issues with breakpoints in Xamarin.iOS on Windows, but based on the pattern of reports, it seems to be more dependent on certain factors (particular details of the project or development environment) than the <Optimize> issue on Android.  If you would be able to file a new bug that includes details about the particular project(s) that hit the issue (including whether on your computer the problem affects a new template project) as well as the complete version information from both Windows and Mac, including the operating system versions, Xcode version, and testing device(s) or simulator(s), that would be excellent.  Thanks in advance!
Comment 12 Fabio Pagano 2017-06-12 16:00:37 UTC
I have solved using Brendon suggestion in Comment 5, but instead of editing the csproj file of the .droid project to add "<Optimize>false</Optimize>", I have gone from Visual Studio 2017 IDE in the .droid project properties, then in the "Build" tab (in the configuration "Debug") I have deselected the option "Optimize code". I have noticed that in the .csproj file, in the "Debug configuration", the tag "<Optimize>" already existed and was set on "true" (as above said, setting it to "false" solves the problem).
Comment 13 Jose Gallardo 2017-06-21 17:46:28 UTC
Hi @Eder,

Can you please confirm if changing <optimize> to false fixes it for you?

Thanks
Comment 14 Eder 2017-06-22 13:22:54 UTC
Hello @joe,
I didn't tried to change the  <optimize> to false. I've rollback to a previous version and waited for another new version. Now I've updated the 'Xamarin for Visual Studio' plugin to version 4.5.0.486 and it seems the bug was fixed by xamarin.

version 4.5.0.486 is working perfectly fine.
Comment 15 Fabio Pagano 2017-06-26 09:26:17 UTC
With Xamarin version 4.5.0.486 (fec6f88) in Visual Studio Enterprise 2017 Version 15.2 (26430.13) the problem is still present. If I select "Optimize code" the breakpoints are not hit, if I don't select "Optimize code" the breakpoints are hit. This behavior happens in Xamarin forms, on google emulator (with HAXM active) and on physical device. We've tried on two different machines.
Comment 16 Eder 2017-06-26 13:26:13 UTC
based on @fpsoft1 latest response I've just reopened this ticket.
Comment 17 Brendan Zagaeski (Xamarin Team, assistant) 2017-06-26 15:11:18 UTC
> If I select "Optimize code" the breakpoints are not hit, if I don't
> select "Optimize code" the breakpoints are hit.
That is the correct expected behavior at this time.  If the Optimize property is _explicitly_ set to `true`, then it is the expected correct behavior that the full debug symbols will _not_ be included.  The fix for Bug 56238 is simply to make it so that when _no_ `Optimize` property is present, the _default_ value for the property is `false`.

(If curious, see the corresponding commit that resolves Bug 56238: https://github.com/xamarin/xamarin-android/commit/fd86ab04e66c8578c49f687650b2a4e5a477f832)