FAKE - F# Make - A DSL for build tasks and more FAKE
Edit this page

Lookig for older versions of the documentation, pre FAKE v6? See 


Migrating from FAKE v4


In this tutorial you will learn how to migrate your existing build scripts to the new FAKE 5 and above dotnet-core version.

First we want you to know that there are two versions of FAKE 5 and above. One is just an update to the regular FAKE 4, but also contains the new API. We will call this the "legacy FAKE version" it is just like the FAKE you are already used to. The second version is the "new/dotnetcore/standalone FAKE 5" or just "FAKE". This "new" version has several advantages:

Therefore you have the FAKE 5 timeframe to update your build scripts to the new version. If you have any issues in the migration process, please see how to fill issues or discuss about your issues (don't be shy about contributing ;)).

Migration Guide

Upgrading to FAKE 5 is a multi step process and has various manual steps in between. If you do these steps out of order it will be a lot harder for you to migrate the script successfully. Here are the steps:

Use the new FAKE-API

After upgrading to legacy FAKE 5 the warnings should tell you exactly what you do. If there is stuff missing or a warning message should be improved let us know. Some warnings indicate how we want the new FAKE version to be used.

The most important part to know is that basically every feature/function changes its location and sometimes they were even grouped in different modules as the old API was growing several years now and we never could do breaking changes.

In this new world you should write "Module.Method a b" instead of "MethodModule a b". Which means in the old world we had lots of methods like "ReadFile argument" (the module probably even opened via [<AutoOpen>]), which is considered bad style now. In the new world we would open the Fake.IO.FileSystem namespace to indicate that we are using the file-system. At the same time we would write File.Read argument, which is only a bit longer but now the IDE can help you a lot better and the code looks a lot more idiomatic and clean.

The "open Fake" and AutoOpen modules are completely obsolete. We urge you to finish your API-Migration (after fixing all warnings) by removing "open Fake". This removes a lot of automatically opened stuff and if your build fails you have probably stuff where we forgot to add the obsolete warning (let us know) or that stuff you are using was not migrated yet (let us know or send a PR, see Contributing to FAKE).

Add FAKE dependencies

All your dependencies no longer are bundled with the FAKE nuget package (or the FAKE distribution for that matter). This has some advantages:

The drawback however is that you now need to know where stuff lives and add those packages to your build.

Already a paket user?

For now it's quite simple: The namespace or module name is used as the package name, just search for the package and then add it to the dependencies file to a new group (for example netcorebuild).

Not a paket user?

No problem! For most use-cases it is enough to find the NuGet package of the module (most times they have the same name for easier discovery) and add it to your script:

#r "paket:
nuget Fake.Targets prerelease
nuget MyPackage1
nuget MyPackage2"

Now delete <script>.fsx.lock and run fake run <script>.fsx now you can use intellisense to start using the modules.

If you want to read more about the possible syntax you can use here, please consult https://fsprojects.github.io/Paket/dependencies-file.html and https://fsprojects.github.io/Paket/nuget-dependencies.html.

Once you feel more confident with using to paket infrastructure you can move your dependencies into a paket.dependencies group and use

#r "paket: groupref netcorebuild //"

CLI Migration

Yes we even broke the CLI. The old CLI was actually a mixture of two different CLI styles, confused a lot of users and to be honest was an ugly hack. It was obvious that we would not even try to make things compatible with it in any way. However your changes should only be minimal in the most cases. I'd say in 80% its just about adding the run verb between the fake.exe and the build script. fake build.fsx will be fake run build.fsx. Running a particular target is as easy fake target will be fake run build.fsx --target target. For a full reference use --help or the documentation.

If you used special cases which aren't mentioned here please edit this page or open an issue.