Unable to publish nuget package to ProGet using MSBuild parameter in TFS 2013

Currently, I have a project in TFS 2013 (using VS 2013) that compiles fine and outputs a .nupkg package file correctly. I receive an error when MSBuild attempts to push that package to our internal ProGet server. Here’s our MSBuild parameters:


Here’s the error from Visual Studio:

(I’ve omitted full paths for brevity and removed the ApiKey)
D:\Builds…\packages\OctoPack.2.0.26\targets\OctoPack.targets (70): The command ““D:\Builds…\packages\OctoPack.2.0.26\targets\NuGet.exe” push “D:\Builds…\OctopusDeploy\obj\octopacked\” full-api-key-is-given-here -s https://proget.internalcompany.com/nuget/octopus-dev-feed/Packages” exited with code 1.

Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException)
Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Here’s the error in the TFS log:

     OctoPack: OctoPack successful
     Publish to repository: https://proget.internalcompany.com/nuget/octopus-dev-feed/Packages
     "D:\Builds\...\Trunk\packages\OctoPack.2.0.26\targets\NuGet.exe" push "D:\Builds\...\OctopusDeploy\obj\octopacked\" [api key] -s https://proget.internalcompany.com/nuget/octopus-dev-feed/Packages
     Pushing 1 to 'https://proget.internalcompany.com/nuget/octopus-dev-feed/Packages'...
     Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.

Initially, I discovered that the server that ProGet was running on only allowed 1MB uploads. I’ve since changed that to 10MB and still the same error.

I’m not sure what the TFS log is referring to: “Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.”. This is obviously a systems level problem but what could be causing this? Is TFS 2013 unable to automatically push nuget packages to feeds using the msbuild parameter OctoPackPublishPackageToHttp?



(Snipped API key out of the log output.)

Hi Ian - can you successfully push a package to the ProGet feed from the TFS machine using the NuGet.exe command line? The third line of the log output above shows what the command looks like.

It is possible there’s an issue with the API key (needs to be the ProGet one) or the network connection in between the machines.

If NuGet.exe fails as well, it might provide some more helpful output we can work with. Sending the same info to the ProGet team might also yield some insights.


Tried to do so using nuget command line but each time it times out. I tried extending the timeout from 5 minutes to 10 minutes but no luck. The nuget package being uploaded is only about 4.5mb in size.

I’ll try reading through the ProGet documentation and forums as well. If the API key was bad or something wasn’t right, wouldn’t I get an API-key-centric error?


Actually, I didn’t think about this but, what ports does a nuget push require? Does it all happen over port 80 or 443? Since I’m using https, I imagine I’m using 443, but by default what does NuGet use? Maybe this is a port configuration issue.

As far as I know, it should use the regular ports. The NuGet forum might be able to suggest some troubleshooting strategies for this, I’m not sure how to get more detailed logs/info out of it.


I’m going to close this issue. I was able to get TFS to publish to a MyGet.org feed without any issues. I’m sure it’s some configuration issue with ProGet or maybe an incorrect path I’m using.

Just wanted to update this thread; we found out that within a domain environment, the Octopus Deploy server needs to have a domain account, not a local account. That solves authenticating to the ProGet server which seems to be the problem.

We’re at another problem where it seems only certain sizes of packages can be pushed to the ProGet server but that appears to be a ProGet issue, not OctoPack at this juncture.

Thanks very much for sharing the solution Ian, I’m sure it will help other people who encounter the problem. Much appreciated.


Another update to this thread - we figured out why ProGet was not able to upload packages. We had ProGet behind a load balancer. Some setting within our load balancer was the problem. We’re searching for the exact issue but if we specifically target the ProGet server behind the load balancer, we’re able to upload packages.