Install .NET and run F# Interactive

Installing F# means installing one thing, the .NET SDK.NET SDK: The kit you install to build .NET code: the dotnet command, MSBuild, NuGet, the C# and F# compilers, F# Interactive and a .NET runtime. Without it, dotnet fsi and dotnet build cannot run.: SDK 10.0.401 carries the F# compiler, F# InteractiveF# Interactive: The REPL and script runner of the .NET SDK, started with dotnet fsi. At the prompt it compiles and runs each entry that ends with ;; and answers with the name, type and value. and a copy of FSharp.Core 10.1.401. On the computer that recorded this lesson, a one-line script then took 2.5 to 3.6 seconds from the command to the end of its output, nearly all of it starting .NET and compiling the script: a cost that shapes how you use scripts.

This lesson installs and checks the SDK, pins it for a folder, uses F# Interactive both as a prompt you type at and as a script runner, pulls a NuGet package into a script with an exact version, and sets up an editor.

The .NET SDK is the only thing to install

Microsoft’s install page for F# offers three routes. On a computer where you build from the command line or with VS Code, install the .NET SDK from Microsoft’s download page or your platform’s package manager, as the .NET install guides for Windows, macOS and Linux describe. With Visual Studio, F# comes with the ASP.NET and web development workload. On a build server, the page says, the .NET SDK has everything you need. Install the .NET 10 SDK: .NET 10 is the long-term support release this track uses.

Then check what you got. These are the checks on the recording computer, in a folder whose global.json pins SDK 10.0.401 (DOTNET_ROOT is the folder the SDK is installed in):

from session import run

# The checks after installing the .NET SDK: the SDK dotnet picks in this folder, every SDK it could pick, the F#
# Interactive inside it, and the F# files the SDK folder holds (DOTNET_ROOT is the folder the SDK is installed in).
run("""
dotnet --version
dotnet --list-sdks
dotnet fsi --help | head -n 1
ls "$DOTNET_ROOT/sdk/10.0.401/FSharp" | grep -E '^(fsc|fsi|FSharp[.]Core)[.]dll$'
ls "$DOTNET_ROOT/sdk/10.0.401/FSharp/library-packs"
""")

$ dotnet --version
10.0.401
$ dotnet --list-sdks
10.0.401 […/dotnet-root/sdk]
$ dotnet fsi --help | head -n 1
Microsoft (R) F# Interactive version 15.2.401.0 for F# 10.0
$ ls "$DOTNET_ROOT/sdk/10.0.401/FSharp" | grep -E '^(fsc|fsi|FSharp[.]Core)[.]dll$'
fsc.dll
FSharp.Core.dll
fsi.dll
$ ls "$DOTNET_ROOT/sdk/10.0.401/FSharp/library-packs"
FSharp.Core.10.1.401.nupkg

dotnet --version prints the SDK that dotnet picks in this folder and --list-sdks every SDK installed. The first line of dotnet fsi --help names F# Interactive and the language it compiles, F# 10.0. The last two commands show that F# lives inside the SDK folder: fsc.dll is the compiler that builds projects, fsi.dll is F# Interactive, and library-packs holds the FSharp.Core 10.1.401 package, so a new F# project finds FSharp.Core without downloading it.

global.json pins the SDK for a folder, scripts included

Several SDKs can be installed side by side, and by default every dotnet command uses the newest one. A global.jsonglobal.json: A JSON file that pins the .NET SDK for its folder and every folder below it. dotnet looks for one in the current folder and each parent, and its rollForward value says how strictly the version must match. file chooses another for its folder and every folder below it: dotnet looks for one in the current folder, then in each parent, and the first it finds decides. The F# 6 notes add that dotnet fsi follows it too, so a script is checked and run by the SDK the folder pins. This session writes one with dotnet new globaljson, then pins a folder to an SDK that is not installed:

from session import run

# global.json pins the SDK for a folder and every folder below it, for dotnet fsi as well as for builds.
# mywork pins the installed SDK; pinned-ahead asks for 10.0.500, which is not installed here.
run("""
mkdir mywork pinned-ahead
cd mywork
dotnet new globaljson --sdk-version 10.0.401 --roll-forward latestPatch
cat global.json
dotnet --version
cd ../pinned-ahead
dotnet new globaljson --sdk-version 10.0.500 --roll-forward disable
!dotnet fsi --help
""", terminal=True)

