Publishing nuget packages from windows works. Mac is failing
We are publishing the same nuget package in both.
You can see what version of nuget we are using in the user agent below.
The mac says it succeeds, but it is not in the repo.
It looks like it is not sending the payload on the mac.
Debug: nuget push dotnet-build-connector.1.0.0-32.nupkg -Verbosity detailed -s Artifactory -NonInteractive
WARNING: No API Key was provided and no API Key could be found for 'http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/'. To save an API Key for a source use the 'setApiKey' command.
Pushing dotnet-build-connector.1.0.0-32.nupkg to 'http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/'...
PUT http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/
Unauthorized http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/ 172ms
Using credentials from config. UserName: patrick.barry
PUT http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/
Created http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/ 276ms
Your package was pushed.
I captured the http traffic of both.
MAC
REQUEST….
PUT /mycompany/api/nuget/repo-nuget-virtual/ HTTP/1.1
user-agent: NuGet Command Line/3.4.4.1321 (Unix 15.6.0.0)
Content-Type: multipart/form-data; boundary="5ee028f9-d105-444d-a520-0aa881118059"
Authorization: Basic xxxx
Content-Length: 228
Expect: 100-continue
Accept-Encoding: gzip, deflate
Host: mycompany.artifactoryonline.com
Pragma: no-cache
Cache-Control: no-cache
--5ee028f9-d105-444d-a520-0aa881118059
Content-Type: application/octet-stream
Content-Disposition: form-data; name=package; filename=package.nupkg; filename*=utf-8''package.nupkg
--5ee028f9-d105-444d-a520-0aa881118059--
RESPONSE…
HTTP/1.1 201 Created
Content-Type: text/plain
Date: Fri, 29 Jul 2016 13:25:27 GMT
Server: Artifactory/4.9.0
X-Artifactory-Id: dedicatedha1c.prod-use1.jfrog.local-mycompany
X-Artifactory-Node-Id: mycompany-s1
X-Node: nginx-dedicated5e.prod-use1
transfer-encoding: chunked
Connection: keep-alive
X-Charles-Received-Continue: HTTP/1.1 100 Continue
Expires: 0
Cache-Control: no-cache
Successfully published NuPkg to: null.null.nupkg
WINDOW
REQUEST…
PUT http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/ HTTP/1.1
user-agent: NuGet Command Line/3.4.3.855 (Microsoft Windows NT 6.1.7601 Service Pack 1)
Content-Type: multipart/form-data; boundary="be3d0f8a-6f14-4d7d-8647-7e1b334e4f8a"
Accept-Encoding: gzip, deflate
Authorization: Basic xxx
Host: mycompany.artifactoryonline.com
Content-Length: 8142
Expect: 100-continue
--be3d0f8a-6f14-4d7d-8647-7e1b334e4f8a
Content-Type: application/octet-stream
Content-Disposition: form-data; name=package; filename=package.nupkg; filename*=utf-8''package.nupkg
RESPONSE…
HTTP/1.1 201 Created
Content-Type: text/plain
Date: Fri, 29 Jul 2016 13:33:16 GMT
Server: Artifactory/4.9.0
X-Artifactory-Id: dedicatedha1c.prod-use1.jfrog.local-mycompany
X-Artifactory-Node-Id: mycompany-m
X-Node: nginx-dedicated5e.prod-use1
transfer-encoding: chunked
Connection: keep-alive
46
Successfully published NuPkg to: dotnet-build-connector.1.0.0-22.nupkg
0
WARNING: No API Key was provided and no API Key could be found for 'http://mycompany.artifactoryonline.com/mycompany/api/nuget/repo-nuget-virtual/'. To save an API Key for a source use the 'setApiKey' command.
Does it work if you set your api key or pass it on the command line?
The fact that it says it completed but didn't actually push the package looks like a bug.
You can ignore the warning. I get that on windows as well and it still works. I agree, i believe this to be a bug.
Successfully published NuPkg to: null.null.nupkg
@patrickjamesbarry would you try with the latest nightly build of nuget.exe from: https://www.myget.org/F/nugetbuild/api/v2/package/NuGet.CommandLine
sure, what do I need to do to install it?
extract nuget.exe from the tools folder in the nupkg, you can rename the nupkg to .zip
exe files do not run on mac...
Looks like the nuget I have is coming from mono.
which nuget
/usr/local/bin/nuget
Commands: ls -al /usr/local/bin | grep nuget
lrwxr-xr-x 1 root admin 49 Mar 21 13:16
nuget -> /Library/Frameworks/Mono.framework/Commands/nuget
On Fri, Jul 29, 2016 at 1:55 PM, Justin Emgarten [email protected]
wrote:
extract nuget.exe from the tools folder in the nupkg
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-236248866, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63ij-OyW_3oUlPR3mwjsxgiW4UtApZks5qaj6CgaJpZM4JYXbT
.
@patrickjamesbarry typically mono nuget.exe will work
Ahh, I didn't know you could run nuget like that. Looks like the problem
is still a problem. It is not sending the package.
Request
PUT /mycompany/api/nuget/nuget-virtual/ HTTP/1.1
user-agent NuGet Command Line/3.5.0-rc1-1697 (Unix 15.6.0.0)
Accept-Language en-US
Content-Type multipart/form-data; boundary="17474ca0-145b-421e-8e06-9b58dd828da4"
Authorization Basic xxxxx
Content-Length 228
Host 127.0.0.1:8887
Accept-Encoding gzip, deflate
Pragma no-cache
Cache-Control no-cache--865c5001-6a15-4a7d-9c2b-63f6ba5379ec
Content-Type: application/octet-stream
Content-Disposition: form-data; name=package; filename=package.nupkg; filename*=utf-8''package.nupkg--865c5001-6a15-4a7d-9c2b-63f6ba5379ec--
RESPONSE
HTTP/1.1 201 Created
Content-Type text/plain
Date Mon, 01 Aug 2016 18:08:57 GMT
Server Artifactory/4.9.0
X-Artifactory-Id dedicatedha1c.prod-use1.jfrog.local-mycompany
X-Artifactory-Node-Id mycompany-s1
X-Node nginx-dedicated5e.prod-use1
Cache-Control no-cache
Transfer-Encoding chunked
Connection Keep-alive
Expires 0Successfully published NuPkg to: null.null.nupkg
@patrickjamesbarry thanks for checking! Looks like this will may need a fix on the NuGet side.
Does that mean I need to log another ticket elsewhere?
On Mon, Aug 1, 2016 at 4:00 PM, Justin Emgarten [email protected]
wrote:
@patrickjamesbarry https://github.com/patrickjamesbarry thanks for
checking! Looks like this will may need a fix on the NuGet side.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-236690069, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63inzyGxBCtmM32dhlXikvIbnn8YZJks5qblBygaJpZM4JYXbT
.
Does that mean I need to log another ticket elsewhere?
Nope, this is the right place :smile:
This seems like a pretty big problem. Can this be labeled a bug and put on
the roadmap or something. Like to see some priority on it.
pb
On Tue, Aug 2, 2016 at 1:22 AM, Justin Emgarten [email protected]
wrote:
Does that mean I need to log another ticket elsewhere?
Nope, this is the right place 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-236801628, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63iguDpwKtp4Er3Euoc03Je5X1--etks5qbtQAgaJpZM4JYXbT
.
@patrickjamesbarry I tried to push package on Mac to nuget.org, it works well. Also, looks like you are using different version on Mac and windows, On Mac is 3.4.4.1321 and windows is 3.4.3.855, and from your log, on Mac the content is 228 but on windows is 8142, looks like on mac it doesn't send the payload.
I don't think it is an Artifactory issue. As you can see from my network
monitoring, the package is not getting sent in the payload. Are you using
the same version of nuget? If this was an Artifactory issue, why would the
windows version work? When you push to nuget.org, are those repositories
protected with credentials? Artifactory is, so maybe that is the
difference?
On Wed, Aug 17, 2016 at 1:47 PM, Zhi Li [email protected] wrote:
@patrickjamesbarry https://github.com/patrickjamesbarry I tried to push
package on Mac to nuget.org, it works well. Can you push packages to
nuget.org on your machine? I'm not sure this is a nuget.exe issue or
Artifactory server issue.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-240490511, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63ij6wzEixyCUXJyquHyp-B-7Ws4sKks5qg0kZgaJpZM4JYXbT
.
Sorry for my previous message, I edited my reply, I suspect it's client issue too, so I need to know your mono version first, and also you are using different nuget version on windows and mac, Can you try same version on both, then provide the log. thank you.
Mono JIT compiler version 4.4.1 (Nightly 4.4.1.0/4747417 Tue Jul 5
17:44:19 BST 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
TLS: normal
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen
_Mac nuget: NuGet Version: 3.4.4.1321_
_Windows nuget: NuGet Version: 3.4.3.855_
I also tried the nightly build version that Justin had mentioned above with
same results.
On Thu, Aug 18, 2016 at 12:16 PM, Zhi Li [email protected] wrote:
Sorry for my previous message, I edited my reply, I suspect it's client
issue too, so I need to know your mono version first, and also you are
using different nuget version on windows and mac, Can you try same version
on both, then provide the log. thank you.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-240775452, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63irWSCFvFd6_fy2jVbbY1-hk4UtM2ks5qhIVfgaJpZM4JYXbT
.
@patrickjamesbarry I set up a artifactory online server and tried to push package, it works well with mono 4.4.2, Can you update your mono version to latest? it might fix your issue. Thanks
After I updated, I have same issue.
test-project: mono -V
Mono JIT compiler version 4.4.2 (Stable 4.4.2.11/f72fe45 Thu Aug 11
06:03:25 BST 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
TLS: normal
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen
It says it successfully pushes, and all i see in artifactory is a new
package named: null.null.nupkg with nothing in it.
pb
On Thu, Aug 18, 2016 at 1:46 PM, Zhi Li [email protected] wrote:
@patrickjamesbarry https://github.com/patrickjamesbarry I set up a
artifactory online server and tried to push package, it works well with
mono 4.4.2, Can you update your mono version to latest? it might fix your
issue. Thanks—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-240800932, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63iq_9U5cKLircjbkWpUuZNocN09PGks5qhJqCgaJpZM4JYXbT
.
@patrickjamesbarry - @zhili1208 has a new theory. Perhaps you have some anti-virus that is preventing the sending of a zip file across the network?
Do you have some software (anti-virus or the like) running on all of your machines that you could temporarily disable?
I did. I disabled it and problem persist.
On Thu, Aug 18, 2016 at 4:46 PM, Rob Relyea [email protected]
wrote:
@patrickjamesbarry https://github.com/patrickjamesbarry - @zhili1208
https://github.com/zhili1208 has a new theory. Perhaps you have some
anti-virus that is preventing the sending of a zip file across the network?
Do you have some software (anti-virus or the like) running on all of your
machines that you could temporarily disable?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-240851156, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63ikvZriizqI7Ofvw6djXycDPYnFGOks5qhMSKgaJpZM4JYXbT
.
On Fri, Aug 19, 2016 at 9:58 AM, Patrick Barry [email protected]
wrote:
I did. I disabled it and problem persist.
On Thu, Aug 18, 2016 at 4:46 PM, Rob Relyea [email protected]
wrote:@patrickjamesbarry https://github.com/patrickjamesbarry - @zhili1208
https://github.com/zhili1208 has a new theory. Perhaps you have some
anti-virus that is preventing the sending of a zip file across the network?
Do you have some software (anti-virus or the like) running on all of your
machines that you could temporarily disable?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-240851156, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63ikvZriizqI7Ofvw6djXycDPYnFGOks5qhMSKgaJpZM4JYXbT
.
@patrickjamesbarry thank you, good find. I compared the code between NuGet 2.12 and 3.4, the difference is 3.4 added one more header ( request.Headers.TransferEncodingChunked = true;) So I can remove that line and get a private build, could you help to verify that build? Please send email to me([email protected]), I can give you the build.
If this does turn out to be the problem, this may be a mono bug?
This post discusses some mono problems in this area:
if that turns out to be the case, we could work with @mrward
No dice on the custom build.
(I did notice that you guys do not accept "-s" anymore for source. Now I
have to spell it out. Will you be bringing back the -s so it does not
break current scripts using that command?)
On Fri, Aug 19, 2016 at 2:01 PM, Rob Relyea [email protected]
wrote:
If this does turn out to be the problem, this may be a mono bug?
This post discusses some mono problems in this area:
- http://stackoverflow.com/questions/24613769/downloadstring-and-
httpwebresponse-is-not-returning-the-full-json-content
http://stackoverflow.com/questions/24613769/downloadstring-and-httpwebresponse-is-not-returning-the-full-json-contentif that turns out to be the case, we could work with @mrward
https://github.com/mrward—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/3251#issuecomment-241090267, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB63iuj84QpLBlEDgEH7zYVcsxIEmQPeks5qhe98gaJpZM4JYXbT
.
thank you, you can file a bug for "-s" support. NuGet doesn't do any magic things around push, just send HttpRequest, we might need help from mono. @mrward
@patrickjamesbarry I just create a test app which just use basic HttpClient API, Can you help me to test it on your machine? https://github.com/zhili1208/monoPushIssue/MacPushTestApp.exe, just type"mono MacPushTestApp.exe [package path] [apikey] [source]". If this doesn't work, we need to look at those mono API, otherwise, I will check nuget timeout, credential and configuration code. thanks
https://github.com/zhili1208/monoPushIssue/MacPushTestApp.exe => 404 for me
Please go to https://github.com/zhili1208/monoPushIssue/
I tested with the test app and it resulted in a successful message, yet the package did not appear in the nuget feed. This supports the above network trace of the client reporting a 201 Created status code, yet nuget package was never sent.
Thank you, Patrick! then we need to look at mono API, this TestApp doesn't include any nuget logic, just simple send a "put" request.
Created a mono bug: https://bugzilla.xamarin.com/show_bug.cgi?id=44027
Doesn't appear there is a work around we can do, as Mono team and NuGet team haven't been able to reproduce the problem that @patrickjamesbarry sees in his environment.
Closing as not repro. If we are able to reproduce in other environments, please reopen this issue.
Same happens on my machine, with every NuGet version available today.
Version info: https://gist.github.com/SamuelDebruyn/6e807c6bc1aeb077a01c9b36ffe26366
I also tried with NuGet that ships with Mono 4.6.1
I spent a bit of time looking at this today trying to get NuGet push working on VSTS. I think the issue here is how NuGet does its weird magic with HttpHandler.
From my understanding of the whole pipeline, NuGet seems to be using a custom HttpHandler (HttpSourceAuthenticationHandler) wrapping the BCL default HttpClientHandler to do its authentication work.
This thing seems to rely on the fact that NuGet can retry sending a request a few times over. During the push process, it will try to send the request first with no Authorization header, get a 401 back, somehow get the proper authorization header in the meantime and retry the same request with the added Authorization header.
Now, the issue at hand here is how NuGet reuses the base HttpRequestMessage in PackageUpdateResource.CreateRequest. Instead of recreating the request when retrying to send it (like the failure path that uses the HttpRetryHandler thing) it will reuse the same one.
On Mono this means trouble because the package is being added to the request as a StreamContent object. If you look at the implementation, in a nutshell the code will use the Stream.CopyToAsync method to do its copying into the underlying WebRequest.
What that means is that once that CopyToAsync is called, the stream is never rewinded and becomes fully consumed. Because the authentication handler ends up calling the same method on the same stream again, the end result is that the second time around the stream is considered, well, empty which means nothing is actually being sent to the server.
If you observe the headers that are sent during a NuGet push transaction it becomes fairly apparent:
First pass:
PUT $(URL)/nuget/v2/ HTTP/1.1
X-NuGet-ApiKey VSTS
user-agent NuGet Command Line/3.5.0 (Unix 16.4.0.0)
Accept-Language en-US
Content-Type multipart/form-data; boundary="10f05a0f-fc5a-4163-b334-353ea40add89"
Content-Length 5624063
Connection keep-alive
Host pkgs.visualstudio.com
Accept-Encoding gzip, deflate
Second pass:
PUT $(URL)/nuget/v2/ HTTP/1.1
X-NuGet-ApiKey VSTS
user-agent NuGet Command Line/3.5.0 (Unix 16.4.0.0)
Accept-Language en-US
Content-Type multipart/form-data; boundary="10f05a0f-fc5a-4163-b334-353ea40add89"
Content-Length 228
Connection keep-alive
Host pkgs.visualstudio.com
Accept-Encoding gzip, deflate
Authorization Basic <long base64>
Notice how in the second case the Authorization header is present and the variation of the Content-Length header which goes from the full size of the file + multipart header to just the bare multipart header.
Now to say that's Mono fault I'm not sure. Is StreamContent supposed to be reusable and thus smart enough to rewind things in the general? Obviously if the stream is not seekable that's impossible so I would be inclined to think NuGet is relying on an implementation detail that just happens to make it works on some runtime.
Fixing this could be done either by switching the StreamContent to a ByteArrayContent (albeit having a memory hit) or re-create properly the original HttpRequestMessage with HttpSourceAuthenticationHandler or implement a custom smarter StreamContent subclass that can cache/rewind things like FileStream when it's called again?
With a patched Mono build I do get push to work for me, tracking this upstream in https://bugzilla.xamarin.com/show_bug.cgi?id=52448
Fixed properly upstream: https://github.com/mono/mono/commit/4393b684526a78da6b9d5d45b82758e23676da57
I'm still facing a problem, even with Mono 5.0.0.100. We have 5 .nupkg's that we build and upload to our VSTS NuGet server. 3 out of 5 of them always succeed, but 2 always fail. For a while, it started working again and we thought this might be related to having Charles running as a proxy on our Mac build machine. But even with this running now we are still seeing problems.
I'm absolutely convinced this is related to the size of the nupkg's. As you can see from the terminal outputs below, the 3 that work are the smallest and the 2 that fail are the biggest. I've starred (*) out sensitive names
1316511 16 May 13:20 ..Mobile.Services.1.0.nupkg (Fails with below message)
418477 16 May 13:30 ..Mobile.ViewModels.1.0.nupkg (Fails with below message)
122084 16 May 13:34 ..Mobile.ViewAbstractions.1.0.nupkg (Works)
42406 16 May 13:31 ..Mobile.Abstractions.1.0.nupkg (Works)
21625 16 May 13:32 ..Mobile.ServiceAbstractions.1.0.nupkg (Works)
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
at System.Net.WebConnectionStream.EndWrite (System.IAsyncResult r) [0x00097] in
at System.Net.WebConnectionStream.Write (System.Byte[] buffer, System.Int32 offset, System.Int32 size) [0x00053] in
at NuGet.MultipartWebRequest.CreateMultipartRequest (System.Net.WebRequest request) [0x001b9] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.PackageServer+<>c__DisplayClass13_0.
at (wrapper delegate-invoke) System.EventHandler1[NuGet.WebRequestEventArgs]:invoke_void_object_TEventArgs (object,NuGet.WebRequestEventArgs)
at NuGet.HttpClient.RaiseSendingRequest (System.Net.WebRequest webRequest) [0x0000d] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.RequestHelper.GetResponse () [0x0010a] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.HttpClient.GetResponse () [0x00032] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.PackageServer.EnsureSuccessfulResponse (NuGet.HttpClient client, System.Nullable1[T] expectedStatusCode) [0x00002] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.PackageServer.PushPackageToServer (System.String apiKey, System.Func`1[TResult] packageStreamFactory, System.Int64 packageSize, System.Int32 timeout, System.Boolean disableBuffering) [0x0006f] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.PackageServer.PushPackage (System.String apiKey, NuGet.IPackage package, System.Int64 packageSize, System.Int32 timeout, System.Boolean disableBuffering) [0x00026] in <5226e4f718e24c13b665b670078f7b6e>:0
at NuGet.Commands.PushCommand.PushPackageCore (System.String source, System.String apiKey, NuGet.PackageServer packageServer, System.String packageToPush, System.TimeSpan timeout) [0x00058] in <9c11515108ff4f45937928ed5e56b6d8>:0
at NuGet.Commands.PushCommand.PushPackage (System.String packagePath, System.String source, System.String apiKey, System.TimeSpan timeout) [0x0003c] in <9c11515108ff4f45937928ed5e56b6d8>:0
at NuGet.Commands.PushCommand.ExecuteCommand () [0x00086] in <9c11515108ff4f45937928ed5e56b6d8>:0
at NuGet.Commands.Command.Execute () [0x000ca] in <9c11515108ff4f45937928ed5e56b6d8>:0
at NuGet.Program.Main (System.String[] args) [0x0018b] in <9c11515108ff4f45937928ed5e56b6d8>:0
Note that I posted the above feedback here because of:
This matches my findings too, see upstream bug https://bugzilla.xamarin.com/show_bug.cgi?id=52579
Unfortunately the Mono network code is quite complicated so it's hard to pinpoint exactly the problem.
Looks like that xamarin bug (or one that it links to), may be fixed as of July 2017. Anybody here able to confirm that this fixes the NuGet scenario or not?
putting in backlog, just to keep our eye on it. Still is closed, as we think this should be fixed in mono, currently.
When trying to push a package :
System.Exception: Pushing took too long. You can change the default timeout of 300 seconds by using the -Timeout
Any idea if we need to upgrade another component as well ? I was hoping that with the latest mono version, this problem would be solved.
I am getting the same error as discussed in this thread. I tested this on terminal.
Pushing MyNuget.nupkg to 'http://Uri:port/nuget'...
PUT http://Uri:port/nuget/
An error was encountered when fetching 'PUThttp://Uri:port/nuget'. The request will now be retried.
Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
PUT http://Uri:port/nuget/
NotAcceptable http://Uri:port/nuget/13ms
406 (Not Acceptable)
My mono version : Mono JIT compiler version 5.4.1.6
Nuget version : latest 4.4.1.
Does anyone know the workaround for this issue ?
This is weired, For me the order of the command matters. I tried with
@emysa341 I got tired of nuget push not working, so I wrote a small python script using requests in order to push my package:
import requests
import os
import sys
# https://docs.microsoft.com/en-us/nuget/api/package-publish-resource
def put_package(file_path, user_api_key):
file_obj = open(file_path, 'rb')
base_name = os.path.basename(file_path)
headers = {'X-NuGet-ApiKey': user_api_key}
r = requests.put('https://www.nuget.org/api/v2/package', headers=headers, files={"archive": (base_name, file_obj)})
if r.status_code == 201 or r.status_code == 202:
print("The package was successfully pushed!")
elif r.status_code == 400:
print("The provided package is invalid")
print(r.text)
elif r.status_code == 409:
print("A package with the provided ID and version already exists")
print(r.text)
else:
print("unknown error")
print(r.text)
if __name__ == "__main__":
put_package(sys.argv[1], sys.argv[2])
To use this you'll need requests installed (http://docs.python-requests.org/en/master/user/install/#install).
python3 put_nupkg.py ./path_your_package.nupkg YOUR_NUGET_API_KEY
Any updates on this issue?
There is a workaround..... This took me ages to figure out unfortunately. Although it doesn't involve mono.
Assuming you have your desired nuget.config inside /wd/ this will push everything in /nuget-artifacts/ to NuGet according to the settings in that config file. You do not specify a source.
(cd /wd/ ; dotnet nuget push /nuget-artifacts/ --api-key vsts)
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="DefaultPushSource" value="FILL ME OUT" />
</config>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json"/>
<add key="CustomFeed" value="FILL ME OUT" />
</packageSources>
<packageSourceCredentials>
<CustomFeed>
<add key="Username" value="vsts" />
<add key="ClearTextPassword" value="FILL ME OUT" />
</CustomFeed>
</packageSourceCredentials>
</configuration>
@garuma seems folks are still facing issues with this scenario. Are you tracking this in mono?
@mishra14 not that I know of
Still no working NuGet push for VSTS/Azure DevOps on Mac?
Bump. I'm also having this issue, both from paket and nuget.
macOS Catalina 10.15.2
λ mono --version
Mono JIT compiler version 6.6.0.161 (tarball Tue Dec 10 23:03:25 GMT 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS:
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
Suspend: hybrid
GC: sgen (concurrent by default)
Thank you for your feedback. We believe that this is fixed on 16.6 Preview 2 or later. Would you please let us know if you continue having issues with updated repro steps? Thanks!
Most helpful comment
Any updates on this issue?