dotnet/fsharp: the F# compiler, core library and editor tooling, and what it takes to build them

What dotnet/fsharp actually ships, and who it is for

This repository is the source of four things that are usually consumed separately: the F# compiler, the F# core library, the language service that powers editor features, and the tooling integration for Visual Studio. The README frames the audience directly by inviting contributions to "future releases of the F# compiler, core library, and tools", and by noting that development can be done on any OS supported by .NET. That sentence is the whole positioning. If you write F# applications, you normally take the compiler and FSharp.Core from a .NET SDK installation and never touch this tree.

The people who do touch it fall into three groups. Compiler contributors implement language changes that have already been approved through the RFC process. Tool builders consume FSharp.Compiler.Service to get parsing, type checking and symbol information inside their own editor or analyzer. Release engineers care about the branch layout, because main is described as buildable, installable and usable in the latest public Visual Studio release, while release/dev17.x carries fixes for a specific point release of Visual Studio and gets integrated back into main once that release ships. A fourth, quieter group exists: people who need to know whether a compiler behaviour is intended, and read the source because the specification does not settle it.

How the pieces fit together and where language changes enter

The README describes a three-repository process rather than a single workflow. Ideas go to the F# language suggestions repository, where they are searched, voted on and discussed. Suggestions that are "approved in principle" become eligible for an RFC in the F# language design repository, which is where the technical specification and the discussion of approved suggestions live. Only implementations and testing of an RFC are submitted here. That ordering matters if you arrive with a patch: a compiler change with no corresponding RFC has no obvious place in the process, and the README gives no route for one.

Inside the tree, the layout follows the build rather than the language. There are separate solution files: FSharp.slnx is the one the Linux and macOS quickstart tells you to open, FSharp.Compiler.Service.slnx isolates the service component, and VisualFSharp.slnx is described as larger because it includes the F# tools for Visual Studio and its associated infrastructure. A VSFSharpExtension.slnx also sits at the root. The docs directory holds the compiler documentation, which the README calls essential reading for any larger contribution and which is also published as The F# Compiler Guide. The language specification is hosted outside this repository, at fsharp.org, and the README explains why it is worth reading: name resolution order and behaviour are specified there, which drives how the name resolution code is written and why certain decisions were made.

Building the compiler from source on Windows, Linux and macOS

The README assumes you already have a .NET SDK, installed from the .NET download page, and it points at global.json in the repository root for the exact version required. Check that file before anything else, because the build will not negotiate a different SDK for you.

On Windows, the documented quickstart is a single script. It depends on an installation of Visual Studio:

build.cmd

If you do not have Visual Studio installed, the README gives an alternative that builds the compiler without that dependency:

build.cmd -noVisualStudio

On Linux or macOS the equivalent is a shell script, with no Visual Studio option mentioned:

./build.sh

After the build finishes, the README says to open FSharp.slnx in your editor of choice; on Windows you may instead open VisualFSharp.slnx, which is larger and includes the Visual Studio tooling. The README states that in practice you only need to run build.cmd or build.sh, and points at DEVGUIDE.md for the other configurations. For running individual test suites rather than the whole build, TESTGUIDE.md is the referenced source. There are also restore scripts, Restore.cmd and restore.sh, at the root, though the README does not walk through them.

Consuming prerelease FSharp.Compiler.Service packages

If your goal is to embed the compiler service rather than change the compiler, the README documents per-build NuGet feeds. Official NuGet releases of FSharp.Compiler.Service and FSharp.Core are synchronized with SDK releases on purpose, so if you need a fix that has landed on main but is not in an SDK yet, you add a prerelease feed. The README gives the feed for the 8.0.10x series as a NuGet.config key:

<add key="fsharp-prerelease" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json" />

A parallel entry exists for the 7.0.40x series under the dotnet7 feed path. The README adds that nightly packages release to Azure feeds on every successful insertion, which means the feed moves under you. Pinning an exact prerelease version is the only way to keep a build reproducible; the README does not describe a retention policy for old nightly versions. The most recent release listed is v14.0.100-preview7.25380.108, aligned with .NET 10.0 Preview 7, and the two before it are also beta or preview builds tied to .NET 10.0 previews. Nothing in the release list indicates a stable channel for the service outside SDK synchronization.

