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.
With Xamarin 126.96.36.1996, 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.
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.
Moving to our iOS component. We'll look into this.
I tested this on Visual Studio 2017 with Xamarin 188.8.131.526 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!
Jimmy thanks for looking into this. My team is using VS 2015. I will try VS 2017 and report back.
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.
@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.
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!