Created attachment 9376 [details]
Customer has following scenario where he is trying use String resource defined in the Android Library project:
1) main blank Android project
2) Library android project, called library1
3) Another library project, Called library2
The library1 references library2 and Main Android app reference library1 .
The solution compiles ok till he add an unique String resource to library2.
Compilation fails after he add string resource with below error
Error 1 'Parent.Resource.String' does not contain a
definition for 'ApplicationName2'
31 92 Parent
We have checked this issue with help of sample app attached in description and getting the same behaviour. Please refer the screencast : http://www.screencast.com/t/mS2idEYfkx
Build Output Log : https://gist.github.com/Udham1/91bd31b65d7fde78900f
Ide Logs : https://gist.github.com/Udham1/61cdb78a3011c975eda9
Environment Info :
=== Xamarin Studio ===
Version 5.7.1 (build 5)
Installation UUID: ce927b2a-2c07-44c5-b186-09cfdafba6dc
Mono 3.12.0 ((detached/1538a59)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000072
=== Apple Developer Tools ===
Xcode 6.1.1 (6611)
=== Xamarin.iOS ===
Version: 22.214.171.124 (Enterprise Edition)
Build date: 2015-01-08 22:29:16-0500
=== Xamarin.Android ===
Version: 126.96.36.199 (Enterprise Edition)
Android SDK: /Users/xamarin76/Desktop/android-sdk-macosx
Supported Android versions:
1.6 (API level 4)
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
=== Xamarin.Mac ===
Version: 188.8.131.52 (Enterprise Edition)
=== Build Information ===
Release ID: 507010005
Git revision: ef2b158f8e0495f6b696d97f1dc0b8208577a5a8
Build date: 2015-01-15 03:32:55-05
Xamarin addins: 12ef44f5cd3bba34b1982969f0d6a8d881ed00c9
=== Operating System ===
Mac OS X 10.9.5
Darwin Xamarin76s-Mac-mini.local 13.4.0 Darwin Kernel Version 13.4.0
Sun Aug 17 19:50:11 PDT 2014
This is a known issue and cannot be resolved only within Xamarin.Android at least right now. Here is the reason:
In Java projects, library projects can be imported with priority. This partly applies to Mono for Android - if your project.properties contain further references to other projects, we take them and resolve those references with priority. On the other hand, if you reference zip archives, we cannot take any preferred priority list from it. So we don’t consider priority and files are extracted in non-deterministic order, avoiding overwrites. If you want imports with priority, first create an empty project that references multiple projects and then reference it, or create archive for that project which should have resolved all relevant resources taking priority.
i.e. there is no way to specify order of "References" (order of DLLs) in normal .NET, there is no corresponding way to Java Android's project.properties ordering.
Note that Java Android library projects (as implemented in Eclipse ADT) don't support resource merging either. That's why library ordering matters. Determining "which resource can/should be merged and what not?" is not obvious without explicit specification.
But we do not reference zip archives. We have a master project which references library project 1, and that library project 1 references library project 2. Isn't there a priority in that hierarchy?
No matter the answer, please provide us with an information how should we change the above sample for it to compile, or is it not possible to use more than 1 level of library referencing?
Oh, my bad, you're right. That doesn't apply to non-Java-involved projects.
Current behavior is basically because Android resource handling in library projects is done in the same manner as Android Java binding library projects, which subsequently conforms to Android native platform development experience gives. I didn't notice that this kind of resources conflict could occur.
XA could do better, but it does not support that feature right now.
Since it is merely dependent on order of library resource extraction, my idea for workaround that would work so far is, to add reference to ClassLibrary2 to Parent _after_ ClassLibrary1 in Parent.csproj (in XML file i.e. you cannot confirm the order from within the IDEs but in the text editor). I think we don't reorder dll references when we process resources, so if mono or .NET (depending on MSBuild implementation) doesn't reorder it.
This is a nasty workaround idea, but by this workaround I could build this Parent.csproj.
Yes it will compile, I knew that earlier, but that kinda defies the purpose of library projects and nice projects structure. This was just a sample. We made from scratch a base for large structure of projects, sub-projects, library projects, and it will make it a total mess if we will have to start referencing everything everywhere.
Secondly it will lead to circular referencing if we'll start to do that (likely).
I'm not sure if I understand that, I cannot think of any reason how this workaround "defies" the "purpose" of library projects...
I don't think you should worry about complicated references graph. With explicit order of references in app project, it shouldn't matter.
In above example parent should have absolutely no knowlege of library2, however it has to because there is a limitation in Xamarin Android, not in Android Framework itself.
In anyway we'll stick with referencing all library projects with resources in our main project. Works so far, hopefully we'll not get into any other situation which will bring forward some problem which arose by doing that.
I think the ticket can be closed at this point.
We will keep it open until we really get this resolved.
We will come up with certain additional specification (either project properties or additional build description file like AndroidEnvironment or LinkDescription), hopefully soon. But that new feature will have to wait for a while until the next major release gets out (and everything from the fixage commit up to verification of resolution will be logged in this entry).
For me, Library 2 doesn't generate resource IDs for it's own resources.
Ignore my comment. There was an aart error preventing generation.
If you're experiencing this, please see the VS output window for aart errors following a rebuild. That might be the cause. It was for me.