Repository navigation
F# support is broken in Xamarin.Android #12640
Description
Repro steps
Provide the steps required to reproduce the problem:
-
Install Visual Studio or Visual Studio for Mac and enable both Xamarin and .NET Core support, these are listed as ‘Mobile development with .NET’ and ‘.NET Core Cross-platform development’ respectively.
-
Open a command prompt window and install the template pack by entering:
dotnet new -i Fabulous.XamarinForms.Templates -
Navigate to a folder in the command prompt window where your new app can be created and enter:
dotnet new fabulous-xf-app -n SqueakyApp -
Build and run SqueakyApp.Android on device.
Expected behavior
The app build and run successfully
Actual behavior
/Users/nikolay/Dev/fsharp/SqueakyApp2/SqueakyApp2.Android/AssemblyInfo.fs(9,30): error FS0039: The type 'Android' is not defined.
/Users/nikolay/Dev/fsharp/SqueakyApp2/SqueakyApp2.Android/AssemblyInfo.fs(9,30): error FS0039: The type 'Android' is not defined.
/Users/nikolay/Dev/fsharp/SqueakyApp2/SqueakyApp2.Android/MainActivity.fs(20,63): error FS0039: The value, constructor, namespace or type 'Layout' is not defined.
/Users/nikolay/Dev/fsharp/SqueakyApp2/SqueakyApp2.Android/MainActivity.fs(21,61): error FS0039: The value, constructor, namespace or type 'Layout' is not defined.
These errors are due to Xamarin.Android.FSharp.ResourceProvider does not compile and does not load Resources library:
type Resources = SqueakyApp2.Android.Resource
Known workarounds
Use Paket instead of NuGet. Looks like Paket in a magical way works with this.
But Paket does not support MonoAndroid11 and MonoAndroid12 (link1, link2)
I also found out that there is no way to add back Xamarin.Android.FSharp.ResourceProvider 1.0.0.28 after remove:
Could not install package 'Xamarin.Android.FSharp.ResourceProvider 1.0.0.28'. You are trying to install this package into a project that targets 'MonoAndroid,Version=v10.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
I tried to install Xamarin.Android.FSharp.ResourceProvider 1.0.1 and it is installed successfully but this version does not work (link1, link2) and I getting the same error as above with warning:
Referenced assembly '/Users/nikolay/.nuget/packages/xamarin.android.fsharp.resourceprovider/1.0.1/lib/monoandroid81/Xamarin.Android.FSharp.ResourceProvider.Runtime.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found
Related information
Provide any related information (optional):
- macOS 12.1
- Xamarin.Android Version: 12.0.0.3 (Visual Studio Community)
- Visual Studio Community 2019 for Mac Version 8.10.16 (build 2)
Activity
Happypig375 commentedon Jan 25, 2022
Duplicate of #10837, xamarin/Xamarin.Android.FSharp.ResourceProvider#9, and dotnet/android#6404
TimLariviere commentedon Jan 25, 2022
In general, the state of mobile development with F# is a real mess right now.
Just to name a few:
Xamarin.Android.FSharp.ResourceProvideras mentioned here (1.0.1never worked)net6.0-iosandnet6.0-android(I don't even know if we can create Android project with F# on .NET 6.0)Sorry for hijacking this issue and venting my frustration, but we could really use some help from Microsoft on the F# + Mobile front. :)
Dolfik1 commentedon Jan 25, 2022
I have successfully ported our F# mobile app to net6.0-ios. It seems most of code works without any issues. I also successfully ran sample app on net6.0-android (but without using android resources).
7sharp9 commentedon Jan 25, 2022
@TimLariviere These things tend to happen people move to different companies and departments and were never replaced, things enter maintenance mode and are forgotten etc. A lot of the F# integration used to be open source, but Im not sure if parts were made internal after the acquisition. I think the F# droid stuff was internal to be honest, now I think back to when I was there.
7sharp9 commentedon Jan 25, 2022
The type provider could be replaces by Myriad too to make it easier to maintain in the future and open source.
nosami commentedon Jan 25, 2022
Xamarin.Android.FSharp.ResourceProvider was originally written by myself because of issues with the F# and CodeDOM provider that came before it that couldn't easily be fixed (F# doesn't support public static fields and Xamarin.Android required these). The problem was that I was never supposed to work on that as I was always part of the VSMac team not Xamarin.Android.
I later moved to the Codespaces team which meant that I was even further removed from Xamarin.Android work. At the time that I moved, I handed over Xamarin.Android.FSharp.ResourceProvider for maintenance to the XA team but it seems like bitrot set in pretty quickly.
I've since returned to the VSMac team, but now that VSMac shares much of the same codebase as Visual Studio, there is no longer any need for dedicated F# staff on the Mac side of things so I mostly work on other areas such as the debugger but have spent a lot of time recently porting parts of the UI to Cocoa.
I could work on the type provider in my spare time, but I have very little of it. It is open source though so anyone could work on it if they wanted to.
I enquired about the state of play with MAUI and net6.0-android. The plan is to ditch the C# code generation completely (which the F# type provider uses in the background) and use IL generation instead which at least in theory should work for all dotnet languages. See comment by @dellis1972 This should make the type provider completely redundant.
TimLariviere commentedon Jan 26, 2022
Thanks for the replies
I was not asking for you or anyone to work on their spare time, especially if it's not even your day job.
The message I wanted to convey was more like it would be really appreciated if Microsoft as a whole would consider .NET to not be only C#, and put on the roadmap some F# to get some basic support on everything labeled
.NET.Such an example is
PackageReferencein Visual Studio (Win) in old style fsproj.VS Mac and Jetbrains Rider support it since a long time ago. VS Win doesn't which is a deal-breaker because most developers use this one.
More than 3 years ago, I tried to submit a PR to fix that but most of what was required was not open-source and the response I got was "Won't do it. Wait for Xamarin to move to sdk-style".
Now we're 2022, C# seems to have got it. F#, still very bumpy.
Sure, we could stay with
packages.configand wait.But since C# has moved away from that years ago, all IDE tooling and Xamarin teams are slowly removing support for it.
"Just use PackageReference." Well, we can't :(
It's that kind of experience that makes it so frustrating.
I'll try to fix my main issues. Just hoping getting reviewed, merged and released won't take months since ownership is from teams at Microsoft...
@nosami Could I ping you if I happen to be stuck on non open-source stuff, so you could try to relay the message internally to the right people?
@Dolfik1 Would you happen to have an empty
net6.0-androidwith F#?I know there is this one for iOS: https://github.com/edgarfgp/Net6iOSTemplate
It would be great to release those templates on NuGet for both iOS and Android (and Xamarin.Forms too).
I tried on my own to convert from C# to F#, but got inflate errors...
Dolfik1 commentedon Jan 26, 2022
The generated resource file also contains
partialclass which is also not supported in F#We can try to fix type provider on our own. I think the main problem is the wrong type provider's project configuration.
I am agree with @TimLariviere. F# reduces development time and provides the ability to write more compact and reusable code. But at the moment we have to spend a lot of time solving tooling/mono/AOT problems instead of solving business problems. At the moment we want to migrate to .Net 6 because some of our problems seem to be solved.
I will attach sample app but it is incomplete without type provider.
I also wrote a migration script from an old-style project. This script is not perfect but mostly works with few manual changes. (this script does not support packages.config, only Paket is supported)
migrator.fsx.zip
Net6Sample.zip
TimLariviere commentedon Jan 26, 2022
Thanks!
I have created a repository to centralize all F# 6.0 templates for mobile development:
https://github.com/fabulousfx/net6.0-mobile-fsharp
This will be helpful to package them for
dotnet newand put them on NuGet.Later, I'll include Xamarin.Forms and maybe MAUI if I get it to work.
I'll take a look at the issue with the Android Type Provider as well.
nosami commentedon Jan 26, 2022
Sure! You can email me at
jasonimison [AT] gmail [DOT] comorjaimison [AT] MSor I have an email rule to notify me if I am mentioned on GitHub.I think personally I would stay with F# 5 and Mono until MAUI comes out. This issue should be resolved automatically.
gsomix commentedon Jan 26, 2022
@TimLariviere Hey, could you create issue in your repository? I'll take a look.
charlesroddie commentedon Jan 26, 2022
"F# support is broken in Xamarin.Android" suggests that creating Xamarin.Android apps using F# has problems. The issue is much smaller, that creating a Xamarin.Android platform project in F# has problems.
Simplest solution is for
dotnet new -i Fabulous.XamarinForms.Templatesto generate C# Xamarin.Android projects which depend on an F# Fabulous Xamarin.Forms netstandard project.Platform head projects are very tooling-dependent and F# projects are always going to be in a cycle of breaking and being fixed and lagging or non-existent tooling. (Unless sdk-style projects fix all problems?)
Dolfik1 commentedon Jan 26, 2022
We used FSharp.Core 4.7.2 for a long time due to AOT issues on iOS. Last month we updated FSharp.Core to version 6.0.2 and it seems that most of the issues have been fixed. But we got new issues with VTable setup on Android in System.Text.Json library (I still don not fully understand what happened, but it looks like the problem is that 6.0.2 supports netstandard2.1 while 4.7.2 does not). It looks like it has been fixed somehow in .Net 6.
Moreover, I do not really believe that all problems will be fixed on MAUI release.
8 remaining items
dsyme commentedon Jan 31, 2022
Well, it would be good to get issues raised in the correct repos - literally none of the above is implemented in this repo, so this is just not the right place to be discussing this. The product owners for Xamarin.Android etc. are ultimately responsible here and you need to be talking with them.
dsyme commentedon Jan 31, 2022
@nosami Do we have a canonical issue link for this?
Anyone have a link to any specific outstanding issues on this?
Anyone got any links to this? TBH I'm not too surprised by this given the old templates used the old project format, and were VS-only, and I think actually only VS-for-Windows (or was it VS-for-mac?). They'd need to be replaced by command line
dotnet newtemplates.nosami commentedon Jan 31, 2022
Not as far as I know. Mono is being superceded by .Net Core. There are no plans to support F# 6 in Mono.
I'm currently getting F# 6 working in VS Mac, but that's a separate issue.
dsyme commentedon Jan 31, 2022
Right, I think that's part of the issue here - it's been hard to justify the udpate when Mono is being replaced within Xamarin stack. So much chicken and egg.
❤️ ❤️ ❤️ ❤️
Dolfik1 commentedon Feb 1, 2022
The main problem at this moment it is the type provider. I have created an issue at November 12 but still no solution. For this reason, I decided to create an issue in this repository to draw more attention to the problem.
This is not possible at the moment (at least for android) due to type provider issues. So we first need to solve type provider problem. I really like what @dellis1972 does but I am afraid at the moment this cannot be a solution, since it is not known how soon it will be released. For this reason, I think we still need to solve the problem with the type provider.
However at the moment, nothing prevents you from create templates for iOS.
dsyme commentedon Feb 1, 2022
What if you just don't use the type provider and address the resources by string? i.e. the generated code that the type provider produces?
Dolfik1 commentedon Feb 1, 2022
instead of
This way is also unsafe because you can make a typo in resource name. It is also more difficult to refactor.
dsyme commentedon Feb 1, 2022
Yes, but it works and unblocks.
TBH I was always skeptical about putting a type provider into the main path of such a corner case of the Xamarin build story. I would have absolutely no problem with ripping it out of any defaults and making it a community-provided optional add-on that the community maintains - we don't bake in type providers like FSharp.Configuration into .NET Core projects even though they are also useful. If we expect the Xamarin team to maintain F# support we need things to be really simple for them.
Dolfik1 commentedon Feb 1, 2022
You are absolutely right. But for now, we have what we have. There is good news about IL generated assembly for resources but still we need some temporary solution.
At the moment @TimLariviere is trying to revive the type provider but there are some difficulties.
TimLariviere commentedon Feb 3, 2022
FYI: I abandoned trying to revive the type provider (too many issues with it) and did a small MSBuild target to build the C# designer file as part of the build.
https://github.com/fabulousfx/FSharp.Android.Resource
A little rough for the moment, but it works with both .NET Framework and .NET 6.0!
It's a drop-in replacement for
Xamarin.Android.FSharp.ResourceProvider.Should be good enough until we get dotnet/android#6427
nbevans commentedon Feb 4, 2022
That's a very simple solution @TimLariviere one wonders why the original impl didn't just do this? Looking forward to the IL generation though.
dsyme commentedon Feb 4, 2022
It should have, a type provider wasn't the right solution for this case, especially in retrospect.
dsyme commentedon Mar 3, 2022
Closing as the workaround is to use the community alternative here: #12640 (comment)
[Xamarin.Android.Build.Tasks] _Microsoft.Android.Resource.Designer (#…