Open snailcatcher opened 11 months ago
I first saw this issue when my pipeline started failing when running dotnet pack. I realized that my agents started using the .NET 8 SDK to compile my solution (Microsoft rolled out the update). I solved the problem by adding the UseDotNet@2 task to my pipeline (to enforce the correct SDK), having in mind that this could be a potential issue once my team focus in upgrading our solutions to .NET 8.
This week we decided to start the migration and the issue was indeed there. This soon became a blocker for us and therefore we decided to revert the migration. After some investigation, I found the following issue on Stack Overflow: https://stackoverflow.com/questions/77521838/devops-pipeline-suddenly-failing-to-access-artifacts-nuget-feed-unauthorised - which a Microsoft employee (?) was able to reproduce the issue.
C:\hostedtoolcache\windows\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [D:\a\1\s\code\SolutionName\ProjectName.csproj]
Assembly loaded during TaskRun (NuGet.Build.Tasks.RestoreTask): System.Diagnostics.StackTrace, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (location: C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App\8.0.0\System.Diagnostics.StackTrace.dll, MVID: 25edb9e8-3a07-4dc6-9c63-0c3ee33029e5, AppDomain: [Default])
NuGet.Protocol.Core.Types.FatalProtocolException: Unable to load the service index for source https://{ORG}.pkgs.visualstudio.com/_packaging/{FEED}/nuget/v3/index.json.
---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at NuGet.Protocol.HttpSource.<>c__DisplayClass15_0`1.<<GetAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync[T](String filePath, Func`2 action, CancellationToken token)
at NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync[T](String filePath, Func`2 action, CancellationToken token)
at NuGet.Protocol.HttpSource.GetAsync[T](HttpSourceCachedRequest request, Func`2 processAsync, ILogger log, CancellationToken token)
at NuGet.Protocol.ServiceIndexResourceV3Provider.GetServiceIndexResourceV3(SourceRepository source, DateTime utcNow, ILogger log, CancellationToken token)
--- End of inner exception stack trace ---
at NuGet.Protocol.ServiceIndexResourceV3Provider.GetServiceIndexResourceV3(SourceRepository source, DateTime utcNow, ILogger log, CancellationToken token)
at NuGet.Protocol.ServiceIndexResourceV3Provider.TryCreate(SourceRepository source, CancellationToken token)
at NuGet.Protocol.Core.Types.SourceRepository.GetResourceAsync[T](CancellationToken token)
at NuGet.Protocol.Providers.VulnerabilityInfoResourceV3Provider.TryCreate(SourceRepository source, CancellationToken token)
at NuGet.Protocol.Core.Types.SourceRepository.GetResourceAsync[T](CancellationToken token)
at NuGet.Commands.VulnerabilityInformationProvider.GetVulnerabilityInfoAsync()
at NuGet.Commands.VulnerabilityInformationProvider.GetVulnerabilityInformationAsync(CancellationToken cancellationToken)
at NuGet.Commands.Restore.Utility.AuditUtility.GetAllVulnerabilityDataAsync(CancellationToken cancellationToken)
at NuGet.Commands.Restore.Utility.AuditUtility.CheckPackageVulnerabilitiesAsync(CancellationToken cancellationToken)
at NuGet.Commands.RestoreCommand.PerformAuditAsync(EnabledValue enableAudit, IEnumerable`1 graphs, TelemetryActivity telemetry, CancellationToken token)
at NuGet.Commands.RestoreCommand.ExecuteAsync(CancellationToken token)
at NuGet.Commands.RestoreRunner.ExecuteAsync(RestoreSummaryRequest summaryRequest, CancellationToken token)
at NuGet.Commands.RestoreRunner.ExecuteAndCommitAsync(RestoreSummaryRequest summaryRequest, IRestoreProgressReporter progressReporter, CancellationToken token)
at NuGet.Commands.RestoreRunner.CompleteTaskAsync(List`1 restoreTasks)
at NuGet.Commands.RestoreRunner.RunAsync(IEnumerable`1 restoreRequests, RestoreArgs restoreArgs, CancellationToken token)
at NuGet.Commands.RestoreRunner.RunAsync(RestoreArgs restoreContext, CancellationToken token)
at NuGet.Build.Tasks.BuildTasksUtility.RestoreAsync(DependencyGraphSpec dependencyGraphSpec, Boolean interactive, Boolean recursive, Boolean noCache, Boolean ignoreFailedSources, Boolean disableParallel, Boolean force, Boolean forceEvaluate, Boolean hideWarningsAndErrors, Boolean restorePC, Boolean cleanupAssetsForUnsupportedProjects, ILogger log, CancellationToken cancellationToken)
at NuGet.Build.Tasks.RestoreTask.ExecuteAsync(ILogger log)
Done executing task "RestoreTask" -- FAILED.
1>Done building target "Restore" in project "ProjectName.csproj" -- FAILED.
1>Done Building Project "D:\a\1\s\code\SolutionName\ProjectName.csproj" (Restore target(s)) -- FAILED.
Build FAILED.
"D:\a\1\s\code\SolutionName\ProjectName.csproj" (Restore target) (1) ->
(Restore target) ->
C:\hostedtoolcache\windows\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Unable to load the service index for source https://{ORG}.pkgs.visualstudio.com/_packaging/{FEED}/nuget/v3/index.json. [D:\a\1\s\code\SolutionName\ProjectName.csproj]
C:\hostedtoolcache\windows\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [D:\a\1\s\code\SolutionName\ProjectName.csproj]
Other GitHub issue that is related to this problem: https://github.com/microsoft/azure-pipelines-agent/issues/4556
An update about this issue.
After spending the weekend without writing any code (neither opening the Visual Studio), I'm currently facing this issue on my local machine.
PS C:\Repositories\{RepositoryName}\code\{ProjectDirectory}> dotnet pack --output "C:\NuGet" --include-symbols /p:PackageVersion=3.$(Get-Date -Format yy.MMddHHmm)-local
MSBuild version 17.8.3+195e7f5a3 for .NET
Determining projects to restore...
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Unable to load the service index for source https://{ORG}.pkgs.visualstudio.com/_packaging/{FEED}/nuget/v3/index.json. [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
PS C:\Repositories\{RepositoryName}\code\{ProjectDirectory}> dotnet build
MSBuild version 17.8.3+195e7f5a3 for .NET
Determining projects to restore...
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Unable to load the service index for source https://{ORG}.pkgs.visualstudio.com/_packaging/{FEED}/nuget/v3/index.json. [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
Build FAILED.
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Unable to load the service index for source https://{ORG}.pkgs.visualstudio.com/_packaging/{FEED}/nuget/v3/index.json. [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:07.27
PS C:\Repositories\{RepositoryName}\code\{ProjectDirectory}> dotnet restore
Determining projects to restore...
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Unable to load the service index for source https://{ORG}.pkgs.visualstudio.com/_packaging/{FEED}/nuget/v3/index.json. [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
C:\Program Files\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Repositories\{RepositoryName}\code\{ProjectDirectory}\{ProjectDirectory}.csproj]
I don't know if it's related with the way credentials are being refreshed, but I think this is good input. I've also found a post on Stack Overflow from another user potentially facing the same issue.
I feel like a breaking change was introduced with .NET 8. I couldn't find anything on the Breaking Changes in .NET 8 post, so I believe this was introduced unintentionally.
Edit: The only way I managed to be able to pack my nuget was by building the project through Visual Studio with the configuration set to Release (as dotnet pack runs with Release configuration by default since .NET 8).
After a nightmare couple of days dealing with this exact issue, I feel like this is going to hit a lot of people real quick, unless we're missing something?
We experienced this issue after .net 8 SDK was downloaded onto our two Hosted Agents. Took me a while to figure out what was going on. We had a new API that was being built in .net 8, and a new pipeline had been setup for it targeting .net 8 SDK. This is what prompted our two hosted agents to download the 8.0.100 SDK.
What happened afterwards was that nearly all our existing .net 6 API build pipelines started failing at the build step.
Each pipeline has a restore step, that is configured to use our Azure Artifacts nuget feed. This step continued to work, however the build started failing due to the same issues above.
2023-12-11T14:19:24.3063665Z d:\vsts-agent\_work\_tool\dotnet\sdk\8.0.100\NuGet.targets(156,5): warning : The plugin credential provider could not acquire credentials. Authentication may require manual action. Consider re-running the command with --interactive for `dotnet`, /p:NuGetInteractive="true" for MSBuild or removing the -NonInteractive switch for `NuGet` [d:\vsts-agent\_work\101\s\{solution}\{project}.csproj]
2023-12-11T14:19:24.3068111Z d:\vsts-agent\_work\_tool\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/{private_feed}/nuget/v3/index.json. [d:\vsts-agent\_work\101\s\{solution}\{project}.csproj]
2023-12-11T14:19:24.3069474Z d:\vsts-agent\_work\_tool\dotnet\sdk\8.0.100\NuGet.targets(156,5): error : Response status code does not indicate success: 401 (Unauthorized). [d:\vsts-agent\_work\101\s\{solution}\{project}.csproj]
2023-12-11T14:19:24.3076135Z 1 Warning(s)
2023-12-11T14:19:24.3079990Z 1 Error(s)
2023-12-11T14:19:24.3085983Z
Just to note the MS Build version was now the same as the above posters logs:
MSBuild version 17.8.3+195e7f5a3 for .NET
I went down the rabbit hole for an afternoon, first assuming permissions had changed, then assuming I needed to append the --no-restore
argument, but to get the build to run I needed to add this to the build, test and publish steps. We have 30+ pipelines.
In the end we've rolled back the new API to .Net 6 and I've manually reset our two hosted agents so neither have the .net 8 SDK available. All pipelines are back to running correctly now.
The kicker is, one of the pipelines has the step to select .net 6 SDK explicitly as below, but the agent still used the .net 8 SDK. Is that a bug too?
I wonder if it is related to the problem of ignore-failed-source
flag
@JL03-Yue if you mean that the flag itself cause the issue, than this is not the case. I tested it out for you:
If I ran the command without ignore-failed-source
dotnet tool update -g {APP_NAME} --add-source https://pkgs.dev.azure.com/{ORG}/{PROJECT}/_packaging/{FEED}/nuget/v3/index.json --interactive -v d
I get the same results:
[NuGet Manager] [Info] GET https://api.nuget.org/v3/registration5-gz-semver2/{APP_NAME}/index.json
[NuGet Manager] [Info] NotFound https://api.nuget.org/v3/registration5-gz-semver2/{APP_NAME}/index.json 146ms
[NuGet Manager] [Info] GET https://pkgs.dev.azure.com/{ORG}/9ad93b27-4725-467b-9dd8-9cce5dd5626a/_packaging/bbb0bf08-62ab-44b1-b204-06f36739e161/nuget/v3/registrations2-semver2/{APP_NAME}/index.json
[NuGet Manager] [Info] OK https://pkgs.dev.azure.com/{ORG}/9ad93b27-4725-467b-9dd8-9cce5dd5626a/_packaging/bbb0bf08-62ab-44b1-b204-06f36739e161/nuget/v3/registrations2-semver2/{APP_NAME}/index.json 399ms
[NuGet Manager] [Info] GET https://pkgs.dev.azure.com/{ORG}/9ad93b27-4725-467b-9dd8-9cce5dd5626a/_packaging/bbb0bf08-62ab-44b1-b204-06f36739e161/nuget/v3/registrations2-semver2/{APP_NAME}/index.json
[NuGet Manager] [Warning] The plugin credential provider could not acquire credentials. Authentication may require manual action. Consider re-running the command with --interactive for `dotnet`, /p:NuGetInteractive="true" for MSBuild or removing the -NonInteractive switch for `NuGet`
[NuGet Manager] [Info] Unauthorized https://pkgs.dev.azure.com/{ORG}/9ad93b27-4725-467b-9dd8-9cce5dd5626a/_packaging/bbb0bf08-62ab-44b1-b204-06f36739e161/nuget/v3/registrations2-semver2/{APP_NAME}/index.json 222ms
Unhandled exception: System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at NuGet.Protocol.HttpSource.<>c__DisplayClass15_0`1.<<GetAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync[T](String filePath, Func`2 action, CancellationToken token)
at NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync[T](String filePath, Func`2 action, CancellationToken token)
at NuGet.Protocol.HttpSource.GetAsync[T](HttpSourceCachedRequest request, Func`2 processAsync, ILogger log, CancellationToken token)
at NuGet.Protocol.PackageMetadataResourceV3.LoadRegistrationIndexAsync(HttpSource httpSource, Uri registrationUri, String packageId, SourceCacheContext cacheContext, Func`2 processAsync, ILogger log, CancellationToken token)
at NuGet.Protocol.PackageMetadataResourceV3.GetMetadataAsync(String packageId, Boolean includePrerelease, Boolean includeUnlisted, VersionRange range, SourceCacheContext sourceCacheContext, ILogger log, CancellationToken token)
at NuGet.Protocol.PackageMetadataResourceV3.GetMetadataAsync(String packageId, Boolean includePrerelease, Boolean includeUnlisted, SourceCacheContext sourceCacheContext, ILogger log, CancellationToken token)
at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetPackageMetadataAsync(PackageSource source, String packageIdentifier, Boolean includePrerelease, Boolean includeUnlisted, CancellationToken cancellationToken)
at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetMatchingVersionInternalAsync(String packageIdentifier, IEnumerable`1 packageSources, VersionRange versionRange, CancellationToken cancellationToken)
at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetBestPackageVersionAsync(PackageId packageId, VersionRange versionRange, PackageSourceLocation packageSourceLocation)
at Microsoft.DotNet.Cli.ToolPackage.ToolPackageDownloader.<>c__DisplayClass8_0.<InstallPackage>b__0()
at Microsoft.DotNet.Cli.TransactionalAction.Run[T](Func`1 action, Action commit, Action rollback)
at Microsoft.DotNet.Tools.Tool.Update.ToolUpdateGlobalOrToolPathCommand.<>c__DisplayClass14_0.<Execute>b__1()
at Microsoft.DotNet.Tools.Tool.Update.ToolUpdateGlobalOrToolPathCommand.RunWithHandlingInstallError(Action installAction)
at Microsoft.DotNet.Tools.Tool.Update.ToolUpdateGlobalOrToolPathCommand.Execute()
at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
At least for dotnet tool restore
as a workaround you can:
global.json
to .NET 7dotnet tool restore -v n --interactive --no-cache
and authenticate when the option is providedglobal.json
dotnet tool restore
which should now complete successfullyDon't know if it would work for dotnet tool update
.
This is preventing us from committing to utilising .net 8 at the moment due to the impact on all our build pipelines.
Has there been no response at all from Microsoft? Feel like this is pretty big.
Thank you for the report. This is indeed very important and will look into it.
I talked with some of my colleagues about this. And I noticed something which may be helpful for looking into this problem.
I noticed this "bug" when using a own custom cli tool on my MacOS machine and our Ubuntu Agents in our pipelines (and when dealing with NuGet packages on my Mac). My colleagues which use Windows machines seem not to have seen this behavior. So maybe it is an issue either with the dotnet runtime for this specific OSs or it has something to do with the architecture of the underling machine. (My Mac and the Linux machines are mostly arm64, the Windows machines are x64)
Maybe this will help and thank you for the investigations.
We get this on Windows Hosted Agents (windows-2022 & windows-latest):
https://github.com/microsoft/azure-pipelines-agent/issues/4556
I've also had it on my local Windows 11 development box in certain circumstances. One thing I've noticed it that it seems to happen frequently if you do the NuGet restore in the dotnet build
(i.e. don't specify --no-restore
and include a separate dotnet restore
step). I haven't looked into it, but I've also seen the same thing in BenchmarkDotNet runs (in .NET 8.0)
We are also experiencing this issue and we were able to 'resolve' this using a PAT from in our nuget config, but we need to change all our pipelines accordingly because we dont want to expose the PAT in our nuget.configs
I am experiencing this 401 (Unauthorized)
error on Azure DevOps Server 2020 (on-prem), after updating Visual Studio Build Tools 2022 from v17.7.x to v17.8.3.
We use self-hosted agents on Windows Server 2019 and Windows Server 2022. Some agents are running as Network Service
(built-in Windows user), and some agents as an Active Directory user.
Previously all commands (dotnet build/pack/publish/test) were running fine on Network Service
agents but after updating to Visual Studio Build Tools 2022 v17.8.3 (which includes .NET 8 SDK), all fails with 401 (Unauthorized)
.
Workaround nr. 1:
As mentioned above, you should run build/publish/test with --no-restore
argument. In this case you have to add a dotnet restore
task before build/publish/test.
Workaround nr. 2: If you are running your pipelines on a self-hosted agent, and that agent is not running as an AD user, you should add a new agent to the pool with AD user, or change the associated user to an AD user in service settings.
We're seeing the same, but intestingly we don't have the problem with any client that uses credential helpers (including Azure Pipelines - they work fine). Only tasks that use a static PAT consistently fail with dotnet 8.0.101 and work fine with dotnet 6. In our case this broke renovate and there doesn't seem to be a workaround (yet).
With dotnet 8.0.201 this problem seems to be fixed. On my my M1 Mac at least. It would be nice if the other reporters can confirm this.
I'll test that as soon as the dpkgs get released on the Debian feed... currently latest from the official microsoft production feed is .200
Just hit this issue today after install of .NET 8 on self-hosted Windows build host. I did install 8.0.201, so I don't think that is a fix. DevOps agent runs as NetworkService, and has never had issue with accessing artifact feed in the past on lower versions of .NET SDK.
Index and 401 issues happened for me using an existing script during 2 of 3 steps; which I run via Developer Powershell or Package Manager Console. Part 1 > dotnet pack Part 2 > dotnet nuget push [to Local Feed Directory] Part 3 > dotnet tool update My solutions nuget.config includes Local Feed, Private Feed, and Nuget.
Starting setup including NET 8.0.1 (via Visual Studio) with credential provider some time ago. Part 1 and 3 failed with 401 accessing the index on my private feed.
Re-auth was required in Visual Studio. That alone was not enough. Rebuild Solution was run twice (first run gives error). At this point the error during Part 1 is gone.
Updated Visual Studio to 17.9.1 w/ NET 8.0.2 and re-trusted the DevCert. This did not fix Part 3.
Instead of installing NET 8.0.201, I decided to run the credential provider install script (used iex method w/ netfx) again. This worked. All parts of my script are running.
(Guessing/wondering if the vs update and NET 8.0.2 we even needed)
SDK 8.0.200 still fails non-deterministically on donet restore
Linux on a CI machine (some build works, next one fails: no clear pattern, same sources).
Starting: .NET SDK 8.0.200 /usr/share/dotnet/dotnet restore /var/teamcity-agent/work/66a8be3456c8d312/Acme.sln --source https://api.nuget.org/v3/index.json --source https://pkgs.dev.azure.com/acme/nuget/v3/index.json
Determining projects to restore...
/usr/share/dotnet/sdk/8.0.200/NuGet.targets(169,5): warning : The plugin credential provider could not acquire credentials. Authentication may require manual action. Consider re-running the command with --interactive for `dotnet`, /p:NuGetInteractive="true" for MSBuild or removing the -NonInteractive switch for `NuGet`
Response status code does not indicate success: 401 (Unauthorized).
Is there a fix scheduled for this?
So we're tracking 3 issues including this one all making us think .net 8 is not worth it right now. The effort needed to avoid having to update 50+ azure pipelines is ridiculous, I cannot understand how more people are not suffering these issues. I can only think many businesses are just opting not to do it right now.
Only one issue resolved but we have to wait for EF 9 to be released to fix it. Madness.
https://github.com/dotnet/efcore/issues/25555 https://github.com/microsoft/azure-pipelines-tasks/issues/17196
I really don't have much faith myself currently. Myself and my colleague are just both done with it at the moment. Other than LTS, we cannot see why upgrading is a worth while path us, we've wasted days trying to overcome all these issues. Exhausted.
we had the similar issue.
Have similar issue on Rider, mac M1, intermittently fails my builds and is causing annoyance working with the IDE, but with dotnet 6 there were no issues in Rider, only now with switching things to dotnet 8, SDK 8.0.204. Making it very hard to work with azure devops private feeds and Rider. but seems the fault is not on Rider but something with dotnet, and don't know if it is unix/linux/mac related only.
I am authenticated to private feed via PAT specified in Nuget.Config on user folder level.
Determining projects to restore... 6>NuGet.targets(169,5): Error : Unable to load the service index for source https://pkgs.dev.azure.com/xxx/xxx/_packaging/xxx/nuget/v3/index.json. Response status code does not indicate success: 401 (Unauthorized). 6>------- Finished building project:
We've found that adding the new(ish) NuGetAuthenticate task to pipeline just before the restore has resolved the issue for us on all of our use cases (Windows, Mac, Ubuntu).
Describe the bug
Try to install a package from a private registry (maybe also non-private, don't know). Install fails with HTTP 401.
fails with:
But only with dotnet sdk 8.0.100, everything works fine with dotnet sdk 7.0.400
To Reproduce
see the stuff above
Exceptions (if any)
see the stuff above
Further technical details
dotnet --info
:Runtime Environment: OS Name: Mac OS X OS Version: 14.1 OS Platform: Darwin RID: osx-arm64 Base Path: /usr/local/share/dotnet/sdk/8.0.100/
.NET workloads installed: Workload version: 8.0.100-manifests.6c33ef20 There are no installed workloads to display.
Host: Version: 8.0.0 Architecture: arm64 Commit: 5535e31a71
.NET SDKs installed: 7.0.404 [/usr/local/share/dotnet/sdk] 8.0.100 [/usr/local/share/dotnet/sdk]
.NET runtimes installed: Microsoft.AspNetCore.App 7.0.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 7.0.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found: x64 [/usr/local/share/dotnet/x64] registered at [/etc/dotnet/install_location_x64]
Environment variables: Not set
global.json file: Not found
Learn more: https://aka.ms/dotnet/info
Download .NET: https://aka.ms/dotnet/download
Error happens when using dotnet cli