Bug 16826 - ACWs: Create unique package names instead of lowercasing the namespace
Summary: ACWs: Create unique package names instead of lowercasing the namespace
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.10.1
Hardware: PC Mac OS
: Normal enhancement
Target Milestone: 5.1
Assignee: Jonathan Pryor
: 21147 ()
Depends on:
Reported: 2013-12-16 14:43 UTC by Jonathan Pryor
Modified: 2015-04-29 16:41 UTC (History)
5 users (show)

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:

Description Jonathan Pryor 2013-12-16 14:43:27 UTC
First (public?) bug on the X.0 breaking change TODO list:

The ACW generation code shouldn't lowercase the namespace name to generate the package name. Instead, it should generate unique names based on namespace+assembly name (e.g. use MD5(Type.AssemblyQualifiedName) as the package name).

This would be a breaking change, because we've previously documented that the package name is the lowercased namespace name, and used this as a workaround for all manner of historical bugs.


 1. It's uncommon, but not impossible, for two types to have the same namespace+type name but be present in two different assemblies:


 2. At least once in the past a customer ran into issues because the Java package name was "too long." (I'm not sure what "too long" was, but the package name was dozens+ of characters in length, and iirc they were either running afoul of Windows' MAX_PATH limit, or Android didn't like their crazy long package name either.)

    Encoding the namespace+assembly into a fixed-size package name would avoid this issue.

Note that this could be disabled on a type-by-type basis by using e.g. ActivityAttribute.Name to set an explicit ACW name.

Potential Problem: Performance. Internally we need to navigate from Managed names to JNI names, and vice versa. (This could probably use some profiling love, too.)

* Managed > JNI is (currently) done by lowercasing the namespace + JNIEnv.FindClass(), and only if that fails do we lookup the custom attributes to find any alternate names. (Note: this may in fact be stupid. Profile!)

The above "always encode" scheme would require an entirely different mechanism for type mapping.

* JNI > Managed is (currently) done by PascalCasing the package name. It's also quite flaky, and offhand I don't know if this is actually used.

occasionally we need to go from a JNI type name to a C# type name, and that currently works by attempting to PascalCase the JNI name into a C# name, and only if that fails do we fallback to
Comment 1 Jonathan Pryor 2014-02-06 15:20:25 UTC
*** Bug 17642 has been marked as a duplicate of this bug. ***
Comment 2 Jonathan Pryor 2014-08-13 10:33:35 UTC
*** Bug 21147 has been marked as a duplicate of this bug. ***
Comment 3 Paul Batum 2014-08-13 20:32:48 UTC
Is there an ETA for taking this change? We maintain a library that is impacted by this issue and so it would be great if we could get an idea of when a fix might be available.


Comment 4 Jonathan Pryor 2014-08-13 23:13:43 UTC
> Is there an ETA for taking this change

This is a gigantic semantic change, and could wreak untold and unknowable havoc: ALL instances where developers assume the ACW name will be invalidated. (Mind you, it's "easily" fixable by using [Register] or [Activity(Name="my/alternate/TypeName")], but it will still break existing code.)

As such, I can't in good conscience do this before an ABI break.

Good news: we're planning on a 5.0 release some time this fall to coincide with Android API-L going stable (which I'm assuming will likewise be 5.0), and this will allow us to perform some ABI breaks.

Bad news: I'm not confident in being able to get this change in place in that timeframe.

So the answer is either "within the next few months" or "over a year from now."
Comment 5 Paul Batum 2014-08-17 23:54:07 UTC
OK, thanks for the info Jonathan, we appreciate it!
Comment 6 Jonathan Pryor 2014-10-15 21:52:52 UTC
Fixed in monodroid/eb04c91c.
Comment 7 Paul Batum 2014-10-19 21:59:13 UTC
I see that 21147 has been marked as a duplicate of this bug. In the case of 21147, the issue of not being able to load two types with the same full name from two different assemblies exists for both iOS and Android. This bug covers the Xamarin.Android side, is the same issue already fixed for Xamarin.iOS?
Comment 8 Jonathan Pryor 2015-03-12 21:47:27 UTC

> is the same issue already fixed for Xamarin.iOS?

Bug #21147, as I understood it, was only for Android, not for iOS. The only places "iOS" shows up in Bug #21147 is in the IDE version information dumps and in your question at:


If there is an iOS equivalent to this bug, it should be filed as a separate bug.