Bug 15205 - Change in name of strong-named v4 support assembly
Summary: Change in name of strong-named v4 support assembly
Status: RESOLVED NOT_ON_ROADMAP
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: 4.8.x
Hardware: PC Windows
: High normal
Target Milestone: ---
Assignee: Alex Soto [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2013-10-04 09:33 UTC by Stuart Lodge
Modified: 2015-03-12 17:49 UTC (History)
7 users (show)

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


Attachments

Description Stuart Lodge 2013-10-04 09:33:06 UTC
We're seeing a problem currently with the Mono.Support.v4 assembly.

The latest version of this - in the component store - has been renamed to a `Xamarin` name - but still contains the same namespaces as the previous Mono assembly.

This means that other assemblies built against the Mono version can't work with the latest component store version. This seems to include assemblies like the Froyo version of the Google Play component and the MvvmCross Fragment support library.

I've tried a few TypeForwarding approaches - but these don't seem to work.

Any workarounds would be gratefully received. If not, can we:

- rename the new component back to Mono
- or change the namespaces used?
- or stop shipping the old assembly and force everyone to shift to the new one.

Cross-reference this to:

- http://stackoverflow.com/questions/19125901/mvvmcross-trying-to-use-fragments-and-latest-support-lib-results-in-linking-pr
- http://forums.xamarin.com/discussion/8563/android-support-library-v4-rev-18-android-support-v4-app-linker-conflict-mono-android-support-v4
Comment 1 Jonathan Pryor 2013-10-04 10:44:15 UTC
> This means that other assemblies built against the Mono version can't work with
> the latest component store version. 

I realize this is annoying, but we do _nothing_ to ensure API compatibility between the bundled Mono.Android.Support.v*.dll and the corresponding Components, and I've debugged at least one "API breakage" between the two (which is why I'm not updating the bundled version -- API broke).

Since the API may (is) not compatible, allowing Type Forwarding would likely be detrimental.

Long-term, I plan on _removing_ the Mono.Android.Support.v*.dll assemblies (Xamarin.Android 5.0-timeframe; there will be warning!), and the Component should be the preferred binding.

> http://stackoverflow.com/questions/19125901/mvvmcross-trying-to-use-fragments-and-latest-support-lib-results-in-linking-pr
> error : Duplicate managed type found! Mappings between managed types and Java types
> must be unique. First Type:
> 'Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor, 
>  Xamarin.Android.Support.v4-r18, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null';
> Second Type: 
> 'Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor, 
> Mono.Android.Support.v4, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'

This actually speaks to a more specific bug that we DO need to fix: we don't handle name collisions at all.

Contrived example:

    // Lib1.dll
    namespace Utilities {
        class Holder<T> : Java.Lang.Object {
            public T Value { get; set; }
        }
    }

    // Lib2.dll
    namespace Utilities {
        class Holder<T> : Java.Lang.Object {
            public T Value { get; set; }
        }
    }

Two separate assemblies, both with the same fully-qualified type name. This is perfectly legal C# code. The problem is that we use the namespace + type name for the name of the resulting Android Callable Wrapper, with _no_ assembly qualification, meaning both of those types will map to the ACW `utilities.Holder`, resulting in the same build error.

The Mono.Android.Support.v4.dll vs. Xamarin.Android.Support.v4.dll issue is just a more readily encountered variant of the above issue.

The proper fix, then, is for us to encode the assembly name into the package name (or something; possible solutions abound, and done right could fix a few other ACW-related issues as well...).
Comment 2 Jonathan Pryor 2013-10-04 10:46:59 UTC
> Any workarounds would be gratefully received. If not, can we:

All I can think of, offhand, are IL-rewriting approaches (ildasm, change the assembly name reference, ilasm, and pray). That's not ideal. :-/

> - rename the new component back to Mono

No.

> - or change the namespaces used?

No. We're using the package name as the namespace name, to facilitate reuse of Java code, documentation, samples, etc. Changing the namespace would thus be detrimental.

> - or stop shipping the old assembly and force everyone to shift to the new one.

As mentioned in in Comment #1, this is the long term plan. Unfortunately such a change would be an ABI break, and I can't in good consciousness do that until 5.0.

(BTW, there's no timeframe on 5.0, so don't hold your breath for it...)
Comment 3 Jonathan Pryor 2013-10-04 10:47:52 UTC
> Any workarounds...

Actually, one workaround that comes to mind is to alter MvvmCross to use the Xamarin component instead of Mono.Android.Support.v*.dll...

You'll need to do this long-term, anyway. ;-)
Comment 4 Stuart Lodge 2013-10-04 11:53:48 UTC
Thanks

> I realize this is annoying

It's not "annoying" as much as I just can't get it to work at the moment :/

> Actually, one workaround that comes to mind is to alter MvvmCross to use the
Xamarin component instead of Mono.Android.Support.v*.dll...
> 
> You'll need to do this long-term, anyway. ;-)

We can only really do that if "everyone" shifts.

And by "everyone" I really mean https://components.xamarin.com/gettingstarted/googleplayservices - as that references the Mono version - and it's more important for us to have Maps at the moment than it is for us to have the latest support library.

If there's a date when that shifts over then that would make it much easier for mvx to shift too. It would still mess up all the existing demos, videos, blog posts, etc - but it would at least work moving forwards :)
Comment 5 Stuart Lodge 2013-10-04 11:55:05 UTC
PS> While we're exchanging winking smilies, it would also help if:

- the xamarin v4 support library was also available on nuget (so I could bundle it as a dependency)
- the component store supported dependencies (so I could ship Mvx on the components store)

Thanks ;-)
Comment 7 Stuart Lodge 2013-12-02 05:34:12 UTC
Hi

Is there any official news on this?

It appears that the GooglePlay component may have switched over? But I've seen nothing here, and I'm mainly guessing this because I've got a customer complaining that their code has stopped building after updating the component.

Is there somewhere the change is announced? Is it "official" now that all customers should not use the Mono version?

Thanks

Stuart
Comment 8 Christian 2013-12-05 08:25:36 UTC
Hi,

i'm also affected by this change and i'm forced to use an old version of the play service component to continue developing.

Are there any news about this topic?

Best Regards
Christian
Comment 9 Stuart Lodge 2013-12-12 02:20:11 UTC
I'm hoping to release a v3.1 beta of mvvmcross and this is blocking me currently... 

It feels like changes have already perhaps been made inside Xamarin - so this issue might now be easy to close :)

Is there any official news or guidelines? Which support library should a 3rd party library like MvvmCross bind to? Which support library version does the Google Play services bind to? Is this now a fixed strong name moving forwards?

Thanks

Stuart
(always asking questions - sorry!)
Comment 10 Floris Otto 2014-01-15 04:11:10 UTC
Hi,

I have the same problem.
We want to upgrade to Google Play Service for Gingerbread.
If I add that component to our project, it'll need the Xamarin.Android.Support.v4 assembly instead of the Mono.Android.Support.V4.
After I update a referenced binding project to that assembly my code breaks saying the type or namespace can't be found anymore.

Error CS0246: The type or namespace name 'LoginButton' could not be found (are you missing a using directive or an assembly reference?) (CS0246)

Whats the current status of this issue?
Is there a workaround or something?

Kind regards,
Floris
Comment 11 Cliff Cawley 2014-01-30 01:54:49 UTC
Hi,

I have the same problem when using MvvmCross. I'm unable to use the new controls such as the ViewPager or TaskStackBuilder because I need to use the ActionBar control, which needs the MvvmCross Fragment support which isn't compatible with the support library.

Something like that, it's been a month since I was working on it and I'd hoped it would have been fixed by now. Posting here to add my voice.

Cliff
Comment 12 Mehmet Kartalbas 2014-02-11 06:20:52 UTC
Hi,

I upgraded to mvvmcross 3.1.1 and face the same issue above, just add my voice here

Mehmet
Comment 13 Alex Soto [MSFT] 2014-02-12 00:48:56 UTC
Hello

The current Google Play Services components available in the store as of today February 11, 2014 are as follows

Google Play Services (Froyo) - https://components.xamarin.com/view/googleplayservicesfroyo
    - This component is only for Xamarin.Android applications that target Android 2.2 (API level 8). In November, 2013 Google stopped supporting Android 2.2 in the newer versions of Google Play Services.
    - You can still use Google Play Services in existing Froyo applications, but you won't get any of the bug fixes or features that appear in Google Play Services revision 13 or higher. So this component is stuck in time.
    - This component also reference and includes the following assembly Android Support Library v4 Rev 18 (a.k.a Xamarin.Android.Support.v4.dll)

Google Play Services (Gingerbread) - https://components.xamarin.com/view/googleplayservicesgingerbread
    - This component is only for applications that target Android 2.3 (API level 10).
    - This component also reference and includes the following assembly Android Support Library v4 Rev 18 (a.k.a Xamarin.Android.Support.v4.dll)
    - This component also reference and includes the following assembly Android Support Library v7 AppCompat Rev 18 (a.k.a Xamarin.Android.Support.v7.AppCompat.dll)

Google Play Services - https://components.xamarin.com/view/googleplayservices
    - This component is only for applications that will target Android 4.0 (API level 14) or higher.
    - This component does not reference or bundle any support libraries

As per comment #2 We are not able to do any changes to the namespace, and Xamarin.Android bundled Mono.Android.Support.v4 will be discontinued on version 5.0

@Stuart on comment #4 you spotted that old GPS component used to rely on bundled Mono.Android.Support.v4, this is no longer true, if you get either Froyo or Gingerbread version of GPS you will get for free Xamarin.Android.Support.v4.dll and both GPS components are built against it.

About the question of using either Xamarin.Android.Support.v4.dll (Component) or Mono.Android.Support.v4 (Bundled on X.A), we now encourage the usage of the component available in the store over the version that comes bundled, you can always use the bundled version but you will be missing updates and bug fixes that Google has released in new revisions and we are trying to keep the component up to date. Also keep in mind we will remove it on version 5.0 of X.A (still no ETA for it).

My recommendation would be to base mvx on the Gingerbread version of Google Play Services based on the Google's Dashboard here http://developer.android.com/about/dashboards/index.html

Hope this helps.

Alex
Comment 14 Stuart Lodge 2014-02-12 06:36:09 UTC
Thanks Alex

I got bored of waiting for an answer here - so MvvmCross changed over to the Xamarin named package in out 3.1.1 branch a long time ago (November?)

However, I know many users are still hitting issues caused by the dichotomoy - see http://stackoverflow.com/questions/21699698/fragment-support-compilation-errors with issues on actionbar sherlock :(

It might be useful to set date when all components must change over?

Stuart

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