System.ServiceModel.ProtocolException when pushing into local NugetGallery

Topics: General
Sep 24, 2012 at 2:34 PM
Edited Sep 24, 2012 at 2:39 PM


I set up a couple of weeks ago a local nuget gallery sucessfully. Every thing worked fine until ... something happened !

I can't recall what I messed up but the fact is I keep getting a System.ServiceModel.ProtocolException every time I try to push a package up to the server.

The Exception states I should increase the MaxReceivedMessageSize property as the maximum message size has been exceeded.

It's been almost two days that i'm hopelessly looking around for a solution, any help would be greatly appreciated.

What I've just tried out was to use a freshly checked out version of the gallery from github, but it gives me exactly the same result.

I also tried various changes to the web.config file but to no avail.

Sep 24, 2012 at 5:21 PM

How large is your package? You might be running into an issue with IIS's request size limit. 

Sep 24, 2012 at 5:56 PM
Edited Sep 24, 2012 at 7:33 PM

So it seems ! The package is about 5 Mb. The max size the exception reports is 65535 bytes which is the default value. I tried to modify the value through the web.config file but I didn't find the correct settings.

How can I modify the settings for the gallery to work ? Is it in the IIS settings or the web.config the right place to modify this ?

I even tried the same gallery on different IIS installations and they show the same behavior ! How come it works for others ? 


One more thing I forgot to mention: I can upload packages without any problem through the web interface. The command line is making me trouble. Every time I push a package I get the error. At first I hat a bad request reponse, now I get 403 reponses.

I need the command line to work as it's intended to be integrated in our build process.

Sep 25, 2012 at 1:08 PM
Edited Sep 25, 2012 at 1:21 PM

I just tried another completely clean install with the standard settings for IIS express. I get exactly the same effect. The Gallery source I used is the one found in the git repository, the web config hasn't been changed except for the site root and the removal of the rewrite rules. 

The error I'm seeing on the command line is still the same: 


C:\nuget>nuget push Dummy.1.0.0.nupkg -S local
Pushing Dummy 1.0.0 to 'http://localhost/api/v2/'...
Failed to process request. 'Bad Request'.
Der Remoteserver hat einen Fehler zur�ckgegeben: (400) Ung�ltige Anforderung...

The stack trace on the server side is still the same:


 bei System.ServiceModel.Channels.HttpInput.ThrowMaxReceivedMessageSizeExceeded()   bei System.ServiceModel.Channels.HttpInput.ReadBufferedMessage(Stream inputStream)   bei System.ServiceModel.Channels.HttpInput.ParseIncomingMessage(Exception& requestException)   bei System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, Action callback)   bei System.ServiceModel.Activation.HostedHttpTransportManager.HttpContextReceived(HostedHttpRequestAsyncResult result)   bei System.ServiceModel.Activation.HostedHttpRequestAsyncResult.HandleRequest()   bei System.ServiceModel.Activation.HostedHttpRequestAsyncResult.BeginRequest()   bei System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequest(Object state)   bei System.ServiceModel.AspNetPartialTrustHelpers.PartialTrustInvoke(ContextCallback callback, Object state)   bei System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequestWithFlow(Object state)   bei System.Runtime.IOThreadScheduler.ScheduledOverlapped.IOCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)   bei System.Runtime.Fx.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error, UInt32 bytesRead, NativeOverlapped* nativeOverlapped)   bei System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

 With this extended exception text: 

System.ServiceModel.ProtocolException: Das maximale Nachrichtengrößenkontingent für eingehende Nachrichten (65536) wurde überschritten. Verwenden Sie die MaxReceivedMessageSize-Eigenschaft für das entsprechende Bindungselement, um das Kontingent zu erhöhen.

Sep 25, 2012 at 4:59 PM

Not sure why you'd get this error. If you can try pushing to to see if you run into the same issue. Also, does this stackoverflow post help you in anyway?

Sep 26, 2012 at 8:06 AM
Edited Sep 26, 2012 at 10:51 AM

One thing is reassuring, I can push packages to ! 

However the post didn't bring me one step further. I actully looked through stack overflow and found many similar questions.

I think the solution to my problem would be modify the configuration file to increase the requested parameter, the problem with that is that in order to get the configuration parameter picked up a full service configuration must be present in the config file in order for this to work. To do that I would need to figure out how the nuget service is configured, how to define the endpoints etc ... all of this is really new to me, so I'm really lost !

I also found a post in stackoverflow : which seems to point that in certain combinations the max parameter size is not picked up at all ....


I suppose the web.config used for the site is the same as in the source archive ?

Sep 26, 2012 at 5:12 PM

I doubt we made any specific settings to IIS outside of what we have in the config. That said, I think you should pursue this bug on the github issue tracker. Perhaps you can start by attaching the nupkg. 

Sep 27, 2012 at 12:16 PM
Edited Sep 27, 2012 at 12:35 PM

Ok. I got this solved !!!!!

Stupid me !

The problem came from the fact that nuget was using the wrong URL to push packages !!!

I forgot that I needed 2 sources for nuget, one to push and one to get the packages !

  •  Source to push:
  • Source to get:

This is the workaround I had found and forgot about it ! 

This is probably not an expected behavior ...

Is this a bug ? Or is this a mis-configuration on my part somewhere ? If it is the case, were must I look ?

Sep 27, 2012 at 12:45 PM
Edited Sep 27, 2012 at 12:51 PM

There must be a trick somewhere, I can confirm this behavior with the preview site.

This seems to be a command line tool issue. Just created a work item for this: