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 or GitHub 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.
I have a MonoDevelop Solution with multiple projects that are built as assemblies. My main project references these assemblies.
In MD 184.108.40.206 debugging these projects worked just fine.
When I updated to 220.127.116.11 I was no longer able to debug the assembly projects (debugging the main project still works just fine). The breakpoints never get hit and they show up as a light pink circle with a red outline, which seems to indicate that it can't find the assembly to match the code.
Once I reverted back to 18.104.22.168 I was once again able to debug my assembly projects.
What is the value of the following checkbox?
MonoDevelop -> Preferences -> Debugger -> "Debug project code only; do not step into framework code"
Is that enabled? If so, that's the problem. Try unchecking that checkbox.
Another option is to reference projects instead of assemblies.
Created attachment 1652 [details]
dummy project which works
Using the attached project, I'm able to debug sources in MyLibrary (even though I'm referencing the assembly and not the project).
I also didn't seem to need to disable "Debug project code only", so maybe that's not the problem you are having after all?
Is this how your projects are setup? If so, does debugging work for you in my dummy project?
Your test project works just fine for me as well... I am able to debug the referenced assembly.
One thing I should have noted is that I am working on Android. Part of the reason I have to reference the assembly and not the project is that these projects are shared in both the iOS and Android solutions...
Ok, I have solved the problem, but I'm not sure exactly what it means...
I guess it could be either a bug that was fixed between v22.214.171.124 and 126.96.36.199 or it could mean a new bug in this latest version.
Here is the situation:
Our main project X referenced assembly A and assembly B. However, assembly A also referenced assembly B.
Assembly B was the assembly that we could not debug from the main project. Once I removed the reference to Assembly B from the main project debugging started working.
So, here is a quick representation of the situation:
Original Scenario (Debugging B works in v188.8.131.52 but is broken in v184.108.40.206):
X --> A, B
A --> B
Current Working Scenario (Debugging works in both versions)
X --> A
A --> B
I took the same project I attached and create a "MyHighLevelLibrary" project and made it reference the assembly built by project "MyLibrary" and then made the main project:
1. reference the assemblies in MyHighLevelLibrary\bin\Debug\[MyLibrary.dll & MyHighLevelLibrary.dll]
I was still able to debug into MyLibrary
2. reference MyHighLevelLibrary\bin\Debug\MyHighLevelLibrary.dll and MyLibrary\bin\Debug\MyLibrary.dll
It still worked.
I'm going to need more clarification on how your build system was setup :-\
Created attachment 1655 [details]
non-working project example
nevermind, I'm able to reproduce it ONLY with Mono4Android
here's what I get in the Application Output window:
W/ ( 663): Symbol file /data/data/X.X/files/.__override__/A.dll.mdb doesn't match image /data/data/X.X/files/.__override__/A.dll
W/ ( 663): Symbol file /data/data/X.X/files/.__override__/B.dll.mdb doesn't match image /data/data/X.X/files/.__override__/B.dll
Those warnings are probably why it doesn't work.
This looks like some sort of Mono4Android build issue and not a debugger issue.
Reassigning to the MonoDevelop MonoDroid add-in, not sure if it's that or Mono4Android.
This issue is an XBuild bug. Basically xbuild does not respect this syntax in the targets file:
When a direct reference to the compiled dlls in A and B are used in project 'X', the mdb files are not copied to the build output. If a ProjectReference is used, then the mdb files are copied as expected. This is something which would need to be fixed within xbuild.
The workaround for now is to use a ProjectReference (use the Edit Reference dialog and choose your project from the 'Projects' section). This will ensure both the assembly and the debugger file are copied properly.
Alternatively you could add the mdb file to your project as a link and choose to copy it to the output directory. So in your main project you will have a reference to the compiled dll of your support library and will then add the mdb as a regular file and mark it as 'Copy to output'. Using ProjectReferences is the recommended fix though.
How do I report an issue with XBuild then?
As I mentioned in my earlier comments, I am not able to use a proejct reference because the projects are set up as MonoTouch projects... We are sharing this code for use in both iOS and Android.
The other workaround seems like a really messy solution.
Also, if this truly is an XBuild issue, then why is there not a problem in MD v220.127.116.11?
Alan's explanation doesn't really make sense to me, copying mdb files to build output shouldn't make a difference, since M4A and MT bundle assemblies and mdb files directly from the original location into the app via the linker.
I don't see any commit between 18.104.22.168 and 22.214.171.124 that could affect this. Is this still a problem with 2.9.x?
1. This was not a bug in MD v2.8.6.x
2. This IS a bug in MD v2.8.8.x
3. I didn't know MD v2.9.x was available...
This doesn't work with the absolute latest MD:
Installation UUID: 8643496d-6965-4784-ae73-43f0ed8c29a1
Mono 2.10.9 (tarball Tue Apr 17 18:59:12 EDT 2012)
Package version: 210090010
Apple Developer Tools:
Xcode 4.3.2 (1177)
Mono for Android: 126.96.36.199858872 (Evaluation)
Apparently this has never worked with xbuild as the msbuild variable where we specify that mdb files should be copied is never used by xbuild itself. So is this a regression in the linker?
> Apparently this has never worked with xbuild as the msbuild variable where we
specify that mdb files should be copied is never used by xbuild itself.
Then why did it work in MD v2.8.6.x?
Actually, on further inspection it looks more like an issue in the M4A xbuild targets or the fastdev deployment.
Alan, can you explain why you think xbuild supports AllowedReferenceRelatedFileExtensions? It appears to be implemented in code, though I haven't tested it. And the value in the M4A targets is a fix for Microsoft MSBuild - xbuild has built-in support for copying mdb files.
> Actually, on further inspection it looks more like an issue in the M4A xbuild
> targets or the fastdev deployment.
For what it's worth... I do not have the fastdev deployment option turned on.
I can't reproduce the issue at all. The project on comment #6 (which has bogus references to project libraries and I had to fix them, but that shouldn't matter wrt this bug report) was debuggable.
Installation UUID: 21d68479-cc51-4c1d-986b-4396951efb28
Could you guys explain what is the problem now? I don't see any issue on this.
I noticed that you are using MD v3.1.0. Perhaps the bug is fixed in MD v3.x... I don't know if you noticed this in the previous comments, but the bug is present in MD v2.8.x and v2.9.x...
Could you try reproducing the problem in v2.8.x or 2.9.x? If you can, then that means the bug is fixed in 3.x versions of MD. If you can't, then I need to better explain the problem...
If you look at comment 4, that pretty much explains the problem. Also note that we are referencing the assemblies of the other projects in the solution and not the projects themselves... The reason for this is that the other projects are shared with an iOS app and the projects are built as MonoTouch libraries so I am not able to reference the projects directly.
I thought the repro at comment #6 is *the* project that realizes what is only literally explained in comment #4, isn't it ? If you say it is different, please attach your repro code instead of just text. Thanks.
Created attachment 1904 [details]
Sample Debug Problem
This project clearly shows the debugging problem...
attachment 1904 [details] (Sample Debug Problem) is a Mono4Android solution that clearly shows the issue. On creating this sample, I realized that the problem is more simple than what I originally thought.
It contains the main Android project and a MonoTouch project (ProjA). The MonoTouch project is referenced in the main project as an assembly.
To see the problem, place a breakpoint in A.cs on line 37. When you run this solution on an Android emulator or device, you will see the following:
MD 188.8.131.52: The breakpoint is hit
MD 184.108.40.206: The breakpoint is not hit
MD 3.0.1: The breakpoint is not hit
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?
If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
PJ, I haven't heard anything about this in forever. I'd almost assume its not a problem anymore. I've since moved to the iOS team and Justin is no longer on the android team.
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.
Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.