The contribution path is documented; the maintenance burden is not

The README is unusually welcoming about entry points. It says no contribution is too small, including a single-character typo, and acknowledges that the codebase can feel daunting for beginners. It points to a curated list of open issues labelled help wanted, asks contributors to indicate interest in the issue comments, and separately labels good first issues. That is a real onboarding path, and it is more concrete than most compiler repositories offer.

The limitation is that the README says nothing about how long a change takes to reach users, or what happens to a change that lands on main but depends on a forthcoming Visual Studio release. It notes that release/dev17.x may contain new features that depend on new things or fixes in the corresponding forthcoming Visual Studio release, which implies a change can sit in a branch for an extended period before it is generally available. There is also no documented rollback or revert process, and the README does not describe how a regression in a nightly VSIX is handled. If your organization needs a predictable date for a compiler fix, this repository will not give you one.

A second, sharper limitation: this is the wrong tool for anyone who wants to write F# rather than work on it. The README explicitly redirects community documentation to the F# documentation on Microsoft Learn, whose source lives in dotnet/docs. Cloning this repository to learn the language gets you a compiler you must build before you can compile a line of code, when an SDK install would have given you a working fsc in minutes.

How this differs from OCaml and from the .NET SDK

The comparison that recurs in search data is F# against OCaml, and the repositories make the difference visible. dotnet/fsharp is a compiler targeting .NET, with FSharp.Core as its core library and FSharp.Compiler.Service exposed as a component you can host in an editor; the language evolves through the suggestions and design repositories described above. OCaml's compiler, core library and tooling live in a different ecosystem with its own release process, and there is no shared component that lets you embed OCaml's type checker in a .NET editor the way FSharp.Compiler.Service is meant to be embedded. The practical consequence is that choosing F# buys you .NET interop and a language service designed for third-party hosts, while choosing OCaml keeps you in its own toolchain.

The second alternative is the .NET SDK itself. For almost everyone, the SDK is the right way to get F#: it carries a released compiler and FSharp.Core, and it does not require you to build anything. This repository is the layer beneath that, and its release notes are tied to SDK previews precisely because the two are meant to move together. Reach for the source tree when you need behaviour that no released SDK contains, or when you are the one building the tool that other people will install.

Licence, upgrade cost and what to verify before you commit

The repository is under the MIT License, with the text in License.txt at the root. MIT is permissive, so redistributing a modified compiler or embedding FSharp.Compiler.Service in a commercial product is the kind of use the licence contemplates; this is a description of what the licence says, not legal advice, and anything beyond that belongs with your own counsel. Note that the tree contains attributions.md, which suggests third-party notices are tracked separately from the main licence file. Read both.

Upgrade cost is dominated by the SDK pin. The README tells you the exact SDK version lives in global.json, and the releases listed here are preview builds tied to .NET 10.0 previews, so moving to a newer compiler generally means moving your SDK as well. The repository also has an .editorconfig and a .fantomasignore, which implies formatting is enforced through Fantomas; a patch that ignores the formatter will likely need rework before it is reviewed. The build itself has a Visual Studio dependency on Windows unless you pass -noVisualStudio, so a machine without Visual Studio can still build the compiler but not the full tooling solution. Before investing time, confirm three things: that global.json matches an SDK you are willing to install, that you can complete build.sh or build.cmd -noVisualStudio, and that docs/index.md covers the area you intend to touch.

Editorial conclusion

Adopt this repository if you are changing the F# language, fixing the compiler, or embedding FSharp.Compiler.Service in an editor or analysis tool; its MIT licence and the documented build scripts make that work tractable. Do not clone it to learn F# or to start an application: the language documentation lives in dotnet/docs and the quickest path to a working F# project is the .NET SDK. Before committing, read docs/index.md and DEVGUIDE.md, confirm the SDK version pinned in global.json, and run build.sh or build.cmd -noVisualStudio once to see whether your machine can produce the compiler at all.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes