SdkAssemblyResolver fails to pick up .NET 6.0 #2618

TheAngryByrd · 2021-11-10T15:20:17Z

Description

Testing out 5.21.0-alpha001 I get this error with fake-cli

There was a problem while setting up the environment:
-> DirectoryNotFoundException: Could not find a part of the path '/usr/local/share/dotnet/packs/Microsoft.NETCore.App.Ref/6.0.0-rtm.21522.10/ref/net6.0'.
   StackTrace:
        at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
        at System.IO.Enumeration.FileSystemEnumerator`1.Init()
        at System.IO.Enumeration.FileSystemEnumerator`1..ctor(String directory, Boolean isNormalized, EnumerationOptions options)
        at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
        at System.IO.Enumeration.FileSystemEnumerableFactory.UserFiles(String directory, String expression, EnumerationOptions options)
        at System.IO.Directory.InternalEnumeratePaths(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
        at Fake.Runtime.SdkAssemblyResolver.SdkAssemblyResolver.SdkReferenceAssemblies() in D:\a\FAKE\FAKE\src\app\Fake.Runtime\SdkAssemblyResolver.fs:line 41
        at Fake.Runtime.SdkAssemblyResolver.SdkAssemblyResolver.ResolveSdkReferenceAssemblies(GroupName groupName, Lazy`1 paketDependenciesFile) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\SdkAssemblyResolver.fs:line 142
        at Fake.Runtime.FakeRuntime.retrieveInfosUncached@114(String cacheDir, Lazy`1 paketDependenciesFile, VerboseLevel logLevel, GroupName groupName, SdkAssemblyResolver sdkAssemblyResolver, FrameworkIdentifier framework, Rid rid, Rid ridNotVersionSpecific, Lazy`1 lockFile, Lazy`1 cache, Unit unitVar0) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\FakeRuntime.fs:line 206
        at Fake.Runtime.FakeRuntime.getKnownDependencies@312-1.Invoke(Unit unitVar0) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\FakeRuntime.fs:line 312
        at Fake.Runtime.CoreCache.getCached[a](FSharpFunc`2 getUncached, FSharpFunc`2 readFromCache, FSharpFunc`2 writeToCache, FSharpFunc`2 checkCacheUpToDate) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\CoreCache.fs:line 41
        at Fake.Runtime.FakeRuntime.getKnownDependencies@310(String cacheDir, Lazy`1 paketDependenciesFile, VerboseLevel logLevel, GroupName groupName, FileInfo lockFilePath, String dependencyCacheHashFile, String dependencyCacheFile, SdkAssemblyResolver sdkAssemblyResolver, FrameworkIdentifier framework, Rid rid, Rid ridNotVersionSpecific, Lazy`1 lockFile, Lazy`1 cache, Lazy`1 writeIntellisenseTask, FSharpFunc`2 readFromCache, FSharpFunc`2 writeToCache, Unit unitVar0) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\FakeRuntime.fs:line 311
        at Fake.Runtime.FakeRuntime.knownDependencies@320.Invoke(Unit unitVar) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\FakeRuntime.fs:line 320
        at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
        at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
        at System.Lazy`1.CreateValue()
        at System.Lazy`1.get_Value()
        at Fake.Runtime.FakeRuntime.paketCachingProvider@329-5.Fake.Runtime.CoreCache.ICachingProvider.TryLoadCache(FakeContext context) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\FakeRuntime.fs:line 336
        at Fake.Runtime.CoreCache.prepareContext(FakeConfig config, ICachingProvider cache) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\CoreCache.fs:line 482
        at Fake.Runtime.CoreCache.runScriptWithCacheProviderExt(FakeConfig config, ICachingProvider cache) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\CoreCache.fs:line 508
        at Fake.Runtime.FakeRuntime.runScript(PrepareInfo preparedScript) in D:\a\FAKE\FAKE\src\app\Fake.Runtime\FakeRuntime.fs:line 579
        at Program.runOrBuild(RunArguments args) in D:\a\FAKE\FAKE\src\app\Fake.netcore\Program.fs:line 156

It seems https://github.com/fsprojects/FAKE/blob/release/next/src/app/Fake.Runtime/SdkAssemblyResolver.fs#L41-L42 isn't a reliable way to determine the version, at least on macOS.

For reference this is what is in my folder:

ls /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Ref/
3.1.0 5.0.0 6.0.0

Repro steps

Wanted to report this first. Not sure if this is wider spread or just on macOS as of yet.

Expected behavior

Picks up 6.0.0 sdk

Actual behavior

Picks up 6.0.0-rtm.21522.10 sdk

Known workarounds

unknown

Related information

Operating system : macOS 11.5.2
Branch
.NET Runtime, CoreCLR or Mono Version: net 6.0
Indications of severity
Version of FAKE (4.X, 5.X): 5.21.0-alpha001
(if performance issue) Performance information, links to performance testing scripts

The text was updated successfully, but these errors were encountered:

baronfel · 2021-11-10T16:22:19Z

Correct, the runtime version <> the sdk version. What you should probably do is take the most up-to-date folder there that matches the same major and minor as the runtime version, though. If you want to be 100% accurate, you would have to parse and use the releases.json manifests and map the runtime version you have to the SDKs that shipped that runtime version. MS has a library to do this here

yazeedobaid · 2021-11-11T20:01:11Z

As @baronfel pointed out, the runtime version is not the same as SDK version. This is why we have used RuntimeInformation.FrameworkDescription to determine the matching runtime version. Can you please share the output of dotnet --info please?

@baronfel Do you have a link or a sample for that package? I cannot find any documentation for it

baronfel · 2021-11-11T20:10:19Z

it's public but not entirely documented, the library is essentially a typed wrapper around the contents of the releases.json file, one of which is generated for each major revision of the .NET SDK/Runtime. Also the Releases Index, which points to tons of these.

TheAngryByrd · 2021-11-11T20:31:40Z

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.5
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/sdk/6.0.100/

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

.NET SDKs installed:
  3.1.201 [/usr/local/share/dotnet/sdk]
  3.1.406 [/usr/local/share/dotnet/sdk]
  3.1.407 [/usr/local/share/dotnet/sdk]
  5.0.103 [/usr/local/share/dotnet/sdk]
  5.0.201 [/usr/local/share/dotnet/sdk]
  5.0.202 [/usr/local/share/dotnet/sdk]
  5.0.208 [/usr/local/share/dotnet/sdk]
  5.0.300 [/usr/local/share/dotnet/sdk]
  5.0.402 [/usr/local/share/dotnet/sdk]
  6.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0-preview.3.21201.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

Arshia001 · 2021-11-12T07:07:27Z

I'm also seeing the same error after updating to fake-cli 5.21.0-alpha003. Here's my dotnet --info, in case it helps:

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

.NET SDKs installed:
  5.0.402 [C:\Program Files\dotnet\sdk]
  6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

And here's the framework description I'm getting:

> System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription;;
val it: string = ".NET 6.0.0-rtm.21522.10"

There is discussion around this issue in dotnet/runtime#61394. They say it won't be fixed until 6.0.1.

CumpsD · 2021-11-12T08:00:48Z

Same on windows:

> dotnet tool restore
Tool 'dotnet-ef' (version '6.0.0') was restored. Available commands: dotnet-ef
Tool 'fake-cli' (version '5.21.0-alpha003') was restored. Available commands: fake
Tool 'paket' (version '6.2.1') was restored. Available commands: paket

Restore was successful.
> dotnet paket restore
Paket version 6.2.1+c82f25d6c324024cbd231df154a447a117c2546e
The last restore is still up to date. Nothing left to do.
Total time taken: 0 milliseconds
> dotnet fake build
The last restore is still up to date. Nothing left to do.
Performance:
 - Cli parsing: 202 milliseconds
 - Packages: 68 milliseconds
   - Retrieve Assembly List: 13 milliseconds
 - Script analyzing: 155 milliseconds
 - Runtime: 696 milliseconds
There was a problem while setting up the environment:
-> DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-rtm.21522.10\ref\net6.0'.
Hint: If you just upgraded the fake-runner you can try to remove the .fake directory and try again.

dotnet info:

.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

.NET SDKs installed:
  2.1.818 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  3.1.120 [C:\Program Files\dotnet\sdk]
  3.1.415 [C:\Program Files\dotnet\sdk]
  5.0.203 [C:\Program Files\dotnet\sdk]
  5.0.209 [C:\Program Files\dotnet\sdk]
  5.0.302 [C:\Program Files\dotnet\sdk]
  5.0.303 [C:\Program Files\dotnet\sdk]
  5.0.400 [C:\Program Files\dotnet\sdk]
  5.0.403 [C:\Program Files\dotnet\sdk]
  6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

spingee · 2021-11-14T10:15:58Z

Same problem

yazeedobaid · 2021-11-16T09:36:26Z

I tried to play with RuntimeInformation.FrameworkDescription but could not get any deterministic results, and not sure how it determine the runtime version. I though it was a direct mapping between SDK and runtime, but turns out not. So, I switch to Microsoft.Deployment.DotNet.Releases package as @baronfel suggested, to determine the runtime version matching specific SDK version. The results are predictable and resolve to exact match between SDK and runtime.

Please let me know if you have any feedback or comments about the approach.

Thanks

Arshia001 · 2021-11-16T09:45:13Z

@yazeedobaid Just to be sure, does Microsoft.Deployment.DotNet.Releases fetch data from the internet? If so, does it mean an internet connection will always be required to run fake? I can imagine a few scenarios where running without an internet connection would be very desirable.

yazeedobaid · 2021-11-16T09:55:43Z

@Arshia001 yes it fetches the releases index and releases JSONs.
So can cache the results from these files in .fake directory.

I can imagine a few scenarios where running without an internet connection would be very desirable.
Even on the first run? Since in the first run, you need an internet connection to download dependencies and other stuff. But for subsequent runs, we can cache it in caching provider along with cached dependencies and other stuff.

CumpsD · 2021-11-16T10:08:34Z

Nice progress @yazeedobaid 👍🏻

Arshia001 · 2021-11-16T11:08:38Z

@yazeedobaid there are a few points to consider here, I'll try go over them one by one:

One connection per run of fake will definitely degrade performance for people with slower connections. This problem is solved by caching the file.
Inside docker builds, we're always running for the "first time"; but to be honest, a clean docker build will always need an internet connection to download Nuget packages. One extra connection is unlikely to affect the process, however...
... People (and build machines) behind restrictive firewalls may already have rules in place for Nuget packages. The same cannot be said for whatever URL the releases file is fetched from, so there will be people who are left scratching their heads as to why their builds are suddenly not running. This can not be fixed by caching and will be hard to document for existing users of fake.
If we do cache the results, when will the cached file be updated?
- Will fake try to fetch the file and then use the cached version on failure? This will result in severe degradation of performance (it'll have to wait for the connection to time out) for people developing without a connection, e.g. on a plane. I've done it, and I know others have too.
- Will we never check for updates once it's cached? How will we know about newer SDKs once the file is cached for the first time?
- Any invalidation scenario we come up with will likely be a compromise between the previous two cases.

All in all, I believe this change will likely ruin someone's day. Isn't there anything we could do to use FrameworkDescription reliably? How about a substring match like this:

Directory.GetDirectiories(dotnet6ReferenceAssembliesPath </> "packs" </> "Microsoft.NETCore.App.Ref"
|> Seq.filter (fun dir -> RuntimeInformation.FrameworkDescription.Contains(Path.GetFileName(dir))

I don't know how beta versions of DotNet are named, so I don't know if it'll work.

yazeedobaid · 2021-11-17T09:23:50Z

Thanks, @Arshia001 for raising these points.

For the connection speed, performance, these can be solved by caching the releases file.
For people behind a firewall, I think the best way is to add a descriptive message about the fail in fetching the releases file. Maybe output the response of the web request...
Cache in-validation will happen when users update the specified SDK in their global.json. In that case, if the matching runtime version is not in the cached releases file, then we can fail with a message to let users delete the cached file, or make FAKE itself delete it and re-fetch it. This is the only case I'm thinking of that will result in an invalid cache. Since cache will be invalid when upgrading to a newer SDK version.

Using FrameworkDescription is not reliable, we cannot predict what we will get (please correct me if I'm wrong on this point). I tried it with multiple versions and didn't know how it determine the runtime version. Your proposed way will mix and match between SDK and runtime versions, not sure what are the effects of this and we went with using releases to avoid this point.

Currently, I have these two approaches - if anyone has other ideas, please let us know:

Improve the releases-index solution by adding caching and descriptive messages for edge cases.
Crowl the folder we use for getting runtime versions and match with fixing major and minor parts of the resolved SDK version. And take the most recent patch version we can find. If we cannot find it, we can roll forward for a minor version and see if we can find any. This approach is described here and was proposed by @baronfel above.

If anyone has any other options/suggestions please let us know.
Thanks

CumpsD · 2021-11-23T08:16:20Z

Any progress on getting this released so people's builds work again? :)

Arshia001 · 2021-12-08T10:32:10Z

Any news of this being resolved any time soon?

baronfel · 2021-12-13T15:45:20Z

A potential resolution to the question of runtime resolution that might strike a good-enough balance is to download and cache the runtime lists as a build task in this repo, so that there's a fallback for situations where network connectivity cannot be guaranteed. This local copy would need to be updated on a periodic basis, but FAKE has a good release pipeline, and that should be a low-overhead activity. Say something on the order of a monthly or every-other-month release cadence would be good enough to ensure decent coverage of updates to this file.

CumpsD · 2021-12-18T16:57:00Z

@dsyme any chance to get this moving somehow? it's hard to convince people to keep on using FAKE if it doesn't support .NET 6, some of the projects are moving away from it so they can continue working

Arshia001 · 2021-12-20T04:52:24Z

@CumpsD others, like us, are stuck on .NET 5.

baronfel · 2021-12-21T14:26:14Z

For those who are stuck on upgrades, consider using a standalone console application with the FAKE library APIs instead of the runner. An example of this can be seen here: https://github.com/TheAngryByrd/MiniScaffold/tree/master/Content/Library/build

SamuelBerger · 2021-12-27T16:20:19Z

Or you can just run your fake scripts with fsi. Example:
https://twitter.com/eiriktsarpalis/status/1459189000082710529

CumpsD · 2021-12-27T17:14:51Z

For those who are stuck on upgrades, consider using a standalone console application with the FAKE library APIs instead of the runner. An example of this can be seen here: TheAngryByrd/MiniScaffold@master/Content/Library/build

Thanks, I went with this solution and can build again :)

dsyme · 2022-01-05T16:02:38Z

@yazeedobaid What's status on this please, thank you

yazeedobaid · 2022-01-06T09:12:36Z

@dsyme I didn't get the chance to continue working on it in the last couple of weeks
will try to continue on it

Thanks

yazeedobaid · 2022-01-06T10:54:22Z

I have merged the PR and published a new alpha release 5.21.0-alpha004
Will keep this issue open until we address the points/concerns raised in the discussion

Thanks

yazeedobaid · 2022-01-07T18:47:46Z

I have opened a new PR that addresses the possibility that accessing the network is not an option to resolve the runtime version for the selected SDK. The PR implements a fallback method to use a cached file that is created as a step in FAKE's build script.

feedback is highly appreciated on the PR

Thanks

yazeedobaid · 2022-01-24T17:02:56Z

The fix for this issue is included in release 5.21.0

Thanks

Arshia001 · 2022-07-02T13:36:40Z

@yazeedobaid It's been a while, but I'm getting an error that seems related to this issue.

I have .NET SDK versions 6.0.201 and 6.0.203 installed on a computer. This corresponds to runtime versions 6.0.3 and 6.0.5 respectively as per https://dotnet.microsoft.com/en-us/download/dotnet/6.0. However, the FAKE runner tries to access reference assemblies for version 6.0.2, which it cannot find and fails.

Here's some output:

dotnet fake build
The last restore is still up to date. Nothing left to do.
...
There was a problem while setting up the environment:
-> Could not find referenced assemblies in path: 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.2\ref\net6.0', please check installed SDK and runtime versions

dotnet --list-sdks
3.1.419 [C:\Program Files\dotnet\sdk]
6.0.201 [C:\Program Files\dotnet\sdk]
6.0.203 [C:\Program Files\dotnet\sdk]

dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

yazeedobaid · 2022-07-15T17:43:11Z

A new alpha release of the FAKE runner has been published now. Please test with that since we had a PR that fix the SDK runtime resolution logic.

Arshia001 mentioned this issue Nov 14, 2021

Fix retrieval of SDK version on .NET 6.0.0 #2624

Closed

yazeedobaid mentioned this issue Nov 15, 2021

Fix sdk resolver for net6 assemblies. Using offical .NET release JSON to get runtime version #2625

Merged

7 tasks

baronfel mentioned this issue Jan 1, 2022

Build on .NET 6 fsprojects/FSharp.Data#1422

Closed

yazeedobaid closed this as completed in #2625 Jan 6, 2022

yazeedobaid reopened this Jan 6, 2022

yazeedobaid mentioned this issue Jan 7, 2022

Add an option to resolve SDK runtime version from a cache file #2630

Merged

7 tasks

yazeedobaid closed this as completed in #2630 Jan 19, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SdkAssemblyResolver fails to pick up .NET 6.0 #2618

SdkAssemblyResolver fails to pick up .NET 6.0 #2618

TheAngryByrd commented Nov 10, 2021 •

edited

Loading

baronfel commented Nov 10, 2021

yazeedobaid commented Nov 11, 2021

baronfel commented Nov 11, 2021

TheAngryByrd commented Nov 11, 2021

Arshia001 commented Nov 12, 2021 •

edited

Loading

CumpsD commented Nov 12, 2021 •

edited

Loading

spingee commented Nov 14, 2021

yazeedobaid commented Nov 16, 2021

Arshia001 commented Nov 16, 2021

yazeedobaid commented Nov 16, 2021

CumpsD commented Nov 16, 2021

Arshia001 commented Nov 16, 2021

yazeedobaid commented Nov 17, 2021

CumpsD commented Nov 23, 2021

Arshia001 commented Dec 8, 2021

baronfel commented Dec 13, 2021

CumpsD commented Dec 18, 2021

Arshia001 commented Dec 20, 2021

baronfel commented Dec 21, 2021

SamuelBerger commented Dec 27, 2021

CumpsD commented Dec 27, 2021

dsyme commented Jan 5, 2022 •

edited

Loading

yazeedobaid commented Jan 6, 2022

yazeedobaid commented Jan 6, 2022

yazeedobaid commented Jan 7, 2022

yazeedobaid commented Jan 24, 2022

Arshia001 commented Jul 2, 2022

yazeedobaid commented Jul 15, 2022

SdkAssemblyResolver fails to pick up .NET 6.0 #2618

SdkAssemblyResolver fails to pick up .NET 6.0 #2618

Comments

TheAngryByrd commented Nov 10, 2021 • edited Loading

Description

Repro steps

Expected behavior

Actual behavior

Known workarounds

Related information

baronfel commented Nov 10, 2021

yazeedobaid commented Nov 11, 2021

baronfel commented Nov 11, 2021

TheAngryByrd commented Nov 11, 2021

Arshia001 commented Nov 12, 2021 • edited Loading

CumpsD commented Nov 12, 2021 • edited Loading

spingee commented Nov 14, 2021

yazeedobaid commented Nov 16, 2021

Arshia001 commented Nov 16, 2021

yazeedobaid commented Nov 16, 2021

CumpsD commented Nov 16, 2021

Arshia001 commented Nov 16, 2021

yazeedobaid commented Nov 17, 2021

CumpsD commented Nov 23, 2021

Arshia001 commented Dec 8, 2021

baronfel commented Dec 13, 2021

CumpsD commented Dec 18, 2021

Arshia001 commented Dec 20, 2021

baronfel commented Dec 21, 2021

SamuelBerger commented Dec 27, 2021

CumpsD commented Dec 27, 2021

dsyme commented Jan 5, 2022 • edited Loading

yazeedobaid commented Jan 6, 2022

yazeedobaid commented Jan 6, 2022

yazeedobaid commented Jan 7, 2022

yazeedobaid commented Jan 24, 2022

Arshia001 commented Jul 2, 2022

yazeedobaid commented Jul 15, 2022

TheAngryByrd commented Nov 10, 2021 •

edited

Loading

Arshia001 commented Nov 12, 2021 •

edited

Loading

CumpsD commented Nov 12, 2021 •

edited

Loading

dsyme commented Jan 5, 2022 •

edited

Loading