You are not logged in.
Hi, I have tried every solution you can google for. Running dotnet restore returns this:
Restoring /home/name/test/test.csproj:
Determining projects to restore...
/home/name/test/test.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.
ss/usr/share/dotnet/sdk/8.0.106/NuGet.targets(156,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/home/name/test/test.csproj]
/usr/share/dotnet/sdk/8.0.106/NuGet.targets(156,5): error : The HTTP request to 'GET https://api.nuget.org/v3/index.json' has timed out after 100000ms. [/home/name/test/test.csproj]
Restore failed.
I can curl https://api.nuget.org/v3/index.json, it responds without a problem.
I have reinstalled the dotnet stack, this is what I currently have:
$ pacman -Q | rg "dotnet"
dotnet-host 8.0.6.sdk106-1
dotnet-runtime 8.0.6.sdk106-1
dotnet-sdk 8.0.6.sdk106-1
dotnet-targeting-pack 8.0.6.sdk106-1
Any knowers?
Last edited by nchoosek (2024-06-19 19:57:30)
Offline
A DuckDuckGo search for dotnet NU1301 gave https://stackoverflow.com/questions/731 … rce-https# .as first result .
It does look relevant, please check it.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Okay, so running restore with --verbosity detailed gave more info:
Errors: MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.SDK.WorkloadAutoImportPropsLocator" because directory "/usr/share/dotnet/sdk/8.0.302/Sdks/Microsoft.NET.SDK.WorkloadAutoImportPropsLocator/Sdk" did not exist.
and
Errors: MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.SDK.WorkloadManifestTargetsLocator" because directory "/usr/share/dotnet/sdk/8.0.302/Sdks/Microsoft.NET.SDK.WorkloadManifestTargetsLocator/Sdk" did not exist.
The SDK "Microsoft.NET.SDK.WorkloadManifestTargetsLocator" was successfully resolved by the "Microsoft.DotNet.MSBuildWorkloadSdkResolver" resolver to location "/usr/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.android/34.0.43" and version "null".
I tried uninstalling and reinstalling the dotnet runtime/sdk from the official repo, older versions of packages from the official repo archives, as well as the binaries from the AUR. None of these helped. I finally uninstalled everything and installed using the official manual install script from Microsoft, which fixed the issues: https://learn.microsoft.com/en-us/dotne … ed-install.
Offline
Okay, so running restore with --verbosity detailed gave more info:
Errors: MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.SDK.WorkloadAutoImportPropsLocator" because directory "/usr/share/dotnet/sdk/8.0.302/Sdks/Microsoft.NET.SDK.WorkloadAutoImportPropsLocator/Sdk" did not exist.
and
Errors: MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.SDK.WorkloadManifestTargetsLocator" because directory "/usr/share/dotnet/sdk/8.0.302/Sdks/Microsoft.NET.SDK.WorkloadManifestTargetsLocator/Sdk" did not exist. The SDK "Microsoft.NET.SDK.WorkloadManifestTargetsLocator" was successfully resolved by the "Microsoft.DotNet.MSBuildWorkloadSdkResolver" resolver to location "/usr/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.android/34.0.43" and version "null".
I tried uninstalling and reinstalling the dotnet runtime/sdk from the official repo, older versions of packages from the official repo archives, as well as the binaries from the AUR. None of these helped. I finally uninstalled everything and installed using the official manual install script from Microsoft, which fixed the issues: https://learn.microsoft.com/en-us/dotne … ed-install.
Currently I have the same problem. I reinstalled everything with the script of Microsoft but I continue with the same error.
Any help?
Offline
The SO thread indicates this error is caused by network issues .
I suggest you start a new thread and post the full output of dotnet restore --verbosity detailed in it .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline