
After more than three years, still no F# support for .NET Native and UWP - TensorMetric
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9110134-f-support-in-net-native-for-uwp
======
TensorMetric
> After one year since has been flagged as WORKING ON IT , the support for
> .NET Native is not even in roadmap
> [https://github.com/Microsoft/visualfsharp/issues/2400](https://github.com/Microsoft/visualfsharp/issues/2400).

And see comments here

[https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-
start...](https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-started-with-
f-as-a-c-developer/)

> 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...](https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-320984143)

> 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...](https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-293248047)

> @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...](https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-305949873)

> 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.

