.NET Core 1.0 Update for F# Tooling

.Net Core 1.0 with Ionide in VS Code

Back in October, I blogged about Using F# with .NET Core The tooling at the time was still a release candidate. Well a lot of things under the hood have changed about the tooling. There was the move from project.json to MsBuild which caused quite a bit of controversy.

That said, there were significant changes to the tooling. All the application models and frameworks are exactly the same.

To demonstrate the changes, I’ve made this short video to show some of the changes that were made to the .NET Core Tooling.

Getting started with .NET Core using F#

Highlights

No More Project.json

Project.json was meant to be a new project system/file format. It was quite awesome. However, It was designed for a strictly web server environment and didn’t play well with the existing .NET codebases. Here are some reasons:

• A project.json class library from a regular .NET Application, you had to first compile it into a Nuget package and then host said package on Nuget. Referencing exisiting .NET DLLs required the same hassle which was too much to ask.
• Project.json wasn’t extensible and lacked some of features like including settings from other files and incremental compilation. Features that were already in MsBuild
• It would mean a complete re-write of a lot of build systems and tooling not just for Microsoft but for the ecosystem as a whole.

That said, the team decided to overhaul MsBuild with all the nice features of project.json and they were able to come up with in what is in my opinion the best of both worlds.

Console FSProj

All the cruft has been tucked away leaving only the really important bits

Welcome back, Solution Files

One of the advantages of moving back to MsBuild is that we now have the ability of build and restore multiple projects simultaneously. We can accomplish this by creating a solution file and registering our project files (fsproj) in it. That way, when you use dotnet restore at the solution file level it will restore all packages in that solution without you having to do it for each project.

Typically we use Visual Studio to manage solution files but now a command line utility helps us manage them.

• dotnet new sln — Creates a new Solution file
• dotnet sln add path/to/fsproj — Adds a new F# project to the solution
• dotnet sln remove path/to/fsproj — Removes an F# project from the solution
• dotnet sln list — Shows list of projects registered in the solution

Project Referencing

Referencing other projects is pretty much the same with the regular MsBuild. Except that MsBuild now supports referencing Nuget Packages directly

Again, you can also add packages or projects from the command line. Note that you need to be in the project directory (directory with fsproj)

• dotnet add package NugetPackageId — Adds a new Nuget Package to a project
• dotnet add reference path/to/fsproj — Adds a project reference to another project file

Conclusion

Like I said in the last post, All the .NET Core tools for building real world applications using F# are available and ready. You can use all the existing frameworks and libraries and tools without much friction.

We are even starting to see innovation from the community like the Giraffe framework, which is an F# web framework for asp.net core. It replaces the Object Oriented Asp.Net Core MVC with a Functional framework. But still plugs in to the already existing eco-system of middleware and tools available for .NET Core. He also has a blog post detailing the rationale/tutorial for the framework. Its worth checking out