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.
* open up a Xamarin.Android application in Xamarin.Studio (try this one: https://github.com/xamarin/mobile-samples/tree/master/TaskyPro)
* set the startup project to be the android app
* select either "Debug" or "Release" in the build config toolbar
* right click on the android project and choose build
it creates the Tasky.Android.dll and Tasky.Android.dll.mdb, but no .apk or -Signed.apk files.
if you want those to get generated, you have to actually deploy to a simulator or the device.
This is by design ( and the VS addin does the same). The sign/package targets are only invoked when deploying. This was intended to reduce build iteration time.
So then what's the point of building? just to make sure you don't have any errors?
This is actually kind of a problematic and confusing feature. imagine, for instance, you're trying to build for Test Cloud. users aren't going to understand why, when the _build_, they're not actually building.
The rationale is that IDE users tend to Build _constantly_, to syntax check their code, etc. With that in mind, it was felt that _any_ delay to the Build would be met with annoyance, as we expect developers to Build many dozens or hundreds of times a day.
> imagine, for instance, you're trying to build for Test Cloud
That's already going to be problematic, because you can't use Debug builds with Test Cloud (if Fast Deployment is enabled, which is the default, because the .apk won't contain any assemblies). We'll need to document this, at minimum.
If you'd like to try this workflow in practice, you could modify your MSBuild file to run the deploy target post-build. i'd recommend trying it on something bigger than a sample.