Bug 24863 - 2 android projects generate the same resource Id
Summary: 2 android projects generate the same resource Id
Status: RESOLVED INVALID
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.12.4
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2014-11-26 12:59 UTC by Mike James
Modified: 2017-09-19 16:55 UTC (History)
4 users (show)

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

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 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.

Related Links:
Status:
RESOLVED INVALID

Description Mike James 2014-11-26 12:59:10 UTC
A customer is experiencing issues with duplicated resource IDs when using multiple projects. 

An example:

Starter.Android\Resources\Resource.cs(229)            public const int load = 2130903040;
Core.Android\Resources\Resource.cs(281)               public const int actionbar_custom_viewpage = 2130903040;
Comment 2 Jonathan Pryor 2014-11-26 20:16:22 UTC
(This is probably INVALID...)

Why is this relevant?

There are two "kinds" of resource constants: Library constants, which are `static`, and Application constants, which are `const`. During process startup, Library constants are updated to the appropriate corresponding Application constants.

Application constants, obviously, can't be updated at runtime (they're `const`!).

The only time these "duplicate resource IDs" would be a problem is if you have an Application project referencing an Application project. This is NOT supported and WILL NOT WORK

(Unfortunately this is a situation we don't currently check for, and thus we don't generate an error for it either...)

You can read the .csproj and see if it has <AndroidApplication>True</AndroidApplication>. If it does, it's an Application project. If it doesn't, it's a Library project.
Comment 4 Rik Lubking 2015-10-28 07:42:46 UTC
I've found that duplicate resource id's can happen and can cause runtime exceptions when referencing a library project from an application project. If the library project references another library project in which the resources are contained and that project is not also referenced by the application project then the application may throw exceptions during runtime.

The fix is easy, simply reference the library project containing the resources from the application project (even if that library project is never actually used in the code of the application project).

So what didnt work was:
Application project -references-> Library project
Library project -references-> Library project with resources

What did work:
Application project -references-> Library project
Application project -references-> Library project with resources
Library project -references-> Library project with resources


Using:

Microsoft Visual Studio Ultimate 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.5.51209

Xamarin   3.11.894.0 (d70d139)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android   5.1.6.7 (58099c5358da3488b0e7fb0bb4af47aca7cc61d6)
Visual Studio plugin to enable development for Xamarin.Android.
Comment 5 Jon Douglas [MSFT] 2017-09-19 16:55:12 UTC
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Android. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction.