Bug 11679 - User is not able to debug the template application of MFA with the default configuration: (Don't Link | Shared Runtime | Fast Deploy).
Summary: User is not able to debug the template application of MFA with the default co...
Alias: None
Product: Android
Classification: Xamarin
Component: Debugger ()
Version: 4.7.x
Hardware: Macintosh Mac OS
: High critical
Target Milestone: 4.8 (async)
Assignee: Bugzilla
: 12215 ()
Depends on:
Reported: 2013-04-09 09:30 UTC by Jatin
Modified: 2013-05-14 19:11 UTC (History)
6 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 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:

Comment 1 Jatin 2013-04-09 09:44:45 UTC
An update to the above issue:

Regression status: REGRESSION, as when we checked this issue with the following builds:

Mono 2.10.12
MFA 4.7.04001

And with the above builds this issue does not exists, as the user is successfully able to debug the application.
Comment 2 PJ 2013-04-09 09:58:18 UTC
Duplicate of bug 11421, perhaps? Does this happen with LinkSDK as well? Then you should just have one bug for 'Cannot debug with Shared Runtime and Fast Deploy enabled'.
Comment 3 Jonathan Pryor 2013-04-09 12:00:13 UTC
Please provide the emulator/target device's `adb logcat` information.
Comment 4 Saurabh 2013-04-09 13:01:01 UTC
Below are the following information:

adb logcat: https://gist.github.com/atin360/0d25977b2ff101130f8f

Diagnostic Build Output: https://gist.github.com/atin360/be1f51113539d35baf81
Comment 5 Jonathan Pryor 2013-04-09 13:33:42 UTC
@Saurabh: Thank you for providing the information. Unfortunately neither of the logs in Comment #4 provide information about the app installation. The logcat output lacks a relevant message containing __mono_init__ or libmonodroid; afaict, the app was never launched, and the app needs to be launched in order for fast deployment to occur.


Similarly the Build output contains the _Sign target, but no Upload targets, so I still don't know _why_ deployment is failing or how to explain the original Android Tool Logs, which indicate that the .__override__ directory is not being created:

> [2013-04-09 18:46:59.5] DEBUG: Stat: 50 FileInfo for /data/data/ldihrgilrbniop.ldihrgilrbniop/files/.__override__ : ---------

Please perform the following: 

Open Terminal.app, and enter the following commands:

    $ xbuild /t:Install *.csproj /v:diag > build.txt

Then gist build.txt, and provide the device's `adb logcat` output.

 - Jon
Comment 6 Saurabh 2013-04-09 14:17:05 UTC
This is the gist of build.txt

Comment 7 Jonathan Pryor 2013-04-09 15:39:30 UTC
This bug is probably fixed in monodroid/d4506afd.

The problem is that the default template doesn't set the $(DebugType) MSBuild property. Consequently, the build system doesn't consider it to be a Debug build, and won't embed the Seppuku receiver into the .apk. Without Seppuku, there's no way to launch the process, and thus no way to create the .__override__ directory, and everything crashes and burns.

WORKAROUND: Edit the .csproj and add the following XML fragment to the Debug|AnyCPU section:

Comment 8 Peter Collins 2013-04-09 18:33:23 UTC
Verified Fixed in master - 77cf8f58
Comment 9 Jonathan Pryor 2013-05-14 19:11:53 UTC
*** Bug 12215 has been marked as a duplicate of this bug. ***