Bug 23176 - Resource IDs in library projects not const
Summary: Resource IDs in library projects not const
Status: RESOLVED INVALID
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.16.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2014-09-19 05:34 UTC by sebastianhaas
Modified: 2014-09-19 13:12 UTC (History)
2 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 sebastianhaas 2014-09-19 05:34:22 UTC
When compiling an executable project, the resource IDs end up to be const e.g.:

public const int menu_delete = 2131361814;

But if we put the same resource to a library project, it becomes something like:

public static int menu_delete = 2131361814;


Now I don't see the reason for declaring resources in executable projects const, but those in library projects only static. In fact after I moved some commonly used resources to a library project, I would have to change a lot of existing code like switch-cases as C# requires options to be const.
Comment 1 sebastianhaas 2014-09-19 05:35:18 UTC
This was also mentioned in the forum earlier this year:
http://forums.xamarin.com/discussion/19369/compiling-resource-ids-static-vs-const
Comment 2 Ram Chandra 2014-09-19 06:59:41 UTC
I can reproduce the reported behavior. "Resource IDs in library projects not const ". I’ll need confirmation from the developer if this is a bug.

Leaving as NEW for now.

Screencast: http://www.screencast.com/t/LL4yXYFG6g4

Environment Info:

=== Xamarin Studio ===

Version 5.3 (build 441)
Installation UUID: a7e29e93-6348-4126-9ebc-b2777c96a552
Runtime:
 Microsoft .NET 4.0.30319.18408
 GTK+ 2.24.22 (MS-Windows theme)
 GTK# 2.12.26

=== Xamarin.Android ===

Version: 4.16.0 (Business Edition)
Android SDK: E:\android-sdk
 Supported Android versions:
  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.2    (API level 17)
  4.3    (API level 18)
  4.4    (API level 19)
  4.4.87 (API level 20)
  4.5    (API level 21)
Java SDK: C:\Program Files (x86)\Java\jdk1.6.0_39
java version "1.6.0_39"
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)

=== Build Information ===

Release ID: 503000441
Git revision: befb6aa1176d37a5f678f4274f340a0159091b7a
Build date: 2014-09-08 20:54:12-04
Xamarin addins: 6dc7c388e31fdfc8014689839d37de0d4622435c

=== Operating System ===

Windows 6.2.9200.0 (64-bit)
Comment 3 Jonathan Pryor 2014-09-19 13:12:05 UTC
> Now I don't see the reason for declaring resources in executable projects
> const, but those in library projects only static

This is By Design, because that's what Android/Java does with Library projects:

http://tools.android.com/tips/non-constant-fields

> The reason for this is simple: When multiple library projects are combined, 
> the actual values of the fields (which must be unique) could collide. Before 
> ADT 14, all fields were final, so as a result, all libraries had to have all their 
> resources and associated Java code recompiled along with the main project 
> whenever they were used. This was bad for performance, since it made builds 
> very slow. It also prevented distributing library projects that didn't include the 
> source code, limiting the usage scope of library projects.