Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
F# Status on CoreRT and UWP #6055
[2018-12-06 update] F# UWP apps can be released on the Windows Store.
Recent testing has assessed the compatibility of F# with CoreRT and .NET Native. Only minor issues have been found, which are easily worked around (see specific issues below).
CoreRT issues can always be tracked and worked on here, and .NET Native issues can now also be tracked now that users can compile using it (See gatekeeper.xml section).
This post is a documentation of the status of F# and CoreRT as requested by @dsyme. This post will be kept up to date. One purpose is to inform F# developers using CoreRT and .NET Native. The second purpose is to inform the request for allowing F# usage on the Windows Store, a 1 line change that may require approval.
CoreRT and .Net Native went through basic tests (the F# cheatsheet), and specific tests (tail calls and highly nested generics as recommended by @MichalStrehovsky, and some of the F# test suite). .Net Native was further tested in a production app using typical F# structures (a symbolic algebra engine using large discriminated union trees, standard usage of record types, reactive UI using Xamarin.Forms, SQLite). CoreRT is used by a number of F# users already. (@ChrisPritchard has written a number of games without encountering any issues.)
Of the issues affecting UWP, lack of support for .tail does not break typical F# code (as Fable and historically mono AOT prove), and the other two issues have simple workarounds.
See https://github.com/FoggyFinder/FSharpCoreRtTest/blob/master/README.md#description-of-current-issues for more detail, and the MainIssues branch for relevant code.
.Net Native: gatekeeper.xml blocks F#
The remaining problem is a non-technical one. F# usage of .Net Native is blocked by gatekeeper.xml.
This can be disabled on user systems to enable compilation with .Net Native, allowing creation of working UWP apps. However these apps cannot be successfully uploaded to the store since they will fail the F# test when compiling on Microsoft servers. We therefore need official editing of GatekeeperConfig.xml, either by turning it off or by replacing
Reasons to allow F# UWP applications on the Windows Store:
let mi = typeof<ObjectPrinter>.GetMethod("GenericToString", NonPublicStatics) let mi = mi.MakeGenericMethod(ty) mi.Invoke(null, [| box spec |])
There is no general issue with F# quotations; the only issue we have found is with LINQ. The function causing the problem is Microsoft.FSharp.Linq.RuntimeHelpers.LeafExpressionConverter.QuotationToExpression. This gives a fail fast error.
E.g. if db is an sqlite connection,
LINQ requires care even from C# and inherently uses a lot of reflection I suppose.
F# query expressions seem to work OK.
We are looking into removing the F# blocking in the Store compilation machines for the next release of .NET Native for UWP apps.
F# will remain officially unsupported, but we'll not prevent people who understand the implications (and who did enough testing to make sure it works okay for their use case) from uploading to the Store. People will still need to hack their local Visual Studio installation to remove the blocking locally because we don't believe the experience of using F# with the level of support the .NET Native compiler has is anywhere near pleasant.
The focus of the .NET Native team has been on completing ARM64 support in the next release. The work to lift the remaining technical limitations to fully support F# is unfortunately non-trivial.
For an example of the technical limitations on top of the issues found by the testing in the top post, you can try this:
namespace FSharpLibrary module Fib = let rec fib = function | n when n=0I -> 0I | n when n=1I -> 1I | n -> fib(n - 1I) + fib(n - 2I)
The .NET Native compiler will emit a couple warnings about unsupported LDTOKEN instructions to stdout (there's several places in
We can likely fix this easily in a future FSharp.Core (e.g. change to emit
That would help! We've had an issue open to make it work for a long time. It never met the bar because we thought only IL obfuscators emit that kind of IL (and we have hack in place that checks if the subsequent instruction is a simple
What version of the .NET Native compiler did you use? I used 2.1.8. Also, do did you modify the RD.XML in the empty UWP app template? The problem goes away after removing the
No, I didn't. My rd (without comments and whitespaces):
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata"> <Application> <Assembly Name="*Application*" Dynamic="Required All" /> </Application> </Directives>
Version of FSharp.Core: 4.5.2
Direct access to UWP UI classes from F# depends on either
Until then F# can only be used 1. in parts of a solution that don't have to reference controls directly (i.e. models, viewmodels), or 2. indirectly via Xamarin.Forms.