Announcing F# support for .NET Core and .NET Standard projects in Visual Studio

We’re pleased to announce that Visual Studio 2017 15.5 Preview 4 now supports F# projects targeting .NET Core, .NET Standard, and .NET Framework through the .NET Core SDK. Some of you have noticed various levels of this support in the first, second, and third previews. We still had a few work items left to complete when those were released, so we didn’t announce the support at that time. These work items are now complete!

Get started

Firstly, support for F# is now included by default in any Visual Studio workload which requires the .NET Core SDK. The .NET Core workload, ASP.NET workload, and Azure workload will all now install F# support by default:

If you install any of these workloads, you can then create new .NET Core/.NET Standard projects with File | New Project:

The current preview has support for Console Apps, Libraries, and Unit test projects.

Existing projects created via the .NET Core CLI can also be opened in Visual Studio. Here is a video of an existing project I have that I didn’t create in Visual Studio 2017:

What’s new

There are several new features in this new project support, and if you’ve used it with C# and .NET Core or .NET Standard projects, you’ll likely know about all of them. Here are a few that I like:

Project files are significantly smaller, often by an order of magnitude.
Project files are editable without having to unload the project.
You can edit a project file (e.g., adding a package) and when it’s saved, the project system will automatically react to those changes (such as restoring an added package).
NuGet dependencies, the SDK reference, and project-to-project references are unified under the Dependencies node.

Expanded functionality with Web SDK projects

The project I opened used the Giraffe library, which provides functional API routing atop the Kestrel HTTP Server. Because this project type uses the Microsoft.NET.Sdk.Web attribute in its project file, it is rendered as a web project in the UI. But that’s not all:

Application publish tooling all works with F# projects as well. Publishing this web app to Azure App Service through Visual Studio works the same way as C# projects. But it doesn’t end there. You can also use these projects with Visual Studio Team Services to set up a CI/CD pipeline:

The Continuous Delivery Tools for Visual Studio can be used on these F# project types to autogenerate a CI/CD pipeline which publishes to Azure App Service. There’s little bit of configuration left to do in the generated Build and Release Definitions after auto-generating them, but it’s very simple to tweak.

Naturally, you can configure the release definition to publish wherever you like – it just uses Azure in the Visual Studio tooling that generates the definitions right now. As other teams at Microsoft continue to expand this sort of functionality, these F# projects will see all those benefits.

Get started with F# and Web SDK projects

You can easily create Web SDK projects in F# with the .NET Core CLI, which also ships with Visual Studio. The following three commands will create projects using ASP.NET Core:

dotnet new webapi -lang F# dotnet new web -lang F# dotnet new mvc -lang F#

Project templates for these project types will be available in a future release of Visual Studio 2017. Community templates which use the web SDK (such as the Giraffe template) will also have all of the above benefits.

The road ahead for F# and .NET Core

Although we’ve come a long way with F# and .NET Core, there are still some remaining issues left for us to address:

After creating a new project-to-project reference, the Error List in Visual Studio can show errors, even though you get IntelliSense and your project builds. You can close/reopen documents for the errors to go away.
Solution Explorer does not show the compilation order of files after you first add them and move them in the project file. If you reload a project, ordering will be shown correctly.
Folder support is limited – all folders are rendered above files in the root directory of a project. We’re going to work out a design on how to handle this gracefully with file ordering in mind.
C# libraries must first be built before their symbols are visible in F# projects.
F# and ASP.NET Core templates are not yet available in the File | New project dialog.
We’re going to continue improving our cross-platform debugging support, specifically in Portable PDB generation.
Performance of solution loading and cross-project IDE features in large .NET Core/.NET Standard solutions is still a place where major investments are being made by the team which owns the underlying project system F# uses for these project types. F# will benefit from all of these investments.
Type Provider support for .NET Core is arriving towards a design that will enable quality support on .NET Standard and .NET Core. This redesign will involve changes to Type Provider libraries.
We’ll also soon begin work on enabling F# Interactive for .NET Core. This will be nontrivial work, so we don’t have an estimated date of completion at this time.
There are no Visual Studio templates for F# Azure Functions yet. We’re also going to work with the Azure Functions team to ensure that F# templates for different Function types will be in a forthcoming release.

Finally, we are laying the groundwork for a long-term effort of migrating all F# projects to the new project system that .NET Core and .NET Standard projects use. This will enable us to retire our current, F#-specific project system that .NET Framework projects use today. We’ll first do this by “dogfooding” our own codebase. There is no timeline for when this will happen, as it is a long-term effort, but it is a major goal of ours because it enables us to hand off project system concerns to experts in that space so that we can focus on the F# compiler and F# tooling.

Send us feedback!

We’re very excited for you to use this new tooling support, and we highly appreciate everyone who finds issues and sends us general feedback. You can file issues on our GitHub repository, which is where we do most of our work. We’ll also move issues created with the Visual Studio feedback tool over to GitHub, so you can use that, too. Thank you, and happy F# coding!