I am using Octopack to push my package to the built in nuget library. This gets built in TFS
Octopack works when using version 3.0.71
But Gives an error when I use any version greater then that.
The error I am getting is:
An error was encountered when fetching ‘PUT http://<octopusserver.octo>/nuget/packages/’. The request will now be retried.
Error while copying content to a stream.
Unable to read data from the transport connection: The connection was closed.
Error MSB3073: The command "“D:\TfsData\Build_work\14\s\Example\packages\OctoPack.3.6.1\build\nuget.exe” push “D:\TfsData\Build_work\14\s\Example_KO\Example\obj\octopacked\Example.2017.7.11.2.nupkg” ******** -Source http://<octopusserver.octo>/nuget/packages " exited with code 1.
When I run the nuget command on the server in powershell, I do not get the error.
Thanks for getting in touch and sorry to hear you’re having difficulty with Octopack. Could you tell me which version of Octopus you are running? The reason I ask is that the Octopack version you’ve referred to is about 12 months old, and looking at our history some changes around Nuget were made in Octopus about that time too, so it could be a version compatibility issue that we haven’t come across previously.
This does seem odd. I believe there are known compatibility issues with the newer Octopack than that version when you have an older Octopus server, but not the other way around.
As of the version following 3.0.71 we include a custom version of nuget.exe with Octopack, to address some SemVer 2 issues. Again, I wouldn’t expect that to cause any issue. Just to check, when you ran it on the server, you just copied the command exactly as above and used the nuget.exe that came with Octopack? Did you run it as the same user the TFS build would be running as?
The reason I ask is that the only other thing I can think of at the moment is a network configuration difference or something like that. We’ve had customers hit issues with different proxy configures between users, as an example.
I did run the copy the command that ran, but not as the same user that the build process uses.
It was a configuration issue for the user that runs the build. In their NuGet.config file I had already set up a proxy so nuget could download nuget packages from outside our network.
I had to add in a “no_proxy” setting for our domain.
Not sure right now why we needed to put a no_proxy setup for the newer versions.
I updated Octopack to version 3.6.1 and TFS was able to push the package to Octopus.
Glad to hear you got it working. I had another chat with the team, and after 3.0.71 the version of nuget.exe we use under the hood was changed, to 3.4 IIRC, so suspect the change in proxy behavior must have come from that.
