After more than three years, still no F# support for .NET Native and UWP
wpdev.uservoice.com
wpdev.uservoice.com
And see comments here
https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-start...
> There is no timeline for F# support on UWP. If you must use UWP for your workplace, then F# is not an option for you. We make no such claim that you can do this, though. If there is such a statement somewhere, please do let me know. I do not wish to mislead anyone.
>This is an interesting point:
>> Full tooling support, every single feature as VB.NET and C# have on Visual Studio.
> Is it your expectation that every programming language be supported across everything you can use in Visual Studio?
>> As for .NET Core, most of us on the enterprise hardly care about .NET Core beyond UWP, until it gets feature parity with .NET Framework.
> I will challenge this position. Perhaps you’ve not seen .NET Core in your organization, but we’ve seen strong adoption and significant interest in the enterprise for .NET Core. And this also goes beyond Visual Studio tooling. Many enterprises have developer who wish to program on macOS and deploy to Linux machines. We’ve made that a priority for .NET Core, and F# is every bit as capable as C# on that front. This has also been a significant area of growth for C#, F#, and .NET as a whole.
And here
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> No further news or updates on F# Support for .NET Native. There is no affinity between .NET Native, .NET Core, or VS 2017. It's an orthogonal area.
> There are three options:
> Use UWP Bridge
> Deploy elsewhere than the Windows Store
> Use Fable + React Native
See also this comment from the F# creator Don Syme.
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> @KevinRansom My impression was that F# libraries would likely work immediately in UWP (not coreclr native code gen) if tail. was ignored. I think it's up to the UWP team though, not the Visual F# Tools team. It's not a compiler problem, it's a runtime problem.
> To be honest, it appears UWP is simply not implementing the .NET specs correctly - tail. has been in all editions of the ECMA 335 CLI Standard... Mind you, generics have also been in that standard, with no mention of "limits of 7 deep" or anything like that. I'm always somewhat surprised when I see adhoc limitations that incorrectly implement the ECMA standard - I really thought that was a standard which mattered.
Come on Microsoft, this is unacceptable, you're driving existing and potential valuable programmers away from your platform and F#.
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> I found this thread tonight while looking for information about how to build a UWP application using F# in Visual Studio Community 2017. I kept seeing lots of references to C# .NET and VB.NET for this purpose, but suspiciously F# was missing. Which made me curious:
>> ... CAN you build a Universal Windows Platform native application with F#?
> And then I found this thread. I now regret investing any time in examining F# as a future development platform for any purpose. I'll probably never pay attention to it again, and I worry about the sincerity of any of Microsoft's future developer endeavors.
F# is a mature fully .NET compliant Microsoft language, it should be expected and a high priority to get the .NET Native UWP (your main client application platform) to accept F# code.
Most people I know invested in F# with the expectation to target modern Windows without fuss and workarounds. And no, UWP Bridge and Fable + React Native are not acceptable solutions.