Fix for "Package manager key paket was not registered" in build.fsx

Question

When I open a Fake build script in Visual Studio Code, like this:

> dotnet new -i fake-template
> dotnet new fake
> dotnet tool update fake-cli
> code build.fsx

I see this error message in the editor and none of the Fake namespaces, modules, or types are defined:

Package manager key 'paket' was not registered in
c:\Users\wallace.kelly\.vscode\extensions\ionide.ionide-fsharp-5.4.0\bin\
Currently registered: nuget

How do I correct this error?

Running dotnet fake build works fine. The error just appears in the editor.

I have "FSharp.dotNetRoot": "C:\\Program Files\\dotnet\\sdk", in my Settings file. That folder includes folders 2.1.701 2.2.401 3.1.407 5.0.103 and 5.0.104.

Answer 1

maintainer of Ionide for VS Code here. That's error's just going to happen from here on out. FAKE is behind in its versions of the FSharp.Compiler.Services, and without updates to that component the integration we have with FAKE has atrophied to the point where the editor shows errors in that script.

There are a few solutions:

• continue to use FAKE and just deal with editor issues
• stop using FAKE as the script runner, but continue to use FAKE libraries from a build project or 'standard' fsx script
• use another build system of some kind
• contribute updates to FAKE (and by extension the deprecated code in Ionide)

etc etc.

Answer 2

I just got rid of the warning by using a ifdef.

#if FAKE
#r "paket:
nuget Fake.DotNet.Cli
nuget Fake.IO.FileSystem
nuget Fake.Core.Target //"
#endif
#load ".fake/build.fsx/intellisense.fsx"
open Fake.Core
open Fake.DotNet
open Fake.IO
open Fake.IO.FileSystemOperators
open Fake.IO.Globbing.Operators
open Fake.Core.TargetOperators

Target.initEnvironment ()

Target.create "Clean" (fun _ ->
    !! "src/**/bin"
    ++ "src/**/obj"
    |> Shell.cleanDirs 
)

Target.create "Build" (fun _ ->
    !! "src/**/*.*proj"
    |> Seq.iter (DotNet.build id)
)

Target.create "All" ignore

"Clean"
  ==> "Build"
  ==> "All"

Target.runOrDefault "All"

Answer 3

Following up on Chester's answer, I've opted to use FAKE libraries in a build console project. This is sometimes referred to as the build.fsproj pattern. It's actually straightforward to convert your script to this pattern, and I've found the debugging and tooling support to be much better. Unfortunately at the time of writing there's no official documentation of this pattern.

In essence you need to:

• Create a new fsharp console project (build.fsproj)
• Put your existing build script in the project (build.fs)
• Include your dependencies in the project using paket or nuget
• Add an [<EntryPoint>] to your script
• Call your project using dotnet run. Probably from a build.cmd or build.sh file

The best examples I've found to work from are:

• MiniScaffold
  • In particular the /build/ directory
• SAFE-Dojo
  • They even have some documentation: Add build automation

I ended up including the helper.fs file from SAFE-Dojo as it made the conversion super easy. Basically the script ends up being:

//
// Existing FAKE script open library calls go here
//

open Helpers
initializeContext()

//
// Existing FAKE script body goes here
//

[<EntryPoint>]
let main args = runOrDefault args

MiniScaffold has nice build.cmd and build.sh scripts. Here's the build.cmd:

echo Restoring dotnet tools...
dotnet tool restore

dotnet run --project ./build/build.fsproj -- -t %*

If you've got an existing script that uses environment variables then the -- -t %* portion is superflous.

I first saw the approach mentioned in this tweet.