$ mkdir mywork pinned-ahead
$ cd mywork
$ dotnet new globaljson --sdk-version 10.0.401 --roll-forward latestPatch
The template "global.json file" was created successfully.
$ cat global.json
{
  "sdk": {
    "rollForward": "latestPatch",
    "version": "10.0.401"
  }
}
$ dotnet --version
10.0.401
$ cd ../pinned-ahead
$ dotnet new globaljson --sdk-version 10.0.500 --roll-forward disable
The template "global.json file" was created successfully.
$ dotnet fsi --help
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'fsi' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 10.0.500
global.json file: pinned-ahead/global.json

Installed SDKs:
10.0.401 […/dotnet-root/sdk]

Install the [10.0.500] .NET SDK or update [pinned-ahead/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
[exit status 155]

In mywork the pin is met and dotnet --version prints 10.0.401. In pinned-ahead nothing matches 10.0.500, so even dotnet fsi --help stops with exit status 155 and names the global.json that asked for it. How strictly a pin matches is its rollForward value:

Every examples folder of this track pins 10.0.401 with disable, so the recorded runs come from exactly that SDK. In your own projects prefer latestPatch: Microsoft supports only the newest servicing update, and a pin that refuses every patch also refuses its security fixes.

F# Interactive runs an entry once you end it with two semicolons

dotnet fsi with no file starts F# Interactive, a REPLREPL: Read, evaluate, print loop: a prompt that reads an entry, runs it, prints the result and waits for the next one, so code can be tried a line at a time.: it reads an entry, compiles and runs it, prints the result and waits for the next. An entry ends with two semicolons, ;;; until you type them, Enter only starts a new line of the same entry, shown after a - prompt. Here is a first session:

from session import fsi

# A first session in F# Interactive: each entry ends with ;; and the answer names every value with its type.
fsi([
    "let price = 250;;",
    "let total qty =\n    price * qty;;",
    "total 4;;",
    "it + 1;;",
    "let price = 300;;",
    "total 4;;",
    "totl 4;;",
    "#quit;;",
])

$ dotnet fsi
Microsoft (R) F# Interactive version 15.2.401.0 for F# 10.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> let price = 250;;
val price: int = 250

> let total qty =
-     price * qty;;
val total: qty: int -> int

> total 4;;
val it: int = 1000

> it + 1;;
val it: int = 1001

> let price = 300;;
val price: int = 300

> total 4;;
val it: int = 1000

> totl 4;;

  totl 4;;
  ^^^^

stdin(8,1): error FS0039: The value or constructor 'totl' is not defined. Maybe you want one of the following:
   total

> #quit;;

Every answer is a val line with a name, the type F# Interactive inferred and the value. total 4 has no name of its own, so its value is bound to it, which the next entry used to get 1001. The typo totl stopped with error FS0039, and the message suggested total; the session carried on, because a failed entry changes nothing. Step through the six entries before it:

The surprise is the last answer. let price = 300 did not change price: it defined a second value with the same name, which hides the first one from later entries. That is shadowingshadowing: Defining a new value with a name that is already in use. Later code sees the new value, while code compiled earlier keeps the value it was compiled with., and total was compiled with the first price, so it still answers 1000.

Lines that start with # are directives to F# Interactive rather than F# code. #quit ends the session, #time switches timing on and off, and since F# 9 #help followed by a name shows that function’s documentation:

from session import fsi

# Two directives of F# Interactive: #time measures every entry, #help shows a function's documentation.
fsi([
    '#time "on";;',
    "List.sum [ for i in 1L .. 1_000_000L -> i * i ];;",
    '#time "off";;',
    "#help List.map;;",
    "#quit;;",
], args=["--nologo"], keep_times=True)

$ dotnet fsi --nologo
> #time "on";;

--> Timing now on

> List.sum [ for i in 1L .. 1_000_000L -> i * i ];;
Real: 00:00:00.079, CPU: 00:00:00.014, GC gen0: 0, gen1: 0, gen2: 0
val it: int64 = 333333833333500000L

> #time "off";;

--> Timing now off

> #help List.map;;

Description:
Builds a new collection whose elements are the results of applying the given function
to each of the elements of the collection.

Remarks:
This is an O(n) operation, where n is the length of the list.

Parameters:
- mapping: The function to transform elements from the input list.
- list: The input list.
Returns:
The list of transformed elements.

Examples:
let inputs = [ "a"; "bbb"; "cc" ]

inputs |> List.map (fun x -> x.Length)
// Evaluates to [ 1; 3; 2 ]

Full name: Microsoft.FSharp.Collections.ListModule.map
Assembly: FSharp.Core.dll

> #quit;;

With timing on, every entry reports its real time, the processor time it used and how many garbage collections of each generation ran. Summing a million squares took under a tenth of a second here, with no collection. The other directives that matter early are #r for packages and assemblies, which the last part of this lesson uses, #load for another script and #i for a package source.

A script runs from top to bottom and prints only what it prints

A scriptscript: An F# source file with the .fsx extension that dotnet fsi compiles and runs from top to bottom, with no project file. It can reference NuGet packages with #r directives. is a .fsx file that dotnet fsi script.fsx compiles and runs from top to bottom. Arguments after the file name reach the script in fsi.CommandLineArgs, whose first element is always the script’s own name. This one adds up the whole numbers it is given:

#!/usr/bin/env -S dotnet fsi
// tally.fsx: adds up the whole numbers given after the script's name.
let args = fsi.CommandLineArgs
printfn "Arguments: %A" args

let numbers = args[1..]
let bad = numbers |> Array.filter (fun s -> not (fst (System.Int32.TryParse s)))

if bad.Length > 0 then
    eprintfn "Not a whole number: %s" (String.concat ", " bad)
    exit 2

let total = numbers |> Array.sumBy int
let twice = total * 2   // a script prints only what it prints: there is no val line for this
printfn "%d numbers, total %d" numbers.Length total

from session import run

# tally.fsx run as a script, with good and bad arguments, then directly through its first line (macOS and Linux).
run("""
dotnet fsi tally.fsx 12 30 8
!dotnet fsi tally.fsx 12 thirty 8
chmod +x tally.fsx
./tally.fsx 5 5
""")

$ dotnet fsi tally.fsx 12 30 8
Arguments: [|"tally.fsx"; "12"; "30"; "8"|]
3 numbers, total 50
$ dotnet fsi tally.fsx 12 thirty 8
Arguments: [|"tally.fsx"; "12"; "thirty"; "8"|]
Not a whole number: thirty
[exit status 2]
$ chmod +x tally.fsx
$ ./tally.fsx 5 5
Arguments: [|"./tally.fsx"; "5"; "5"|]
2 numbers, total 10

Three things differ from a session at the prompt. Nothing is echoed: let twice = total * 2 defines a value but prints no val line, so a script shows only what it prints itself. A problem can end the script with a status of your choosing, here exit 2 after eprintfn wrote the message to standard error, which a calling script or a build step can test. And on macOS and Linux the first line, #!/usr/bin/env -S dotnet fsi, lets the file run as a command once it is executable, as ./tally.fsx 5 5 did; on Windows, run dotnet fsi tally.fsx.

Each run starts .NET and F# Interactive afresh, and that start is most of the cost of a short script:

from session import run

# How long a one-line script takes from start to finish (/usr/bin/time -p prints real, user and system seconds).
run("""
/usr/bin/time -p dotnet fsi hello.fsx
/usr/bin/time -p dotnet fsi hello.fsx
""", keep_times=True)

$ /usr/bin/time -p dotnet fsi hello.fsx
Hello from F# on .NET 10.0.12
real 3.55
user 1.19
sys 0.63
$ /usr/bin/time -p dotnet fsi hello.fsx
Hello from F# on .NET 10.0.12
real 2.46
user 1.15
sys 0.32

The two runs of a one-line script took 3.6 and 2.5 seconds of real time on the recording computer, which was busy with other work, and about 1.2 seconds of processor time each on the user line; the million squares above took under a tenth of a second. Almost all of a short script’s time is starting the runtime and compiling the script. Keep related work in one script rather than many tiny ones, and explore at the prompt, where the start-up is paid once.

Scripts reference NuGet packages with #r, pinned to a version

A script can use any NuGet package without a project file: #r "nuget: Name, Version" at its top makes dotnet fsi restore the package before the script runs. This session has no network, so it first shows what that means for a package that is in no source the computer can reach. Then it packs two versions of a small library, Paise, into a local folder, and runs scripts whose nuget.config names that folder as their only package source:

#r "nuget: Paise, 1.0.0"

printfn "Paise %s: %s" Paise.Money.version (Paise.Money.format 123456L)

from session import run

# The network is off in this session. First a script whose package is in no source this computer can reach; then a
# folder of packages made here, two versions of a small library called Paise, and scripts that a nuget.config points
# at that folder.
run("""
!dotnet fsi offline/pinned.fsx
dotnet pack Paise -o feed -p:Version=1.0.0 -v q
dotnet pack Paise -o feed -p:Version=1.1.0 -v q
ls feed
cd scripts
/usr/bin/time -p dotnet fsi pinned.fsx
/usr/bin/time -p dotnet fsi pinned.fsx
ls ~/.nuget/packages/paise
dotnet fsi latest.fsx
""", keep_times=True)

$ dotnet fsi offline/pinned.fsx


offline/pinned.fsx(1,1): error FS0999: ~/.packagemanagement/nuget/Projects/<id>/Project.fsproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.
[exit status 1]
$ dotnet pack Paise -o feed -p:Version=1.0.0 -v q
$ dotnet pack Paise -o feed -p:Version=1.1.0 -v q
$ ls feed
Paise.1.0.0.nupkg
Paise.1.1.0.nupkg
$ cd scripts
$ /usr/bin/time -p dotnet fsi pinned.fsx
Paise 1.0.0: Rs 1234.56
real 9.17
user 2.74
sys 0.87
$ /usr/bin/time -p dotnet fsi pinned.fsx
Paise 1.0.0: Rs 1234.56
real 3.85
user 1.02
sys 0.27
$ ls ~/.nuget/packages/paise
1.0.0
$ dotnet fsi latest.fsx
Paise 1.1.0: Rs 1234.56

The offline run failed before a line of the script ran, with error NU1301: the package was in no folder on the computer and nuget.org was out of reach. With the local source, the first run of pinned.fsx restored Paise 1.0.0 and took 9.2 seconds of real time; the second found it in ~/.nuget/packages, the global packages folderglobal packages folder: The folder where NuGet keeps every package version it has restored, ~/.nuget/packages by default. A later restore of the same version takes it from there instead of from a source., and took 3.9. Step through the first run, then the second:

The last command is the reason to pin. latest.fsx is the same script with #r "nuget: Paise" and no version, and the F# Interactive reference says such a reference takes the highest version available that is not a preview. The moment 1.1.0 existed, the same script printed Paise 1.1.0: an unpinned script can change its output with nobody touching it. A nuget.config next to the script decides where packages may come from, which matters for build agents without internet access; #i "nuget: <folder>" adds a source too, but the reference notes it does not accept relative paths yet.

Three editors understand F# through the same compiler

Any editor can open a .fsx file, but these three check F# as you type, run scripts in F# Interactive and load projects:

Microsoft’s install page for F# names Ionide as the only plugin VS Code needs, and its VS Code guide describes Ionide as an open-source project built and maintained by members of the F# community. Whichever editor you choose, it uses the SDK that the folder’s global.json pins, the same one dotnet fsi uses at the command line. Notebooks are no longer an option to plan around: Polyglot Notebooks and .NET Interactive, which ran F# in notebooks, were deprecated and their repository archived, so this track uses .fsx scripts for exploring.

Practise: installing, running and referencing

Here are questions on the SDK, global.json, the prompt, scripts, package references and editors. They arrive one by one, weakest idea first, and whichever answer you pick, the explanation of why it works or fails opens straight away:

Interview questions

Warm-up (fresher to 2–5 years): what is F# Interactive, and when would you use a script instead of a project?

F# Interactive, started with dotnet fsi, is the REPL and script runner that ships in the .NET SDK. At the prompt it compiles and runs each entry ending with ;; and prints a val line with the name, type and value; given a .fsx file it runs the script from top to bottom and prints only what the script prints. Scripts suit exploration, automation, data checks and one-off tasks: they need no project file, can reference NuGet packages with #r "nuget: Name, Version", and receive arguments in fsi.CommandLineArgs. A project suits code that several files make up, that is compiled into an assembly, tested, packaged or deployed, and code that must start fast, because a script compiles on every run.

Two harder questions follow, about a script whose output changed by itself and about scripts on build agents without internet access:

Key takeaways

• The .NET SDK is the one thing to install: it carries the F# compiler, F# Interactive and FSharp.Core, and dotnet --version and dotnet fsi --help show what you got.
• A global.json decides which installed SDK every dotnet command in its folder uses, dotnet fsi included; latestPatch suits projects, disable reproduces a recorded output exactly.
• At the prompt, an entry ends with ;;, an unnamed result becomes it, and a second let with the same name shadows the first while older functions keep the value they were compiled with.
• A script runs from top to bottom, prints only what it prints, reads its arguments from fsi.CommandLineArgs and can end with exit; most of a short script’s time is start-up.
• #r "nuget: Name, Version" restores a package into the global packages folder on the first run; pin the version, or the script changes its output whenever a newer one appears.