Bug 19556 - Cannot debug project with conditionally redefined package name
Summary: Cannot debug project with conditionally redefined package name
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Android Add-in ()
Version: 5.0
Hardware: Macintosh Mac OS
: Low enhancement
Target Milestone: Future Cycle (TBD)
Assignee: Greg Munn
: 44133 ()
Depends on:
Reported: 2014-05-06 10:22 UTC by Chris Riesgo
Modified: 2016-10-04 15:10 UTC (History)
4 users (show)

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

Repro case (68 bytes, text/plain)
2014-05-06 11:10 UTC, Chris Riesgo

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 for Bug 19556 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Chris Riesgo 2014-05-06 10:22:51 UTC
My goal is to add a Conditional statement to the csproj file such that when the Build configuration is set to Debug, my Android app will use Properties\AndroidManifestDebug.xml as the manifest template, and use Properties\AndroidManifestDebug.xml for all other Build configurations.

More specifically, I want to define separate manifest templates for Build configurations so that I can build and deploy versions of the same app with different package names side-by-side:

Debug: com.example.conditionalmanifest.debug
Release: com.example.conditionalmanifest

The behavior that I expect is that when I redefine the AndroidManifest property, that the build process will use the redefined AndroidManifest file to build the application package.

The behavior that I see is that when I redefine the AndroidManifest inside of the existing Debug conditional PropertyGroup and attempt to deploy a Debug build, the application deployment fails:

Deployment failed because of an internal error: Could not find file "/repro/ConditionalManifest/bin/Debug/com.example.conditionalmanifest-Signed.apk".

Deployment failed. Internal error.
Comment 1 Chris Riesgo 2014-05-06 11:10:47 UTC
Created attachment 6741 [details]
Repro case
Comment 2 Ram Chandra 2014-05-06 13:16:33 UTC
I have checked this issue and I am able to reproduce this issue.

Steps to reproduce :
1. Open the attached project on XS
2. Debug the project
3. Deployment error will occur

I observe that when I deploy attached project on "Debug" mode, I am also getting deployment error but With a little work around here, I have found that there is  wrong package name mentioned on "AndroidManifestDebug.xml" file i.e. "com.example.conditionalmanifest.debug". When I change this package name to this "com.example.conditionalmanifest" then I am able to deploy application successfully on both mode ( Debug/Release).

Please check the same on your end and let us know if this is working fine for you now.

Screencast: http://www.screencast.com/t/CNymkHDA1E30
Comment 3 Chris Riesgo 2014-05-06 14:24:27 UTC
Thanks for following up, Ram. 

My intention is that I *want* to have 2 different package names so that both the "Debug" and "Release" build configurations can be installed onto the device side-by-side at the same time. So, changing the package name isn't really an option. I need to be able to specify unique package names for N-build configurations within a single android project.
Comment 4 Mikayla Hutchinson [MSFT] 2014-05-06 17:26:17 UTC
The apk is *building* just fine with the conditionally included manifest.

The issue here is that the manifest changes the package name, and XS need to know the package name to find the apk file and deploy it. Due to limitations in the XS MSBuild integration, the execution engine cannot evaluate arbitrary MSBuild properties, so it's just reading the project-level manifest. 

For more info see http://mjhutchinson.com/journal/2012/08/19/state_msbuild_support_monodevelop, which is still mostly true.

So you can *build* different configurations with different package names, but from the IDE you can currently only execute the ones that use the root manifest.

Fixing this will depend on better integrating MSBuild engine into the core project system.
Comment 5 Chris Riesgo 2014-05-06 17:37:29 UTC
I think I understand, now. You're suggesting that the build and output of the project is just fine. If I were to execute the build via some script or msbuild command outside of XS, I would "net" the result that I'm looking for. You're just saying that I won't see that result I'm expecting when attempting to build and deploy from the IDE.

Does that sum it up accurately?
Comment 6 Mikayla Hutchinson [MSFT] 2014-05-06 18:12:55 UTC
XS will create the actual apk, it just won't be able to upload it to the device and execute it.

The build is split into two parts, building and packaging. XS automatically runs the packaging step before uploading the app. Although the upload will fail, the packaging step will succeed, and you'll be able to find the apk in the build directory.
Comment 7 Chris Riesgo 2014-05-07 08:47:59 UTC
Of course, not the answer I really wanted to hear, but I understand that the nuances of getting 100% MS Build integration into XS is not an easy thing, and that there are higher priorities. Again, thanks for taking the time to explain how everything is working instead of simply saying, "Won't work. Next."
Comment 8 Greg Munn 2016-09-09 20:05:32 UTC
*** Bug 44133 has been marked as a duplicate of this bug. ***