Bug 4352 - Unable to debug assemblies in MonoDevelop project
Summary: Unable to debug assemblies in MonoDevelop project
Status: RESOLVED NORESPONSE
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.0
Hardware: Macintosh Mac OS
: High critical
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-04-09 16:36 UTC by Justin
Modified: 2013-12-05 18:34 UTC (History)
5 users (show)

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


Attachments
dummy project which works (15.90 KB, application/zip)
2012-04-10 17:44 UTC, Jeffrey Stedfast
Details
non-working project example (19.01 KB, application/zip)
2012-04-11 17:23 UTC, Jeffrey Stedfast
Details
Sample Debug Problem (431.50 KB, application/zip)
2012-05-17 09:54 UTC, Justin
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 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.

Related Links:
Status:
RESOLVED NORESPONSE

Description Justin 2012-04-09 16:36:11 UTC
I have a MonoDevelop Solution with multiple projects that are built as assemblies.  My main project references these assemblies.

In MD 2.8.6.3 debugging these projects worked just fine.  

When I updated to 2.8.8.4 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 2.8.6.3 I was once again able to debug my assembly projects.
Comment 1 Jeffrey Stedfast 2012-04-10 16:30:08 UTC
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.
Comment 2 Jeffrey Stedfast 2012-04-10 17:44:08 UTC
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?
Comment 3 Justin 2012-04-11 13:00:34 UTC
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...
Comment 4 Justin 2012-04-11 13:17:26 UTC
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 v2.8.6.3 and 2.8.8.4 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 v2.8.6.3 but is broken in v2.8.8.4):
X --> A, B
A --> B

Current Working Scenario (Debugging works in both versions)
X --> A
A --> B
Comment 5 Jeffrey Stedfast 2012-04-11 17:18:27 UTC
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 :-\
Comment 6 Jeffrey Stedfast 2012-04-11 17:23:00 UTC
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.
Comment 7 Jeffrey Stedfast 2012-04-11 17:24:04 UTC
Reassigning to the MonoDevelop MonoDroid add-in, not sure if it's that or Mono4Android.
Comment 8 Alan McGovern 2012-05-01 15:27:13 UTC
This issue is an XBuild bug. Basically xbuild does not respect this syntax in the targets file:

<PropertyGroup>
	<AllowedReferenceRelatedFileExtensions>
		$(AllowedReferenceRelatedFileExtensions);
		.dll.mdb;
		.exe.mdb
	</AllowedReferenceRelatedFileExtensions>
</PropertyGroup>

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.
Comment 10 Justin 2012-05-01 15:48:42 UTC
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 v2.8.6.5?
Comment 11 Mikayla Hutchinson [MSFT] 2012-05-01 16:21:48 UTC
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 2.8.8.3 and 2.8.8.4 that could affect this. Is this still a problem with 2.9.x?
Comment 12 Justin 2012-05-01 16:25:03 UTC
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...
Comment 13 Alan McGovern 2012-05-01 16:43:26 UTC
This doesn't work with the absolute latest MD:

MonoDevelop 2.9.6
Installation UUID: 8643496d-6965-4784-ae73-43f0ed8c29a1
Runtime:
	Mono 2.10.9 (tarball Tue Apr 17 18:59:12 EDT 2012)
	GTK 2.24.10
	GTK# (2.12.0.0)
	Package version: 210090010
Apple Developer Tools:
	 Xcode 4.3.2 (1177)
	 Build 4E2002
Mono for Android: 4.1.0.88858872 (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?
Comment 14 Justin 2012-05-01 16:45:38 UTC
> 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?
Comment 15 Mikayla Hutchinson [MSFT] 2012-05-01 16:56:59 UTC
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.
Comment 16 Justin 2012-05-01 17:23:47 UTC
> 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.
Comment 17 Atsushi Eno 2012-05-11 10:27:26 UTC
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.

MonoDevelop 3.1.0
Installation UUID: 21d68479-cc51-4c1d-986b-4396951efb28

Could you guys explain what is the problem now? I don't see any issue on this.
Comment 18 Justin 2012-05-11 11:22:09 UTC
Atsushi Eno...

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.
Comment 19 Atsushi Eno 2012-05-17 05:43:56 UTC
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.
Comment 20 Justin 2012-05-17 09:54:03 UTC
Created attachment 1904 [details]
Sample Debug Problem

This project clearly shows the debugging problem...
Comment 21 Justin 2012-05-17 09:57:18 UTC
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 2.8.6.3: The breakpoint is hit
MD 2.8.8.4: The breakpoint is not hit
MD 3.0.1: The breakpoint is not hit
Comment 22 PJ 2013-11-19 17:04:46 UTC
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.
Comment 23 Stephen Shaw 2013-11-19 22:52:30 UTC
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.
Comment 24 PJ 2013-12-05 18:34:57 UTC
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.