Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Pushing fails returning "The underlying connection was closed"
-
This error is from the NuGet client. Is there an error in the ProGet logs that corresponds to the timing of this one?
-
The web interface logs show nothing so I went to the logs on the actual server and I've got this:
2016-04-12 11:49:56 10.30.63.58 GET /nuget/Default - 80 - 10.30.43.41 NuGet/3.3.0.212+(Microsoft+Windows+NT+6.1.7601+Service+Pack+1) - 200 0 0 530 196 15
2016-04-12 11:49:56 10.30.63.58 PUT /nuget/Default/ - 80 - 10.30.43.41 NuGet+Command+Line/3.3.0.212+(Microsoft+Windows+NT+6.1.7601+Service+Pack+1) - 400 0 0 290 333 328So there's an error 400 (bad request) returned from the server but what is the reason?
-
Oh, upon returning to the home page I see this message:
An error occurred processing a PUT request to http://nuget.ourserver/nuget/Default/: There must be exactly one package.
Details:
at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.NuGetApi.PutHandler.<ProcessPutRequestAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.NuGetApi.<ProcessRequestAsync>d__6.MoveNext()Here's the nuget command I issued:
nuget push Our.Package.2.0.0.0.nupkg -source http://nuget.ourserver/nuget/Default -apikey SomeUser:SomePassword -verbosity detailed
-
In this case, it sounds like the problem might be, there's something wrong with the package itself. I'd double check the nuspec file and package format and make sure it conforms to the standards.
-
That's strange....
The package gets pushed without any problem to my local PC using ProGet which is configured with the internal web server.
There seem to be a problem when proget is not using its internal web server but IIS.
-
Furthermore, if I put the same package to the drop path it imports successfully.
-
Found the culprit.
It was the proxy.
-
We're getting this same issue with version 3.4 of the nuget client. Previous clients (i.e. 3.3, 3.2, 2.8) all work correctly with the same package.
-
Seeing same issue as Ross King with Nuget 3.4 client. Workaround is to use older command-line client.
Proxy issue is red herring for this. Should be easy to reproduce with big enough package (>10 mb); my guess is different low-level http library used by 3.4 is showing up as multiple objects sent on Proget side.
-
Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know.
But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that.
There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login