RockNHawk
commented
5 years ago export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0
dotnet restore
this worked for me
Open livarcocc opened 7 years ago
RockNHawk
commented
5 years ago export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0
dotnet restore
this worked for me
vmpatel
commented
5 years ago Upgrading dot net package from 2.08 to 2.09 resolved this issue.
Can you please share your docker file to compare and what .net package version Microsoft.AspNetCore.All and Microsoft.NETCore.App ?
Umc34
commented
5 years ago try to run
docker buildwith--network=host
thanks. 3 hours missed with my fault.. if no network, no restore...
marxxxx
commented
5 years ago Restarting docker on my windows system resolved it for me.
This was solving the issue for me as well. Also docker login to ACR is now working.
RockNHawk
commented
5 years ago If in Linux, I was able to get restore working on my Solus box by first running
export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0. Once I did that, dotnet restore worked.
export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0
dotnet restore
WernerMairl
commented
5 years ago Same symtoms here, building a AspNetCore 2.2 App with docker.
Restarting Docker (Version 2.0.0.3 (31259) helps for me (like for a few other problems with docker after machine restart - outside from aspnetcore).... => problem caused by docker not by dotnet/nuget etc!
BUT: reading this issue here was really helpful!
engmsaleh
commented
5 years ago Restart didn't work for me, I'm using osx 10.14.5 :(
hubert-associates
commented
5 years ago Sad but true: nobody seems to be able to figure this show-stopper out. It has caused us to currently drop the entire windows-stack-container-approach and move to iot-edge on linux containers just so we can make some progress. We have tried all the "tricks" mentioned above. none of them work in our case, so not the root cause. Where I draw the line though is attempting to de-install and re-install things at random to see if a "shot in the dark" fixes it. I'm still suspecting Docker on windows but no proof. We are using the newest iot-edge Docker-Windows.
brennon
commented
5 years ago I had the same issue that multiple others had. Trying a nuget restore in a Docker image build. For whatever reason, while I could resolve api.nuget.org in a shell on a container from that image, it wasn't working when building the image. Adding this to the script launched from my Dockerfile did the trick:
echo 152.199.4.33 api.nuget.org >> C:\Windows\System32\drivers\etc\hosts
brmatola
commented
5 years ago I had a similar problem, and fixed it by adding "dns": ["8.8.8.8"] to the daemon.json. When I used a shell from a running container, I could ping IP addresses, but couldn't resolve dns names. For example, ping 8.8.8.8" would work just fine, but ping google.com would fail. I couldn't resolve hostnames, so couldn't find api.nuget.org to restore nuget packages.
On further exploration, Resolve-DnsName google.com would fail while Resolve-DnsName google.com -Server 8.8.8.8 would succeed. For whatever reason, the container did not have a default DNS server configured. An ipconfig /all confirmed that no DNS server was known by the container.
To fix this, I added "dns": ["8.8.8.8"] to the daemon configuration file to force the daemon to add a DNS server. The documentation says that if no DNS server is specified, 8.8.8.8 will be added by default, but in my case that did not appear to be happening. Hopefully, someone can get to the bottom of why this is the problem or whether the problem is something more general.
hamburgerwang
commented
4 years ago I encountered this error when build my project with a library in NuGet. Setting the proxy in terminal works for me. set http_proxy=my.proxy.com:80 set https_proxy=my.proxy.com:80
shiro997
commented
4 years ago I added the source address of my NuGet packages in the nuget.config file of my project and I still get the error "Unable to load the service index for source http: // myServer: 8080 / tfs / TPC__MyProject / _packaging / MyNuget / nuget /v3/index.json ", what do you recommend me to do in this case? The package sources section looks like this:
pushist1y
commented
4 years ago I had a similar problem, and fixed it by adding
"dns": ["8.8.8.8"]to the daemon.json
This is what fixed that for me. I was testing my network from container by pinging 8.8.8.8 and was totally sure that it's ok. But as i saw this and tried to ping google.com - it wasn't resolved.
webcoyote
commented
4 years ago I was able to fix this problem by removing the .nuget directory from my %USERPROFILE% (AKA $HOME) directory, as mentioned here: https://github.com/NuGet/Home/issues/2880#issuecomment-332247920
tavisca-cchowdhary
commented
4 years ago If you are having this error in a docker container then run
Then stop the docker app in your machine. Restart your machine and running everything from start.
psgivens
commented
4 years ago * docker system prune --volumes.
This worked for me, but seems a bit heavy handed. Before executing it gives this warning:
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all volumes not used by at least one container
- all dangling images
- all dangling build cache
This smells like a cache problem. Is nuget using a cache that I can clear? Could we use this:
dotnet nuget locals --clear all
I fixed it before using the prune solution. Then it broke again. Then I used the prune solution to fix it again. Now I have to wait until I run into it again before attempting the --clear all solution.
tavisca-cchowdhary
commented
4 years ago I tried using the
Yes even I think that this is a cache problem.
psgivens
commented
4 years ago I ran into the same problem this morning, and here is a new datapoint. I was able to fix the problem by removing and creating my network.
docker network rm <my network name>
docker network create <my network name>I cannot imagine why this worked, but it was one of the things that is removed during the system purge. I'll report back wheather this is a consistent fix, or if I figure out why it worked.
The above solution worked when launching from docker directly, but then when I try to do docker-compose up, I get this:
ERROR: for basicservice_pomodoro-pgsql_1 Cannot start service pomodoro-pgsql: network 108e8267563fc4bb2ee6af201c0d3e2b95d4717a7d5cb3c9b5620ee751fc3fcc not foundSomething in the docker-compose ecosystem may be causing the caching problem even when launching from docker directly. Easily fixed:
docker-compose rm
docker-compose upLooking at docker-compose up help, I think I may be able to fix it with either --force-recreate and/or --renew-anon-volumes. I'll have to wait until the next time the problem occurs to find out.
Type1JGB
commented
4 years ago I really would like this fixed. Just to help anybody else that came across this issue, here's what I did:
There's a file at the path C:\ProgramData\Docker\config\daemon.json. Add the line: "dns": ["8.8.8.8"] in the JSON object.
Ideally, replace it with your actual DNS server. 8.8.8.8 is just a well known DNS server, so it should work.
After adding that line, restart the Docker daemon. You can use the context menu from the system tray for that.
I hope this helps somebody.
rererecursive
commented
3 years ago I had the same problem (Docker on Linux) and fixed it by enabling host networking, i.e.
docker run --network host mcr.microsoft.com/dotnet/core/sdk:2.1
Docker image:
docker inspect --format='{{.Id}}' mcr.microsoft.com/dotnet/core/sdk:2.1 => sha256:156e5cc5d7a3aaf4166d17f1e0b3a3c262a22caf8efac9b855ba1782ef98071c
The container would actually work on my local Linux machine, but on Jenkins (also Linux) it would fail. Very strange.
AraHaan
commented
3 years ago Mine is
C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk\5.0.100\NuGet.targets(131,5): error : Unable to load the service index for source https://dotnet.myget.org/F/roslyn/api/v3/index.json. [D:\a\Sdk\Sdk\build_all_packages.sln] C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk\5.0.100\NuGet.targets(131,5): error : Response status code does not indicate success: 404 (Feed does not exist.). [D:\a\Sdk\Sdk\build_all_packages.sln]
from inside of Github Actions.
zivkan
commented
3 years ago @AraHaan the "dotnet" account at myget (dotnet.myget.org) has been deleted. I suggest using versions of packages available on nuget.org.
AraHaan
commented
3 years ago @zivkan I see, however I usually use the prerelease packages to .NET core assemblies in order to be able to pull in the latest and greatest fixes to them (like for example System.Text.Json from .NET 5 / 6) and using it on netcoreapp3.1.
I do this to then be able to ease up porting to .NET 5 / 6 easier once all of the dependencies get greenlit on the support of .NET 5 / 6.
ajtruckle
commented
3 years ago I also get the error for https://dotnet.myget.org/F/roslyn/api/v3/index.json
/usr/local/share/dotnet/sdk/5.0.102/NuGet.targets(131,5): error : Unable to load the service index for source https://dotnet.myget.org/F/roslyn/api/v3/index.json. [/Users/xxx/Documents/GitHub/AvalonStudio/AvalonStudio/AvalonStudio/AvalonStudio.csproj]
/usr/local/share/dotnet/sdk/5.0.102/NuGet.targets(131,5): error : Response status code does not indicate success: 404 (Feed does not exist.). [/Users/xxx/Documents/GitHub/AvalonStudio/AvalonStudio/AvalonStudio/AvalonStudio.csproj]@ajtruckle I later found out that the roslyn feeds on myget was deleted for the feeds in their azure.
For those I would check by adding the feeds on the dotnet/runtime repository to yours one at a time until your build passes again to figure out which ones to obtain from and replace those with.
ajtruckle
commented
3 years ago It is all to complicated I am afraid for me. These systems should just download and install. I mean, why is AvalonStudio exe download only for OS X? So I can’t even do it that way. And the framework pauses at 34% in GitHub Desktop. Too much hassle. I think I will persevere with XCode and Xamarin forms.
zivkan
commented
3 years ago The feeds on dotnet.myget.org were never official packages, they were used for "daily" CI builds, which certain enthusiasts liked to use, but were in no way ever needed for any official product. If the goal is to keep development simple, I would not recommend using non-standard sources, or pre-release packages. If you got dotnet.myget.org from a solution template or sample, rather than configuring it yourself (or someone in your team), you could ask the template/sample author for an update that doesn't try to use source URLs that no longer exist. NuGet and Visual Studio never configured dotnet.myget.org.
The other comments about AvalonStudio or GitHub Desktop doesn't appear to be related to NuGet in any way (or is missing a lot of context), so I'm not sure how we're supposed to act on the comments.
ajtruckle
commented
3 years ago @zivkan All I did was download AvalonStudio from GitHub. Then use dotnet restore. This failed with the above messages. I have no team. Just download and build.
ddbtrmatic
commented
1 year ago Things I've tried without any luck, based on the solutions provided in this issue.
Environment: Windows 10 Visual Studio 2022 Docker Desktop 4.14.1 Using linux containers
Create new project WebApplication1 from asp core 6 template with docker support
cd WebApplication1/WebApplication1
docker build -f Dockerfile ..
Results:
------
> [build 4/7] RUN dotnet restore "WebApplication1/WebApplication1.csproj":
#12 1.374 Determining projects to restore...
#12 8.163 /src/WebApplication1/WebApplication1.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.
#12 8.235 Failed to restore /src/WebApplication1/WebApplication1.csproj (in 6.57 sec).Attempted work arounds:
["1.1.1.1", "8.8.8.8"]docker system prune --volumes--disable-parallelexport DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0--network=hostAraHaan
commented
1 year ago check if the nuget.org source is enabled, sometimes things might randomly disable it in the background. (or try flushing dns, that sometimes works for me too).
nurulvll
commented
1 year ago [api.nuget.org] Unable to load the service index for source https://api.nuget.org/v3/index.json. An error occurred while sending the request. The remote name could not be resolved: 'api.nuget.org' Unable to load the service index for source https://api.nuget.org/v3/index.json.
i have this problem i can not solve it .
nurulvll
commented
1 year ago 
AraHaan
commented
1 year ago They are running maintenance on it perhaps.
From @Xarkam on June 7, 2017 7:25
Steps to reproduce
Clone https://github.com/ExtCore/ExtCore-Sample-Modular-Ui-Adv
Expected behavior
Restore package
Actual behavior
Environment data
dotnet --infooutput:If I use nuget cli for restore, I don't have any problem.
Copied from original issue: dotnet/cli#6783