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.
Created attachment 16074 [details]
Sample project illustrating issue
Given an F# 4.0 PCL referenced by an X.Android app written in C#, such as in the attached project, at runtime the F# 3.x version of FSharp.Core is used. This may work just fine, or blow up in weird ways if some member is used that is not present in the 3.x version of FSharp.Core.
Expected behavior: The 4.0 version of FSharp.Core should be packaged in X.Android, like it is in X.iOS.
Workaround: The FSharp.Core Nuget can be used (e.g. as a dep if the library is distributed via Nuget).
N.B. This is the doc that is supposed to provide guidance on FSharp.Core: https://fsharp.github.io/2015/04/18/fsharp-core-notes.html
> Expected behavior: The 4.0 version of FSharp.Core should be packaged in X.Android
I'm wondering if, in the current state of affairs, we should instead *not bundle* F# support and instead require developers use the NuGet packages. The FSharp.Core NuGet packages already include Xamarin-profile binaries -- we use them instead of building them in the xamarin-android OSS repo, and are also doing so in monodroid (it cuts off ~10 minutes on CI build time!) -- so the only change here would be to ensure that NuGet-provided assemblies override SDK-provided binaries...
That said, xamarin-android and monodroid/master are both now using F# 4.0, so your immediate concern is already addressed for Cycle 8. Mid-to-long term, though, I wonder if this is really the right approach at all...
I would be in favor of users using NuGet packages and us not distributing F#. We don't use it for anything, so the package might bitrot unless someone remembers to update it from time to time (when? For what reason? We wouldn't know because we don't use it ourselves)
We've decided that the saner course of action is to have developers rely on the F# NuGet packages, as those will be more frequently updated that what is provided with Xamarin.Android.
As such, we do not plan on providing newer versions of FSharp.Core.dll with Xamarin.Android. Please use the Sharp.Core NuGet package instead:
We're removing FSharp.Core.dll from Xamarin.Android. Please use the FSharp.Core NuGet package: