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.
Created attachment 11800 [details]
sample solution with repro
I have two Xamarin App projects A and A.Tests (using NUnit.Droid or whatever the name is). To this end, A.Tests has a project reference on A. This used to work fine in Xamarin.Android 4 but broke in Xamarin.Android 5.
When upgrading to Xamarin.Android 5 I had to add <IsAppExtension>False</IsAppExtension> to my project reference.
The actual build order when I build A.Tests is:
whereas it should be
Thus, project A.Tests does not build correctly. Xbuild appears not to add a /reference for A (unless I built A manually before) to the csc invocation when building A.Tests.
I suppose this is a bug in xbuild.
Sample repro attached
A.Tests = BuildOrderTests.csproj
Version 5.9.4 (build 5)
Installation UUID: 3cbf1b60-0560-4942-8de5-aedf17c5251e
Mono 4.0.2 ((detached/c99aa0c)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400020005
Apple Developer Tools
Xcode 6.4 (7720)
Version: 18.104.22.168 (Indie Edition)
Build date: 2015-06-22 21:28:32-0400
Version: 22.214.171.124 (Indie Edition)
Android SDK: /Users/jr/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: /usr
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Xamarin Android Player
Release ID: 509040005
Git revision: 8010a90f6e246b32364e3fb46ef2c9d1be9c9a2b
Build date: 2015-06-08 16:52:06-04
Xamarin addins: 7e93e9c3503f28770f23ce1b7eafd829919f18e8
Mac OS X 10.10.4
Darwin iDevBook01.local 14.4.0 Darwin Kernel Version 14.4.0
Thu May 28 11:35:04 PDT 2015
I haver checked this issue with attached sample project and observed that project "BuildOrderTests" getting build error.
if I have change <IsAppExtension>True</IsAppExtension> to <IsAppExtension>False</IsAppExtension> in BuildOrderTests.csproj then its build successfully.
Please confirm me that are you getting same behavior? if no then please let me what step I missing.
I was taking about something different. Unfortunately my first attachment was missing a using for the buildorder namespace, I see you've fixed that in your sample.
- add "using buildorder;" statement to BuildOrderTests/MainActivity.cs
- leave the <IsAppExtension> setting at False like it is in the sample
- Clean All
- Build BuildOrderTests
- you will get a build error: "The name name or namespace buildorder..."
I get that behavior everytime using these steps.
Unfortunately, your repro is invalid.
It is not valid, and never has been "valid" (though we never previously error'd on it...) for an AndroidApplication project to reference an AndroidApplication project. (See above for some details.)
> TL;DR: Don't add Application projects to Application projects; things generally won't work as you expect.
The insidious problem with having an Application project reference an Application project is that it would continue to build. The problem wouldn't appear until you *ran* the project, at which point any Android resource lookup (FindViewById(), GetDrawable(), etc.) could return the "wrong" Android resource.
Throwing <IsAppExtension/> everywhere is not a fix, especially since <IsAppExtension/> is now used for something completely different: embedding Android Wear apps:
If you want to write unit tests, you should put the code you want to test into a *Library* project (PCL or Android Library). You can then reference that project from both your "normal" app and the unit test app.
Tell you what - it worked perfectly fine in prior versions of Xamarin.Android..... FindViewById() etc. didn't work of course but that's totally to be expected.
It totally works on iOS too....
I want to be able to reference the assembly containing the App Code to allow me to perform subcutaneous testing of code interacting with native APIs. There needs to be a solid way to do that, and testing via referencing the App assemblies has thus far always been the easiest approach.
(And it has saved me numerous times due to tiny incompatibilities, be it either the mono code interfacing with the platform (sockets....) or using the native APIs of the Platform).
The way I read this is: "we never officially supported something and now we broke it and are not even sorry?"
I want to reference an Android App assembly, don't give a damn about resources. I had to set IsAppExtension=false exactly because I didn't want to create an Android Wear package...
> Tell you what - it worked perfectly fine in prior versions of Xamarin.Android.....
It didn't work "perfectly fine".
> FindViewById() etc. didn't work of course but that's totally to be expected.
Which demonstrates how it *didn't* work "perfectly fine".
I also fail to see how that would be "totally expected" unless you have knowledge of how all the internals work, which (for better or worse) is *not* the majority of developers.
It "worked"...for various definitions of "work." Unfortunately, my definition of "work" requires that it be able to work work correctly, and Android App projects referencing Android App projects could *never* work *correctly*; it was stuck in a limbo land of "works if you squint just right or never hit its limitations," which is a terrible scenario for all parties involved. (Adds to our support costs; angers customers when they hit one of the bizarre limitations which are *not* "totally expected"...)
> (And it has saved me numerous times due to tiny incompatibilities, be it either
> the mono code interfacing with the platform (sockets....) or using the native
> APIs of the Platform).
I don't understand this.
> The way I read this is: "we never officially supported something and now we
> broke it and are not even sorry?"
More or less...yup.
> I want to reference an Android App assembly
But *why*? If it's for testing, as initially suggested, then my suggested solution of using a Library project (1) works, and (2) works properly for all scenarios, unlike the App assembly approach.