Could not find a suitable .NET 6 runtime version matching SDK version: 7.0.100

[nojaf]

Description

I cannot my FAKE using dotnet 7 sdk.

Repro steps

global.json:

{
  "sdk": {
    "version": "7.0.100"
  }
}

install fake-cli 6.0.0-alpha003.
Create empty fsx file.
Run dotnet fake run build.fsx

Consider adding your dependencies via `#r` dependencies, for example add '#r "paket: nuget FSharp.Core //"'.
See https://fake.build/guide/fake-modules.html for details.
If you know what you are doing you can silence this warning by setting the environment variable 'FAKE_ALLOW_NO_DEPENDENCIES' to 'true'
Updating group Main in C:\Users\nojaf\Projects\fake-dotnet7-repro\.fake\build.fsx\paket.dependencies
Resolving dependency graph...
Updated packages:
  Group: Main
    - FSharp.Core: 7.0.0 (added)
Starting full restore process.
Starting task 'DotNet:version': running dotnet --version
7.0.100
Finished (Success) 'DotNet:version' in 00:00:00.1310713
Performance:
 - Cli parsing: 91 milliseconds
 - Packages: 639 milliseconds
   - Resolver: 498 milliseconds (1 runs)
      - Runtime: 28 milliseconds
      - Blocked (retrieving package details): 50 milliseconds (1 times)
      - Blocked (retrieving package versions): 419 milliseconds (1 times)
   - Disk IO: 14 milliseconds
   - Average Request Time: 144 milliseconds
   - Number of Requests: 2
   - Creating Runtime Graph: 1 millisecond
   - Retrieve Assembly List: 2 seconds
 - Script analyzing: 11 milliseconds
 - Runtime: 2 seconds
There was a problem while setting up the environment:
-> Could not find a suitable .NET 6 runtime version matching SDK version: 7.0.100

Expected behavior

It should not fail.

Actual behavior

I find it weird to see a complaint about finding no dotnet 6 runtime.
The check above did find the correct 7.0.100 version

Known workarounds

/

Related information

• Operating system: Win 11
• .NET 7
• Version of FAKE (4.X, 5.X) 6.0.0-alpha003

[yazeedobaid]

The FAKE runner is locked to .NET 6 runtime assemblies. In FAKE v6. the support for NETSTANDRD 2.0 has been dropped in the runner and it only searches for a .NET 6 SDK references assemblies. If it cannot find any, then the runner will fail with this message.

Supporting multiple reference assemblies causes problems before when we supported NETSTANDARD2.0 and NET 6, and we had to do some workarounds to overcome them - and some we could not, hence we dropped support for NETSTANDARD.

Locking runner to .NET 6 and making it a requirement to use FAKE runner, and providing alternative options to run FAKE; use FSI directly or a dedicated build project (please see Different ways to run FAKE) was the option we went on with, especially since the approach to using a dedicated build project is being adopted recently.

If we can support .NET 7 reference assemblies in runner in a way that will not cause side effects, I'm all ok with that. But just I don't wanna go down that rabbit hole again.

[nojaf]

Hello @yazeedobaid, thanks for explaining the problem space.
I'm currently trying to upgrade an open-source project that happens to use FAKE.
So, I would probably go for the easiest option and convert the script to a project. (If the maintainers approve of course)

The best solution would be to use the reference assemblies of the currently used SDK (assuming it is 6 or higher). But that smells like a rabbit hole for sure 😅.

[MortalFlesh]

Hello,
I'm also trying to use net 7 in my project and I constantly get an error:

Unhandled exception. Fake.Core.BuildFailedException: Target 'AssemblyInfo' failed.
 ---> System.AggregateException: One or more errors occurred. (Could not load file or assembly 'Fake.Core.ReleaseNotes, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
)
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'Fake.Core.ReleaseNotes, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

File name: 'Fake.Core.ReleaseNotes, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null'
   at Build.initTargets@72-4.Invoke(TargetParameter _arg5)
   at Fake.Core.TargetModule.runSimpleInternal(TargetContext context, Target target) in D:\a\FAKE\FAKE\src\app\Fake.Core.Target\Target.fs:line 371
   --- End of inner exception stack trace ---
   --- End of inner exception stack trace ---
   at Fake.Core.TargetModule.raiseIfError(OptionalTargetContext context) in D:\a\FAKE\FAKE\src\app\Fake.Core.Target\Target.fs:line 1319
   at Fake.Core.TargetModule.runOrDefaultWithArguments(String defaultTarget) in D:\a\FAKE\FAKE\src\app\Fake.Core.Target\Target.fs:line 1542
   at Build.main(String[] args)

Before this I used build.fsx but as @yazeedobaid mentioned, there are problems - so I'm trying to use build as a project (inspired by https://github.com/TheAngryByrd/MiniScaffold example).

Foo target works as expected (so does the Clean target).

But when there is a Fake package in use in the target (such as AssemblyInfo or ReleaseNotes.. in AssemblyInfo target), it fails.

I've tried multiple ways of declaring dependencies in paket.dependencies (in group, not in group, ..) but the result is always the same.

All the code is in this PR MortalFlesh/console-style#19 (here is the error https://github.com/MortalFlesh/console-style/actions/runs/3583647906/jobs/6029331205)

Locally it behaves the same.

