F# and .NET Core Roadmap Update

Now that .NET Core 2.0 has been released, we wanted to take some time to talk about F# and .NET Core.

F# and .NET Core 1.0

F# has been supported on .NET Core and .NET Standard since their 1.0 releases. In the months leading up to the release of .NET Core 1.0, Enrico Sada from the F# community worked with us and other teams at Microsoft to add support for F# projects in the .NET Core CLI and SDK. Enrico continued to work with us and other teams to ensure quality F# support as .NET Core tools evolved from project.json to MSBuild. We also focused on Portable PDB generation during this time so that F# was supported when debugging on .NET Core. When Visual Studio 2017 was shipped, we declared full support for F# running on .NET Core 1.0 and 1.1.

F# and .NET Core doesn’t end at what Microsoft and Enrico worked on. The rest of the F# open source community has embraced .NET Core, porting many libraries over to it. The most impressive of which is Fable, which allows you to use the entire JavaScript ecosystem to write F# code that runs in the browser!

Today, F# on .NET Core 1.0 and 1.1 is used in production by many people, and many F# libraries have ported to .NET Standard. We continue to see adoption on .NET Core, and believe that it will be the primary target for F# developers in the coming years, especially now that .NET Core 2.0 has been released.

F# and .NET Core 2.0 and .NET Standard 2.0

Our top priority since the release of Visual Studio 2017 has been to ensure the quality of F# when targeting .NET Core 2.0 and .NET Standard 2.0. Another priority was to ensure that F# could be built from source with .NET Core. This is critically important for many Linux users, who expect to be able to build their entire development stack from source on the machines they run code on. It can also greatly extend the reach of F# and .NET Core. These sources will also be shipped on RedHat Enterprise Linux.

Starting with the release of .NET Core 2.0 and .NET Standard 2.0, all of the changes we have made for F# support in .NET Core 2.0 will be in-box with the .NET Core SDK and .NET Core CLI. Additionally, we have backported in-box support for F# running on .NET Core 1.0.4 and .NET Core 1.1 in the version of the .NET Core SDK that ships with Visual Studio 2017 version 15.3. We’re also working with the maintainers of highly-used open source projects to ensure they work well on .NET Core 2.0 and .NET Standard 2.0.

The best way to use F# and .NET Core today

The best way to use F# and .NET Core today is in Visual Studio Code with the Ionide-FSharp extension. This should come as no surprise to F# developers already using .NET Core today. Ionide supports many things, including project scaffolding, IntelliSense, and debugging.

There are only three dependencies required to create, build, run, and debug F# applications on .NET Core today:

Once you have configured your application for debugging, just like with C#, you can use F# in Visual Studio Code to do nearly anything you want with F# and .NET Core!

Visual Studio tooling support

For long time .NET developers, a common question is "when will Visual Studio support F# .NET Core projects". We’re working hard to get this functionality ready, but unfortunately, we’re not quite happy enough with the quality in the 15.3 update to announce that it’s fully supported. While Visual Studio 2017 version 15.3 is able to open the new F# .NET Core projects, build, and debug them, IntelliSense does not yet work correctly.

All .NET Core projects now share a common simplified project format that you’ve hopefully seen by now. This means that we share a common core component of the IDE referred to as the Common Project System (CPS). This dependency will enable us to develop at a much greater pace, rather than maintaining the large, complicated, and specialized code base designed specifically for F# projects. Unfortunately, CPS does not yet support file ordering in the tree view of the Visual Studio UI.

We knew that this would prevent ordering files in the Visual Studio UI until tree ordering was implemented. However, we did not know that the component of CPS which sends files to the F# language service also did not support file ordering. This was discovered a few weeks into the implementation of F# support in the Visual F# tools themselves. The F# language service is what powers F# IntelliSense. Due to receiving files out of order, our language service isn’t able to understand a project’s F# code, resulting in false negative error reporting and a lack of IntelliSense in certain cases. Our work in offering stable support for .NET Core 2.0 took us beyond the window that we were able to fix this issue in CPS for the 2017 15.3 release.

F# Interactive and Type Providers

.NET Core introduces a different model for how assemblies are laid out on disk and loaded by a process such as F# Interactive. This model breaks #r in F# Interactive. Rather than add workarounds in F# Interactive, we are going to move forward with a plan to use a package manager to resolve assemblies and change the way that you use #r from here on out.

