Bug 44887 - VS debugger not hitting the breakpoints when using bait-and-switch trick on iOS
Summary: VS debugger not hitting the breakpoints when using bait-and-switch trick on iOS
Status: VERIFIED FIXED
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: iOS ()
Version: 4.2.0 (C8)
Hardware: PC Windows
: Normal major
Target Milestone: 15.3
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-09-29 14:24 UTC by tranb3r
Modified: 2017-07-07 09:31 UTC (History)
10 users (show)

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


Attachments
VS debugger not hitting the breakpoints when using bait-and-switch trick on iOS (182.64 KB, application/x-zip-compressed)
2016-09-29 14:24 UTC, tranb3r
Details


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 tranb3r 2016-09-29 14:24:31 UTC
Created attachment 17804 [details]
VS debugger not hitting the breakpoints when using bait-and-switch trick on iOS

# Description

Breakpoints placed in a PCL called using bait-and-switch trick are not hit on iOS.
No problem on Android and when not using the bait-and-switch trick on iOS.

# Sample

Attached

# Steps to Reproduce

1. Download sample
2. Open solution in Visual Studio
3. Deploy TestBreakpoint.iOS to iOS (I'm using the simulator and iPhone 5 iOS 10.0)
4. Make sure you have a breakpoint set on line 10 in file Class1.cs in project Breakpoint.iOS.
5. In the app, click on the message.

# Expected Results

Tapping message should cause breakpoint set in step 4 to be hit

# Actual Results

The counter in the message does increase as expected, but breakpoint is not hit

# Versions

Microsoft Visual Studio Community 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Community

Xamarin   4.2.0.695 (7603786)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android   7.0.1.2 (c1d1c79)
Visual Studio extension to enable development for Xamarin.Android.

Xamarin.iOS   10.0.0.1 (29910bb)
Visual Studio extension to enable development for Xamarin.iOS.

iOS simulator 0.10.0.6
Comment 1 tranb3r 2016-10-17 08:47:06 UTC
Do you have any update on this issue ?
Comment 2 Ben Beckley 2016-10-17 17:15:53 UTC
Sorry, but no, there is not. This has been brought to the developers' attention, and is currently on the milestone for the next release. We plan to have a beta available sometime during the next month.
Comment 3 thomas 2016-11-11 19:14:23 UTC
Yes, would be very helpful
Comment 4 Jon Douglas [MSFT] 2016-11-17 20:26:21 UTC
@tranb3r

I do not believe this workflow is supported as the Bait and Switch(Advanced PCL Trick) approach is mostly the inner workings of NuGet.

Specifically NuGet will *always* prefer a platform library to a PCL one. Because of this, Bait and Switch is possible.

As for debugging this item, you would directly need to reference your iOS library implementation to your iOS startup project and exclude the PCL invocation. You can add a copy of TestBreakpoint(PCL) "MyClass.cs" to the TestBreakpoint.iOS project and then the debugger should work just fine while you're testing the functionality preparing your library for NuGet.

You could potentially keep it on the NuGet end and ship symbols with your library http://docs.nuget.org/ndocs/create-packages/symbol-packages in which you can setup a CI environment to debug that way. It's really up to you at that point.
Comment 5 thomas 2016-11-18 18:00:03 UTC
Hi, it happens not only when using nuget

have a look at https://github.com/escamoteur/Plugin.MediaLibrary

if you try to set a breakpoint in th iOS part of the plugin project and run the sample it won't hit the breakpoint

Cheers
THomas
Comment 6 tranb3r 2016-11-20 16:46:37 UTC
I'm sorry but as the creator of this bug report, I cannot accept this bug being updated to "RESOLVED ANSWERED", for two reasons:
- I'm not using nuget at all in the original sample I've attached, so comment#4 is irrelevant.
- this is a very common pattern, it works perfectly on Android, and I expect the same behavior on iOS.

Could you please reopen and fix this issue ?
Comment 7 Jon Douglas [MSFT] 2016-11-21 05:57:11 UTC
Hi tranb3r,

Can you please try this project structure and let me know if it works for you in Visual Studio?

https://www.dropbox.com/s/j1964hry4jgdu71/TestBreakpointWorks.zip?dl=0

Please note: You may need to delete the bin/obj folders inside each project for a fresh cache.

I've ensured the Assembly names are correctly defined in the Breakpoint.iOS project and it seems to break fine for me:

http://screencast.com/t/VV02ne08iECH

Notes:

I was able to replicate the original behavior in Xamarin Studio, so it seems like a potential issue with how Xamarin.iOS names Assemblies in each IDE. Secondly, I was able to change the Assembly name within XS and load the project in both VS/XS(Mac) and VS(Windows) in which the debugger now hits the appropriate breakpoint as shown above in the screenshot. I will have to investigate this further in the morning.

Version Information:

Xamarin 4.3.0.281 (2c75d6d)
Xamarin.Android 7.1.0.2 (0a4ab55)
Xamarin.iOS 10.4.0.1 (7c50b27)
Comment 8 tranb3r 2016-11-21 08:17:55 UTC
I confirm the "TestBreakpointWorks" does work in Visual Studio (it breaks fine).
What's the difference compared to the original project (apart from renaming the assembly) ??
Comment 9 Artem Pavlov 2016-11-25 05:38:50 UTC
I have compared both original and modified projects and found that if an order of dependency declarations in the TestBreakpoint.csproj file will be as follows:

<ProjectReference Include="..\TestBreakpoint\TestBreakpoint.csproj">
<ProjectReference Include="..\Breakpoint.iOS\Breakpoint.iOS.csproj">

then the debugger breaks correctly, otherwise (as was done in the original project) will not.
Comment 10 Artem Pavlov 2016-11-25 05:44:59 UTC
Sorry for the typo, I meant TestBreakpoint.iOS.csproj file
Comment 11 thomas 2016-11-25 07:00:41 UTC
That's really interesting, I will try with my project if that solves it too
Comment 12 Jon Douglas [MSFT] 2016-11-28 21:38:00 UTC
@Artem Thanks for getting to this before I did. Yes this is indeed due to how Visual Studio creates ProjectReferences and then how Xamarin Studio does. Thus the behavior between VS and XS is inconsistent.

I can indeed confirm that this behavior works in my sample project

Works:

  <ItemGroup>
    <ProjectReference Include="..\TestBreakpoint\TestBreakpoint.csproj">
      <Project>{71e82085-3b7c-4379-9814-b1ac8604d890}</Project>
      <Name>TestBreakpoint</Name>
    </ProjectReference>
    <ProjectReference Include="..\Breakpoint.iOS\Breakpoint.iOS.csproj">
      <Project>{C2B9DEBA-1539-4609-B06E-E5B81DEB1551}</Project>
      <Name>Breakpoint.iOS</Name>
    </ProjectReference>
  </ItemGroup>

Fails:

  <ItemGroup>
      <ProjectReference Include="..\Breakpoint.iOS\Breakpoint.iOS.csproj">
      <Project>{C2B9DEBA-1539-4609-B06E-E5B81DEB1551}</Project>
      <Name>Breakpoint.iOS</Name>
    </ProjectReference>
    <ProjectReference Include="..\TestBreakpoint\TestBreakpoint.csproj">
      <Project>{71e82085-3b7c-4379-9814-b1ac8604d890}</Project>
      <Name>TestBreakpoint</Name>
    </ProjectReference>
  </ItemGroup>

Thus the PCL project must be first in the Project References followed by the implementation.
Comment 13 Juan Marcelo Tondato 2017-06-28 16:54:02 UTC
This should be fixed on the latest stable. Marking as Fixed for internal verification. Please reopen if you are still seeing the issue.
Comment 14 Ivan Herrera 2017-07-07 09:31:18 UTC
Verified