dotnet/fsharp: The compiler, core library, and editor tooling that define F#

What this repository actually contains

The dotnet/fsharp repository is not a sample project or a library wrapper. It is the home of the F# compiler, the F# core library (FSharp.Core), the F# language service, and the F# tooling integration for Visual Studio. If you use F# in any serious capacity, you are indirectly using code that lives here. The README is explicit: the repository is for the compiler, core library, and editor tools. That means it is the place where language features are implemented, tested, and shipped. The repository also hosts the FSharp.Compiler.Service component, which is the API that powers editor features like IntelliSense and type checking outside the compiler executable. For anyone who builds F# tooling, that service is a key dependency. The README points to the F# Compiler Guide for public documentation of this component, so you can learn its API without digging through source code.

The three-repository language evolution process

F# language changes do not start here. The README describes a process that spans three repositories. First, ideas go to the F# language suggestions repo, where the community discusses and votes. Second, approved ideas become RFCs in the F# language design repo, where the technical specification is written. Third, implementations and tests land in this repository. This separation is deliberate. It keeps the compiler repository focused on code, not on debating syntax. It also means that a contribution to dotnet/fsharp should ideally be tied to an existing RFC. If you are new, the README points to a curated list of issues labeled help wanted and good first issues. That is a concrete entry point. The process is heavier than a typical open source project, but it matches the scale of a language change. A typo fix is welcome, but a new feature will require design work elsewhere first.

Building on Windows, Linux, and macOS

The build system is straightforward on the surface. On Windows, run build.cmd. On Linux or macOS, run ./build.sh. The README warns that the Windows build depends on an installation of Visual Studio, but you can bypass that with build.cmd -noVisualStudio. After the build, you open FSharp.slnx or VisualFSharp.slnx in your editor. The latter includes the Visual Studio tooling and its infrastructure, so it is larger. On non-Windows platforms, only FSharp.slnx is mentioned. The exact .NET SDK version is pinned in the global.json file at the repository root. That is a critical detail: you must install that exact SDK, not just any recent one. The README also points to DEVGUIDE.md for configuration details and TESTGUIDE.md for running test suites. In practice, the README says you only need to run build.cmd or build.sh, but that hides the complexity of a compiler codebase. Expect the first build to take a while.

Per-build NuGet packages and their purpose

The README documents per-build NuGet packages for two series: 7.0.40x and 8.0.10x. These are preview packages of FSharp.Compiler.Service, available from Azure DevOps feeds. The README gives the exact feed URLs for each series, for example https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json for the 7.0.40x series. The note is important: official NuGet releases of FSharp.Compiler.Service and FSharp.Core are synchronized with SDK releases on purpose. Nightly packages go to Azure feeds on every successful insertion. This means if you want to test a feature before an official SDK release, you can use these feeds. But you must add the feed to your NuGet configuration, as shown in the XML snippet. The version numbers are preview versions, so they are not stable. For production code, you would wait for the official SDK release. This is a useful mechanism for early adopters, but it is not a substitute for the official NuGet package.

Branch strategy and servicing model

The repository uses a main branch for almost all contributions. The README states that main is built, installed, and used in the latest public Visual Studio release, and it may contain updated F# features. There are also release branches. The release/dev15.9 branch is a long-term servicing branch for VS 2017 update 15.9.x, though the README notes they do not expect to service that release. The release/dev17.x branches are for particular point releases of Visual Studio. They incorporate features and fixes from main up to a branch point, then selective cherry-picks. After the corresponding Visual Studio release is made, they are integrated back into main. This is a classic servicing model for a language that ships with an IDE. The implication for contributors is that your change to main may not reach a released Visual Studio version until the next branch point, unless it is cherry-picked. That is a real delay to factor in if you are fixing a bug that affects your own tooling.

Where this repository is the wrong tool

If you are an application developer, you do not need to clone dotnet/fsharp. The README points to the official F# documentation on learn.microsoft.com and to the F# Software Foundation for community support. The compiler repository is for people who want to change the language, fix compiler bugs, or build on FSharp.Compiler.Service. The build requirements are a barrier: on Windows you need Visual Studio unless you pass -noVisualStudio, and on any platform you need the exact SDK version from global.json. The codebase is described as daunting for beginners, even by the maintainers. The contribution process is also heavy, with a separate design repo. If your goal is just to write F# code, using the released SDK is faster and less error-prone. The repository is also not a good place to learn F#; the README directs learners to the F# Documentation instead. So this is a tool for contributors and tool builders, not for general users.

Alternatives and how they differ

The main alternative for F# tooling is the FSharp.Compiler.Service package distributed via NuGet. That package is built from this repository, but you consume it as a binary dependency. The difference is in approach: using the package lets you integrate F# analysis into your own editor or script without building the compiler. The repository source gives you the full control and the ability to patch, but at the cost of a long build and the need to track the branch strategy. Another alternative is the F# language service that ships inside Visual Studio, but that is part of this repository anyway. For language design, the alternative is the fslang-design repository, where RFCs live. If you want to propose a feature, that is the entry point, not this repository. So the practical choice is: consume the released package for stability, or work in this repository for change. The two are not interchangeable.

Maintenance costs and license implications

Maintaining a fork of dotnet/fsharp is a serious commitment. The repository is large, with a compiler, core library, and editor integration. The README does not give explicit maintenance instructions, but the branch strategy shows that keeping up with main requires regular integration. The release branches are cherry-picked, so a fork would need to track those changes. The license is MIT, per the README and the License.txt file. That means you can use the code in commercial projects, but you must retain the copyright notice. This is permissive, but it does not grant any trademark rights; F# and Visual Studio are Microsoft trademarks. The repository also has a Contributor Covenant code of conduct, which affects how contributions are handled. For a company considering a fork, the MIT license is favorable, but the ongoing cost of merging upstream changes is the real price. The README does not specify a release cadence, but the recent releases show preview versions tied to .NET 10, so expect regular updates.

Editorial conclusion

Adopt dotnet/fsharp if you need to contribute to the F# language itself, build a custom F# compiler, or integrate FSharp.Compiler.Service into your own tooling. Do not use this repository if you only want to write F# applications; the released SDK and NuGet packages are the right path. Before contributing, verify that your .NET SDK version matches global.json, and check the docs/index.md and DEVGUIDE.md for build and test procedures. The repository is the authoritative source for F# language changes, but its complexity and Visual Studio dependency on Windows mean you should budget time for the build and test suites.

Official sources

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