Our goal is to move you away from specifying assemblies on disk and towards referencing a package by name and optional version. That may look like this:

We’re still working out the design and default behavior. It will be backwards-compatible, but we’re using .NET Core as a precedent to move towards this new way to reference things in F# scripting and F# Interactive.

Type Providers are also a work-in-progress on .NET Core:

Erasing Type Providers work with this workaround today. In the near future, the workaround won’t be necessary.

Generative Type Providers are still unsupported on .NET Core and have no workaround at this time.

Conclusion

F# is stable on .NET Core, there is a great tooling experience with Visual Studio Code, and much of the F# open source ecosystem is already running on .NET Core today. Although the entire developer experience isn’t complete yet, we are working hard on it. Each of the important remaining parts – Visual Studio support, F# Interactive, and Type Providers – have a way forward and are being worked on. We’re really excited about the release of .NET Core 2.0 and .NET Standard 2.0, and we look forward to seeing more and more people use F# and .NET Core in the future.

The relationship between .NET Core and .NET Native is a bit complicated. When running a debug build of a UWP app, it will run locally on .NET Core. F# works just fine there. But when compiling for a release build to submit to the Windows Store, it will use the .NET Native backend compiler toolchain to generate an application file with the .NET Native runtime baked in. It is in this step that F# is not supported.

It is the best experience for F# _on .NET Core_ today, yes. We’re working on Visual Studio support for .NET Core tooling. You should try Visual Studio Code! It’s absolutely amazing software, and the Ionide plugin is top-knotch.

I long for the days when MS told us wait until July for VS2017 support for F# support with .NET Core. We’re a sneeze away from September and we’re still waiting. Glad F# got the first class citizen treatment from MS.

All this obsession with web stuff to write F# programs is a big turnoff to all the people I talk with. You can’t even write a simple UWP app without having to deal with yet another web framework. This is really sad since the language is vastly superior to C#.

Apple is upping their game by pushing modern languages like Swift and the JVM has Kotlin and Scala, yet Microsoft insists on writing UWP apps with outdated languages like C#, while they have this gem of F# which they neglect.

C# lacks features like discriminated unions and has wrong defaults like null references by default, which results in brittle and verbose code. The language in general is too verbose and there is too much boilerplate to do even the simplest things. Instead of trying to fix the language with workarounds, they should start a new language from scratch or migrate users towards F#, or at least treat F# like a first-class citizen next to C# and VB.NET so that we can write UWP apps with it.

compared to Scalas caps both C# and F# are outdated … if only the syntax was not that ugly

1 year ago

Franky

That’s true.

Another thing is the obsession on having clean 2-way interop between F# and .NET stagnated F#. We could have had ML functors or higher-kinded types by now.
F# is what made .NET bearable for us, but we’re seriously considering alternatives now that don’t include any of the Microsoft platforms or languages.

Visual Studio Code is pretty lame IMHO. I would rather Microsoft spend there time working on bringing Visual Studio forward and porting it to 64 bit, something they refuse to do. Watching Microsoft kiss up to Linux fans is getting old. It is like corporate Democrats trying to be Republicans.

While I think that cross platform support and Linux support is commendable, it shouldn’t be at the expense of Windows support, which is what is happening now.
It feels like F# has been hijacked away from Windows leaving many of us who invested in F# early on left behind.

Rather odd comment with a silly political message shoed in for no apparent reason (and I’m not even clear what it is you’re trying to say). In the server world Linux is king and the sensible folks at Microsoft are starting to figure this out, it’s nothing to do with ‘sucking up’ to anyone they’re just going where developers and businesses are.

We’re working with folks who also work on C# interactive to come up with a design (and set of principles) that make sense for everyone. F# is one of the key stakeholders in this work, but because the concepts can be extended to C#, we also want to come up with a good shared design so that powerful scripting is a great experience on .NET Core.

Not at this time, no. We actually have a prototype working with full file ordering supported (including in the UI), and we do have a target release, but there is no concrete date for that release right now. We’ll announce more on GitHub as this work stabilizes.

I understand the lack of VS tooling support for .net core, does this also extend to .net standard? I have a number of f# pcl libraries I would like to migrate to .net standard, do you think I can go ahead or should I hold off?

This does indeed also extend to .NET Standard. Projects targeting .NET Standard and .NET Core both use the same underlying code in Visual Studio to load and manage projects. The same issues with .NET Core tooling support for F# in Visual Studio apply to .NET Standard.

