Akavache should install portable classes instead of net45 on a Xamarin.Android project

[mikescandy]

When installing Akavache (nuget akavache) to a Xamarin.Android project targeting Api 21, Paket adds references to dlls from the net45 folders, instead of the portable ones (portable-windows8+net45+wp8 which should be equivalent to profile 259). As a side effect, it also adds references to System.Reactive.Windows.Threading and WindowsBase, which are obviously not available on Android.

I tried to force the framework in the references for the project but with no luck.

[forki]

/cc @christianlang ideas?

[christianlang]

@mikescandy can you specify the version of Akavache you're using? The current version 4.1.0 of akavache.core (the package "akavache" itself doesn't contain files) has a dedicated MonoAndroid build which I assume should be used.

[christianlang]

I general Paket prefers builds for specific platforms over portable builds, just like NuGet does. For the reasoning behind this, please see this discussion: #380 (comment).

Maybe this doesn't make sense for .NET builds on Xamarin.Android. Not sure how compatible they are.

[mikescandy]

If I understand right, akavache references akavache.sqlite3, which in turn references akavache.core,which then references everything else (RX-Main, Newtonsoft, and the windows specific Rx packages).
Maybe the problem is in the way the profile is defined? AFAIK portable-net45+winrt45+wp8+wpa81 is equivalent to portable-net45+winrt45+wp8+wpa81+MonoAndroid+MonoTouch (profile 259, you can check this in Xamarin studio)

As a sidenote, installing with nuget is working fine.

[christianlang]

Why do you think it should reference the portable version? Shouldn't it reference akavache.core/lib/MonoAndroid/Akavache.dll because that's exactly the platform you need? (I'm not saying there is no bug, I'm just trying to understand the issue.)

[mikescandy]

Ok, you're right, I didn't explain the problem properly, sorry for that!
let's try again.

Installing "akavache" with nuget on a Xamarin.Android app I get references to:

akavache.core.4.1.0\lib\MonoAndroid\Akavache.dll
akavache.sqlite3.4.1.0\lib\Portable-Net45+Win8+WP8+Wpa81\Akavache.Sqlite3.dll
Newtonsoft.Json.6.0.3\lib\portable-net40+sl4+wp7+win8\Newtonsoft.Json.dll
Splat.1.3.3\lib\monoandroid\Splat.dll
SQLitePCL.raw_basic.0.7.0\lib\MonoAndroid\SQLitePCL.raw.dll
Rx-Core.2.2.5\lib\portable-windows8+net45+wp8\System.Reactive.Core.dll
Rx-Interfaces.2.2.5\lib\portable-windows8+net45+wp8\System.Reactive.Interfaces.dll
Rx-Linq.2.2.5\lib\portable-windows8+net45+wp8\System.Reactive.Linq.dll
Rx-PlatformServices.2.2.5\lib\portable-windows8+net45+wp8\System.Reactive.PlatformServices.dll

Installing "akavache" with paket on a Xamarin.Android app I get references to:

• akavache.core\lib\MonoAndroid\Akavache.dll (v. 4.1.0)
• akavache.sqlite3\lib\Portable-Net45+Win8+WP8+Wpa81\Akavache.Sqlite3.dll (v. 4.1.0)
• Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll (v. 6.0.8)
• Splat\lib\monoandroid\Splat.dll (v. 1.6.1)
• SQLitePCL.raw_basic\lib\MonoAndroid\SQLitePCL.raw.dll (v. 0.7.1)
• Rx-Core\lib\net45\System.Reactive.Core.dll (v. 2.2.5)
• Rx-Interfaces\lib\net45\System.Reactive.Interfaces.dll (v. 2.2.5)
• Rx-Linq\lib\net45\System.Reactive.Linq.dll (v. 2.2.5)
• Rx-PlatformServices\lib\net45\System.Reactive.PlatformServices.dll (v. 2.2.5)
• Rx-Xaml\lib\net45\System.Reactive.Windows.Threading.dll (v. 2.2.5)

and an extra reference to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\WindowsBase.dll

• Newtonsoft.Json is loading a different version and a different platform
• All the Rx libraries are loading the net45 assemblies instead of the portable ones.

hopefully this will help shed a bit of light on this.
If it helps, I could try debugging paket locally to see what's happening, although it might take a while (not exactly proficient with F# :) )

[christianlang]

Thanks, that's very helpful now :) Newtonsoft.Json is where it breaks, it seems (among others).

NuGet references Newtonsoft.Json.6.0.3\lib\portable-net40+sl4+wp7+win8\Newtonsoft.Json.dll.
Paket references Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll.

I'm trying to find a rule here that we can implement. Problem is that we don't even try to determine the
exact portable profile that's represented by a lib-folder. When we see a folder portable-net40+sl4+wp7+win8 we don't know it's ".NETPortable, Version=v4.0,Profile=Profile136", so we can't derive that it should support Xamarin.Android and Xamarin.iOS as well. We just look at the platforms mentioned in the folder name (.NET 4.0, Silverlight 4.0, WP7, Win8) and go from there.

NuGet doesn't seem to do the right thing either, by the way. From the screenshot you posted I see that Profile 259 seems to support Xamarin.Android. So why does NuGet prefer the older Profile 136 build over the dll in portable-net45+wp80+win8+wpa81?

Can you please explain specifically why .NET 4.5 is the wrong version to take here? Is Xamarin.Android not very compatible with .NET 4.5? Is it better to go with .NET 4 in general? Maybe that's an angle to tackle it from.

Sorry that I'm asking more questions than giving answers.

[mikescandy]

well, the main issue is that Paket is bringing in Rx-Xaml\lib\net45\System.Reactive.Windows.Threading.dll (v. 2.2.5) and WindowsBase as a reference, which is obviously not related to Android and breaks the project

regarding the newtonsoft reference, I don't think it's a big issue. Not sure what's happening there, but on a different project it's importing packages\Newtonsoft.Json.6.0.8\lib\portable-net40+sl5+wp80+win8+wpa81\Newtonsoft.Json.dll (profile328 I think) which makes sense.

OT: the profile thing is a mess...

[mikescandy]

Could it be that the issue is related to the "bait and switch" trick (http://log.paulbetts.org/the-bait-and-switch-pcl-trick/ from @paulcbetts )?

[christianlang]

Yes, this pattern is the reason why we implemented Paket the way it is. It's why we pick the .NET version of Rx instead of the portable version. See #380 (comment).

That's why I'm not sure how/if we can solve this problem.

[mikescandy]

fair enough, thanks for the time spent on this anyway 👍 i'm reverting to plain nuget, but paket remains a fantastic tool to inspect package dependencies!

[forki]

Can we solve this with special casing?

[christianlang]

Since Rx is a very common library a special case for this would make sense, I think. Is that what you mean?

We could also try to manipulate our rules to prefer a portable build over a .NET build for Android, but that would probably break other packages using the "bait and switch" trick. So a special case for Rx sounds good to me.

[forki]

I'd love to see a PR which special cases Rx
On Mar 10, 2015 11:10 AM, "Christian Lang" [email protected] wrote:

Since Rx is a very common library a special case for this would make
sense, I think. Is that what you mean?

We could also try to manipulate our rules to prefer a portable build over
a .NET build for Android, but that would probably break other packages
using the "bait and switch" trick. So a special case for Rx sounds good to
me.

—
Reply to this email directly or view it on GitHub
#676 (comment).

[anaisbetts]

From the Akavache side, most of those look right, so does SQLitePCL_Raw

[christianlang]

Because you provide excellent cross-platform support as usual :)

[davidfowl]

Don't special case RX, the support for PCLs in NuGet is shaky at best but you can draw from the rules here https://github.com/NuGet/NuGet3/blob/dev/src/NuGet.Frameworks/FrameworkReducer.cs#L46. This is the new NuGet v3 client. This logic should return the "best match" given a "target" target framework and a list of target frameworks. This includes the mess that is portable-*

[forki]

Closing old issue. Hope everything will be fine with .NET Standard