Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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
*** Bug 17642 has been marked as a duplicate of this bug. ***
*** Bug 21147 has been marked as a duplicate of this bug. ***
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.
> 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."
OK, thanks for the info Jonathan, we appreciate it!
Fixed in monodroid/eb04c91c.
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?
> 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.