Bug 57178 - Breakpoints not hit in external C# library
Summary: Breakpoints not hit in external C# library
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: iOS ()
Version: 4.5.0 (15.2)
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2017-06-06 12:24 UTC by Jerome Laban
Modified: 2017-09-25 21:12 UTC (History)
7 users (show)

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:

Description Jerome Laban 2017-06-06 12:24:36 UTC
With Xamarin, using the steps to repro for bug #35691, it is still not possible to put breakpoints in external libraries, and the workaround for #35691 is not applicable anymore. I have not found another one yet.

This time, for some reason, the mdb files are correctly generated, *sometimes* end up in the mtbs folder on the mac, but almost never end up in the MyApp.app folder.

Cleaning, rebuilding, seem to have no influence on the copy of files to the mac.

Manually copying the mdb files in the .app folder somehow help the debugger hit breakpoints.
Comment 1 nhamawi 2017-06-29 15:10:14 UTC
We are experiencing exactly the same issue which is very serious problem for my client's mobile team because it's not easy to roll back to 4.4 (not like switching alpha/beta/stable channels) and 4.4 brings back other issues that we also cannot manage. While v4.6 (beta) claims to fix missed breakpoints, we have found that 4.6 is actually worse and does not even allow us to hit internal breakpoints, even after clearing all build caches on the mac. Even worse, 4.6 is causing our app to crash, complaining about invalid instructions. Unfortunately, I was not able to set a breakpoint or step through the code to see where exactly this is happening.

Jerome, thank you; at least we have some sort of workaround.
Comment 2 Joaquin Jares 2017-07-10 18:45:57 UTC
Moving to our iOS component. We'll look into this.
Comment 3 Jimmy [MSFT] 2017-07-12 22:42:04 UTC
I tested this on Visual Studio 2017 with Xamarin but I wasn't able to reproduce the issue. The bug 35691 report was initially for an iOS library and later PCLs, so I tested both cases for this new report. The libraries were created and built in a separate VS instanceand I referenced the dlls in the main test project. I opened the source files for the libraries and set breakpoints and they were hit during debugging. I also checked the app bundle on the Mac and confirmed that it contained the mdb and pdb files for the library assemblies.

Can you confirm that Xamarin.iOS is also up to date on the Mac machine? For my tests I used v10.10.0.36. Are you experiencing this when deploying to the simulator, device, or both and can you attach the full debug output to the report? Also, if there is anything I might have missed in my steps above, please let me know. Thanks!
Comment 4 nhamawi 2017-07-13 22:27:47 UTC
Jimmy thanks for looking into this. My team is using VS 2015. I will try VS 2017 and report back.
Comment 5 Jerome Laban 2017-07-19 13:48:48 UTC
It seems like disabling the linker changes the behavior somehow.

We need the linker to work properly in debug, as it allows the catching of linker-related issues early in the dev process.
Comment 6 Joaquin Jares 2017-07-19 18:37:36 UTC
@Jerome what's the change of behavior? Does it work in every case, or only in some. Linker rewrites symbol files, so this may be a linker issue. If that's the case, I can get the linker expert to look into it.
Comment 7 Pierce Boggan [MSFT] 2017-09-25 21:12:37 UTC
Because we have not received a reply to our request for more information in over 4 weeks, we are closing this issue. If you are still encountering this issue, please reopen the ticket with the requested information so we can continue looking into this. Thanks!