Bug 26100 - Xamarin.Android app fails to merge Resource from library project
Summary: Xamarin.Android app fails to merge Resource from library project
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 4.20.0
Hardware: PC Mac OS
: High enhancement
Target Milestone: ---
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2015-01-16 05:53 UTC by Prashant Cholachagudda
Modified: 2017-05-10 17:01 UTC (History)
5 users (show)

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


Attachments
Testcase (21.37 KB, application/x-7z-compressed)
2015-01-16 05:53 UTC, Prashant Cholachagudda
Details

Description Prashant Cholachagudda 2015-01-16 05:53:41 UTC
Created attachment 9376 [details]
Testcase

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'
C:\Projekty\Testowe\ResourceIdTesting\Parent\Resources\Resource.Designer.cs
31 92 Parent
Comment 2 Udham Singh 2015-01-16 06:40:58 UTC
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
Runtime:
	Mono 3.12.0 ((detached/1538a59)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000072

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)
Build 6A2008a

=== Xamarin.iOS ===

Version: 8.6.0.52 (Enterprise Edition)
Hash: 7c4c2c5
Branch: 
Build date: 2015-01-08 22:29:16-0500

=== Xamarin.Android ===

Version: 4.20.0.28 (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: 1.11.3.0 (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
    root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
Comment 3 Atsushi Eno 2015-01-19 05:39:30 UTC
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.
Comment 4 ltoczek 2015-01-19 07:15:22 UTC
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?
Comment 5 Atsushi Eno 2015-01-19 07:38:44 UTC
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.
Comment 6 ltoczek 2015-01-19 08:48:06 UTC
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).
Comment 7 Atsushi Eno 2015-01-19 09:59:24 UTC
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.
Comment 8 ltoczek 2015-01-20 02:04:54 UTC
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.
Comment 9 Atsushi Eno 2015-01-20 05:01:48 UTC
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).
Comment 10 Daniel Vaughan 2017-05-09 20:31:08 UTC
For me, Library 2 doesn't generate resource IDs for it's own resources.
Comment 11 Daniel Vaughan 2017-05-10 17:01:21 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.