That said, Visual Studio Code and the .NET CLI work wonderfully right now. Many people are already using them to port PCL libraries over to .NET Standard. I think you should definitely give them a try.

Hi Phillip,
Many thanks for reply, had not seen that clarified anywhere in the release notes. That is clear once you do the VS 15.3 upgrade as there are still no F# .netstandard/core templates.
I have a pretty gnarly mix of pcl, xamarin, .net F# and C# projects so I think the VS Code route is not an option for me.

Oh well, will hang in there for the VS tooling support and hope it comes in soon.

I see! Yes, that would indeed block you. If you’re up for it, you can actually use the .NET CLI to create a .NET Standard project in your solution, load it into VS, copy code over, and compile/run/debug/etc. However, IntelliSense will not be in a good place, and it won’t be a very good experience. But it could unblock you if you’re okay with that subpar experience for the time being. We actually disabled the F# templates for .NET Core and .NET Standard because we didn’t want to give any impression that the tooling support was a good enough experience. But those same templates are in the .NET CLI, so when the tooling support for F# and .NET Core ships in a fully supported state, the project types won’t be any different.

Playing devil’s advocate here (or glass half full rather than half empty) with other commentators here on .Net Core and UWP.
As far as I can tell .Net Core is primarily for cross platform server side use, which practically speaking boils down to Linux or Windows. If you’re developing primarily for Linux, then use VS Code & Ionide, there is no Visual Studio for Linux anyway. If you’re developing for Windows, then why not just use the very stable full fat .Net platform until Visual Studio and .Net Core has stabilized.
I’d agree it would be nice to have UWP support for F#, but again in all practicality, if you’re developing mobile apps then use Xamarin to target over 99% of phones with iOS and Android. The recent figures I’ve seen online show Windows Phone represents less than 1% of the market. If, for whatever reason, you want to target the Windows Store, the Windows 8 development tools let you target Window 10, and there’s always F# to JavaScript…

The mobile Windows story isn’t that clear cut anymore with all the hybrids and upcoming mobile devices. Note that Windows Mobile will be replaced with proper Windows on telephony capable devices, which Windows Mobile detractors conveniently don’t mention.

And don’t forget, that a modern desktop app is expected to use UWP with Fluent Design.

And regarding F# to JS, one should not have to mess around with web technologies for Windows apps, also many use cases cannot afford the performance hit.

I’m currently working on a mobile app for conferences using F# and Xamarin, targeting Android and iOS, and I can’t currently justify the development effort for Windows Phone based on user numbers.
I have also built recently commercial desktop apps with F# and C# using WPF, which was the only option that lets you target Windows 7, 8 and 10. Most of the user base I’ve been targeting has been on Windows 7 (enterprise users), and in my current organization most of the clients are still on 7.
Agreed JS for Windows apps (regardless of F#) is not going to work for everyone.
I’d be genuinely interested in knowing more about the scenario you have where you need to support Windows Mobile and Windows Store (but not Windows 7?).

Hi Phil.
Agree on .net core being primarily for linux and ignorable for windows developers. .net standard though has wide-ranging advantages unrelated to linux.
About UWP, yes it has minimal market share for phones, but it does have significant desktop share. If you code in Xamarin, you get a Windows 10 app for free with C#, but not with F#. Xamarin is aiming for WPF support but work on that is only beginning. Windows 8 is possible now and that is the approach we are taking at the moment but most new components do not support Windows 8.

Great idea on using packet managers for referencing assemblies, but in my opinion is best to use a new symbol for that, instead of #r use #rp or #p, I assume that the implementation will require a form of packet manager configuration too #pm

I don’t think so. This would require F# support in Razor Pages, which is right now tied to C# (and C# only – no VB.NET either). Perhaps there might be a way to use some of the foo.cshtml files within the F# project, but since they’re also tied to foo.cshtml.cs files, and there’s no way to mix C# and F# source code in the same project, I don’t see that as a way forward. I would suggest opening an issue on the ASP.NET MVC GitHub to request F# support for Razor Pages.

I’m glad to know about F# community via .NET Core news. I hope F# could be suitable for my next project.
Besides, I wonder if .NET Core team have any plan for adopting TypeScript as a high-level language on CLR?
Is there any technical problem when adopting TypeScript?