Am I doing something wrong?

[yazeedobaid]

@MortalFlesh I cloned the repository you provided on feature/use-net-7 branch and the project build successfully for me and the tests target ran also successfully, I didn't encounter the missing dependency issue but some tests were failing for another reason.

Could you please remove the storage: none statements from paket.dependencies file and re-restore dependencies again? And after that check packages folder, it should contain a directory called build for Build group in your paket.dependencies which has all the FAKE modules you referenced.

[MortalFlesh]

Well.. I still can't understand, how it worked for you @yazeedobaid :)

I've found a problem and fixed it. Problem was in the Clean target, which removes all bin and obj directories - and it also removed the build/bin and build/obj dir, so the they were missing when next target ran.

So now I can use the build project and I confirm it works on net 7.
Thanks :)

[otto-gebb]

I encountered this issue after upgrading FAKE from 5.23.1 to 6.0.0:

There was a problem while setting up the environment:
-> Could not find a suitable .NET 6 runtime version matching SDK version: 7.0.200

The message confuses me, because I have all the runtimes and SDKs:

❯ dotnet --info                       
.NET SDK:
 Version:   7.0.200
 Commit:    534117727b

Runtime Environment:
 OS Name:     arcolinux
 OS Version:  
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/7.0.200/

Host:
  Version:      7.0.3
  Architecture: x64
  Commit:       0a2bda10e8

.NET SDKs installed:
  3.1.426 [/usr/share/dotnet/sdk]
  6.0.114 [/usr/share/dotnet/sdk]
  7.0.200 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.32 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.14 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.32 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.14 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/share/dotnet]

global.json file:
  Not found

I am using the build.fsx-way of running FAKE in many of my projects and would prefer to keep using it. The only workaround I found is to downgrade FAKE to 5.23.1.

Adding a global.json file fixing the SDK version to v6 like this

{
  "sdk": {
    "version": "6.0.114"
  }
}

also fixes the FAKE script, but it breaks my project, I want to use SDK v7.

Are there any other workarounds?

[yazeedobaid]

During the upgrade of dependencies of FAKE and Paket.Core in FAKE we had to drop support for NETSTANDARD2.0 in FAKE runner and use .NET 6 reference assemblies. We choose .NET 6 since it is the current LTS release. The SDK resolver in FAKE runner look at the global.json file in the project, and setting it to .NET 7 which is not matching what is pinned will result in that error.

The other workaround is to convert the build script to a dedicated build project as explained here.

[otto-gebb]

@yazeedobaid sorry, I don't quite get your explanation for 2 reasons:

1. You say

   "...we had to use .NET 6 reference assemblies"

   but I do have both SDK v6 and runtimme v6 installed, as indicated by dotnet --info. See these parts:

   .NET SDKs installed:
     6.0.114 [/usr/share/dotnet/sdk]
   ...
   .NET runtimes installed:
     Microsoft.AspNetCore.App 6.0.14 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
     Microsoft.NETCore.App 6.0.14 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
   

2. You say

   "The SDK resolver in FAKE runner look at the global.json file in the project..."

   but I dont' have a global.json file. See this part in the output of dotnet --info:

   ...
   global.json file:
     Not found
   

[yazeedobaid]

@otto-gebb so FAKE runner now uses .NET host to get the current version of .NET SDK using dotnet --version as implemented in 2639 PR and 2665 PR. And from that it ensure that resolved version is based on .NET 6, otherwise it will show the message you are having.

In your case, you have .NET 6 and .NET 7 installed on the machine, but .NET host uses the latest SDK version, so it will be .NET 7, hence you get the error message.

However, when you specified a global.json file and set it to 6.0.114 it worked, but as I understand your projects are using .NET 7 already (so it is a downgrade for you).

The resolution algorithm first try to resolve .NET host from environment variables. I can suggest installing .NET host in another directory and install .NET 6 SDK only in that directory and set DOTNET_HOST_PATH environment variable for FAKE runner to pick it up.

I know this is not a convenient way, but allowing runner to use different reference assemblies will be problematic. We tried before to combine .NETSTANDARD 2.0 and .NET 6 and we hit edge cases that resulted in dropping .NETSTANDRD 2.0

Another option I can suggest is to call your scripts directly using FSI instead of FAKE runner. However, if you are using Paket to resolve dependencies you need to tell FSI about Paket, you can do that by passing --compilertool flag to FSI as explained here Passing the folder of the extension as --compilertool flag.

[rcknight]

Just to add a +1 to this issue, we are in the exact same scenario @otto-gebb - building a net7 project, net6 and 7 installed on the build agent.

If I now can't use fake-cli to build a .net7 project this seems a pretty severe limitation of it's usefulness for us.

[otto-gebb]

Tried the compilertool workaround. Unfortunately, it doesn't work for me, I guess because of a bug in Paket (more specifically, in its handling of the groupref instruction).

[otto-gebb]

The workaround using a separate SDK v6 installation works for me.
The commands I used:

curl -s -L -O https://dot.net/v1/dotnet-install.sh
chmod +x ./dotnet-install.sh
./dotnet-install.sh --version "6.0.114" --install-dir "/tmp/dotnet6" \
  --architecture "x64" --os "linux" --no-path
export DOTNET_HOST_PATH=/tmp/dotnet6/dotnet ; fake build