How can we improve the Windows dev platform?

F# support in .Net native for UWP

There has been some discussion on the blog post for supporting F# in the .Net native toolchain for UWP. I had posted this on the VS uservoice site but it looks like that was the wrong place to do that. I hope the votes that request got will be considered for this. A lot of people are moving to F# PCLs for library code and to be able to use those PCLs in the UWP and get native compilation via .Net native tools would be great.

871 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Krishna shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

F# team just posted an update on their GitHub.

This is still a work in progress. One key thing from that post is some of these features and fixes have already been underway for months. While we’ve been investigating F#-specific issues in .NET Native, the team has continued to improve .NET Native. One feature known as “universal shared generics” is likely to have improved .NET Native’s support for F#, even without that being an explicit goal of the feature.


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Ryan Riley commented  ·   ·  Flag as inappropriate

    Hi, Clint. I think many of us want .NET Native support for IoT purposes. Many others, including my company, build mobile apps in F# on Xamarin and would like to be able to also support Windows.

    F# library support in Windows 8 (PCL) was very weak and had many problems. For the most part, it was easier to port the code to C# than to try to get it to work. Also, given MS did not support F# all the way to the UI layer, you were certain to see very low adoption.

    As a better metric, consider the use of F# for building Xamarin applications on iOS and Android. While still a small percentage, I think you'll find it significantly higher than what you saw in the Windows Store. Full support goes a long way to giving you more reliable metrics.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I absolutely need this for Nu Game Engine, the world's first practical, pure functional game engine in F# -

    While the game engine is already reasonably fast, there's no reason it should be bottlenecked by the JIT, or to have be an even more significant resource drain on mobile. Not to mention start-up times!

  • Anonymous commented  ·   ·  Flag as inappropriate

    I spent 6 years with c#, spent a year with f# and I do not want to go back. Please support

  • Amy Damerow commented  ·   ·  Flag as inappropriate

    Please please please support this. I've been writing in F# so long that it's painful trying to rewrite my library code in C#. It'd be nice if I could re-use all this work I've already done.

  • Richard commented  ·   ·  Flag as inappropriate

    This will indeed be very much appreciated. With my entire team moving to F# for almost everything, it will be nice to be able to use it everywhere.

  • Sergey commented  ·   ·  Flag as inappropriate

    Sorry, I've accidently clicked "Flag idea as inappropriate…" on this idea. Please ignore this.

  • Sebastian commented  ·   ·  Flag as inappropriate

    Would be very amazing to have also full F# on UWP, since i started to use F# on the last months is really a pain have to go back on UWP

  • David Neale commented  ·   ·  Flag as inappropriate

    F# generated assemblies really need to be fully supported, not just PCLs. Functional coding is very much the up and coming way to build all kinds of software and the single biggest market is going to be UWP apps across all device types so we really shouldn't be forced back to imperative coding for those, when we can make higher quality apps (less bugs, better use of multiple cores etc.) using F#.

1 2 3 5 Next →

Feedback and Knowledge Base