DEV Community


What tooling do you use for F# on .NET Core

Kasey Speakman
collector of ideas. no one of consequence.
・2 min read

The Problem

I have tried F# on .NET Core a number of times now. With the Core 1.x release, and now the Core 2.0 release. Both times I have been disappointed to discover that tooling is still basically broken (compared to .NET Framework F# tooling).

For instance using VS 2017 15.5.whatever, the Add Above and Add Below gestures are entirely missing from the Solution Explorer. So I have to hand-edit the project file to put a new file in the order I want it. Then I have to unload and reload the project. This is a significantly annoying regression from the behavior of .NET Framework projects on the same IDE. Definitely feeling the 2nd-class-citizen sentiment from Microsoft there.

Note for onlookers: Adjusting file order is not me being OCD, it is a very common operation. Because F# uses a single-pass compiler, files are compiled in the order listed in the project file. If you don't keep files in some semblance of dependency order, the code will not compile.

I also tried VS Code with Ionide-F#. It is quite an excellent plugin, but I've had a few problems with it as well. For instance, when I tried to use the Move Up/Down gestures in the F# Solution Explorer, it changed the .fsproj file in such a way that it would no longer open (!!!). I also had the experience when I attempted to add a new project to a solution (also thru F# Solution Explorer), it took on the order of 3 minutes for the operation to complete. (A message bar was stuck at the top saying it was working during that time. Although I could see that the .fsproj file had been added, I could not make use of it.)

The Appeal

So basically my experience so far is that F# tooling for .NET Core is still not-quite-there yet. So I'm wondering how you other F# folks get along on .NET Core. Do you just put up with the irritations or is there some justWork: true setting I can tweak or some other workflow I can use? I could put up with some of it for tinkering, but for our production software I really don't want to have to document all the work-arounds. For now I have kept my projects on Framework, waiting for tooling to catch up. But I have some use cases I am eager to hit with .NET Core (docker/linux). Dear reader, please advise me.

Discussion (3)

eljayadobe profile image

I've been doing little toy programs with F#, using Visual Studio Community for Mac (

Note: I've done most of my F# work on a Mac. Previously with Xamarin, which has had an amazing amount of renovation/consolidation into Visual Studio Community. I've read quite a few F# books, but the only one that I've liked so far is The Book of F# by Dave Fancher. I just got Expert F# 4.0 by Don Syme this week, I haven't read it yet.

In Visual Studio Community for Mac, the F# side works great. The FSI (F# Interactive) works great. Not as great as an actual REPL, but we're not programming in Lisp, so I'll just have to be satisfied with what we have.

Plumbing up F# to Cocoa has been a bit more difficult than when I plumbed up F# to WPF (Visual Studio, on Windows). The majority of the difficulty being lack of examples, tutorials, and guidance.

kspeakman profile image
Kasey Speakman Author

Answering my own question. Apparently Ionide has fixed the issue with corrupting the project file. I used it last night to create a console app in a solution. I reordered files multiple times without issue. So I guess that is currently the best experience. I haven't tried to add other projects to the solution thru the VS Code yet (added the initial project thru the command line).

kspeakman profile image
Kasey Speakman Author

Answer #2. Now that Visual Studio (2017) 15.6 is out, the dev experience of F# on dotnet Core is at least as good as it was on Framework.


Forem Open with the Forem app