maxReceivedMessageSize not fixing 413: Request Entity Too Large - wcf

My call to my WCF web service is failing with System.Net.WebException: The request failed with HTTP status 413: Request Entity Too Large.
Checking Fiddler, I see that I'm sending:
Content-Length: 149839
Which is over 65KB.
Enabling WCF tracing on the server, I see:
System.ServiceModel.ProtocolException: The maximum message size quota
for incoming messages (65536) has been exceeded. To increase the
quota, use the MaxReceivedMessageSize property on the appropriate
binding element.
Adding this property doesn't solve the issue.
I've tried with just that property, and (later) with various others that posts have suggested. Here's what I have currently (on the server):
<basicHttpBinding>
<binding name="PricerServiceSoap"
closeTimeout="00:10:00" openTimeout="00:10:00"
receiveTimeout="00:10:00" sendTimeout="00:10:00"
maxBufferSize="2147483647"
maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</binding>
</basicHttpBinding>
My sole endpoint (under <client>) is:
<endpoint address="/NetPricingService/Service.asmx"
binding="basicHttpBinding" bindingConfiguration="PricerServiceSoap"
contract="Pricing.PricerService.PricerServiceSoap"
name="PricerServiceSoap" />
I've also added:
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
under <behavior>.
I've even run (for IIS 7):
%windir%\system32\inetsrv\appcmd set config "WebServicesDev/PricingService"
-section:requestFiltering -requestLimits.maxAllowedContentLength:104857600
-commitpath:apphost
Nothing makes any difference.
One catch is that this is a WCF service meant to replace an older ASMX service. The service skeleton was generated with svcutil from existing WSDL. I can't change the client configurations (and the clients are in multiple languages). My test client project imported the service with Add Web Reference (under Add Service Reference / Advanced), so I have no WCF configuration. However, the test client works if I point it at the older ASMX service.
How can I fix or diagnose this?
Additional info
If I use the Microsoft Service Configuration Editor to generate the config (setting maxReceivedMessageSize and maxBufferSize), it works. The problem is that the endpoint is then specified under <service>, and it won't let me specify the /NetPricingService/Service.asmx relative address. If I edit the bindings in the svcutil-generated config (where the endpoint is under <client>), it doesn't work with large requests.

The answer was staring me in the face.
The config generated by svcutil was for the client. I was using it on the server.
I was editing the bindings for the endpoints specified under <client>, which made absolutely no difference to the service.
Adding a proper <service> endpoint and setting the maxReceivedMessageSize and maxBufferSize on its binding resolved the issue.

I had a similar problem.
For me, the problem was that my endpoint did not explicitly name the binding using bindingConfiguration and so must have been using some default one somewhere.
I had:
<webHttpBinding>
<binding
name="myXmlHttpBinding"
maxReceivedMessageSize="10485760"
maxBufferSize="10485760">
<readerQuotas
maxDepth="2147483647"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647"/>
<security mode="None"/>
</binding>
</webHttpBinding>
and my endpoint defined as:
<service
name="blah.SomeService">
<endpoint
address=""
behaviorConfiguration="WebHttpBehavior"
binding="webHttpBinding"
contract="blah.ISomeService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>
It worked once I changed the endpoint to:
<service name="blah.SomeService">
<endpoint address=""
behaviorConfiguration="WebHttpBehavior"
binding="webHttpBinding"
bindingConfiguration="myXmlHttpBinding"
contract="blah.ISomeService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>

I also had this problem and realized in fiddler that the max Content-Length that was working ended up being 30000000.
After verifying that my WCF configuration was correct I found an article suggesting a modification to the IIS setting, Request Filtering.
Large file upload failure for Web application calling WCF service – 413 Request entity too large
Open IIS Manager
Select your application
Select the Request Filtering icon.
Select Edit Feature Settings... (Right Panel)
Adjust the Maximum allowed content length (Bytes) Default Appears to be 30000000
or web.config file example
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="50000000" />
</requestFiltering>
</security>
</system.webServer>

tried things from 10 different blogs and my coworker figured it out.
we had to add a basicHttpsBinding section inside of in addition to the basicHttpBinding section. We have a webapi service calling wcf. the webapi method was catching the entity too large error when it called the wcf service method. This change was applied in the web.config file of the wcf service.

None of the suggestions worked for me. What solved the issue was to increase the MaxReceivedMessageSize in System.ServiceModel.Channels.HttpTransportBindingElement
There are two different MaxReceivedMessageSize parameters:
MaxReceivedMessageSize in
System.ServiceModel.Configuration.BasicHttpBindingElement
MaxReceivedMessageSize in
System.ServiceModel.Channels.HttpTransportBindingElement
In the dump file, I saw that it was failing because of the limitation in HttpTransportBindingElement
Adding this to my web.config fixed the issue:
<customBinding>
<binding closeTimeout="00:10:00" openTimeout="00:10:00" sendTimeout="00:10:00">
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" useDefaultWebProxy="true" transferMode="Buffered" />
</binding>
</customBinding>
Source: WCF service shows 413 Request Entity Too Large error when uploading files over 64 KB

Add this solve it for me:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_Example"
maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
</binding>
</basicHttpBinding>
</bindings>

Related

HTTP 413 error posting to SharePoint web service

I know the "HTTP 413 Request Entity too large" error is a FAQ. But I have a variation that I've been unable to figure out for two days now. I've created a WCF service endpoint as part of an on-prem SharePoint 2013 application (see below). The web site is SSL enabled and I'm getting the 413 error. I've tried increasing maxReceivedMessageSize in the site web.config per the many posts related to this error as well as modifying the flag on the site itself via IIS Manager / Site / Management / Configuration Editor. But nothing seems to work. I can post small files with no problem. My guess is that maybe SharePoint does something to override the binding and that I need to apply the maxReceivedMessageSize change in a different place
Service contract
[ServiceContract]
public interface ISharepointService
{
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "UploadFile?partner={partnerid}&location={locationid}&filename={filename}&type={type}&period={period}")]
void UploadFile(string partnerid, string locationid, string filename, string type, string period, Stream stream);*
web.config
<services>
<service behaviorConfiguration="serviceBehavior" name="MyCompany.Sharepoint.MyService.SharepointServiceApp">
<endpoint address="Sharepoint" behaviorConfiguration="webBehavior" binding="webHttpBinding" bindingConfiguration="webBinding" contract="MyCompany.Sharepoint.MyService.SharepointServiceApp"></endpoint>
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
</service>
</services>
<bindings>
<webHttpBinding>
<binding name="webBinding" maxReceivedMessageSize="2147483647">
<security mode="Transport">
</security>
</binding>
</webHttpBinding>
</bindings>
I was able to resolve this by creating/modifying the binding for my service in SharePoint. I did this by executing the following powershell script:
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
$contentService.ClientRequestServiceSettings.MaxReceivedMessageSize = -1
$wcfServiceSettings = New-Object Microsoft.SharePoint.Administration.SPWcfServiceSettings
$wcfServiceSettings.ReaderQuotasMaxStringContentLength = 2147483647
$wcfServiceSettings.ReaderQuotasMaxArrayLength = 2147483647
$wcfServiceSettings.ReaderQuotasMaxBytesPerRead = 2147483647
$wcfServiceSettings.MaxReceivedMessageSize = 2147483647
$wcfServiceSettings.MaxBufferSize = 2147483647
$wcfServiceSettings.ReaderQuotasMaxDepth = 2147483647
$wcfServiceSettings.ReaderQuotasMaxNameTableCharCount = 2147483647
$contentService.WcfServiceSettings["<my service name>.svc"] = $wcfServiceSettings
$contentService.Update($true)
This effectively did as suggested by the original responder. But it fixed the problem for the special case scenario where the web service is part of a SP application.
There's more configurations that must be set, try to set this:
<system.web>
<httpRuntime maxRequestLength="2147483647" />
</system.web>
And add this to your binding:
<webHttpBinding>
<binding name="webBinding" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" maxBufferSize="2147483647">
<readerQuotas maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" />
<security mode="Transport"></security>
</binding>
</webHttpBinding>
SylverSmyth's soultion worked for me.
Without creating Service Factory.
Only one note: name of a service in ["<my service name>.svc"] should be in lowercase.

WCF Service Error 413 Entity Too Large

Need some insight on where to look further related to a WCF error I am getting about the Request Entity Too Large (Error 413).
Pretty much, the service is a simple [OperationContract] accepting a string as a parameter.
<IService.cs>
[OperationContract]
string UploadReportText(string ReportText);
<Service.cs>
public string UploadReportText(string ReportText)
{
// Code to process data passed.
}
I've already set the web config for the service as follows:
<bindings>
<webHttpBinding>
<binding maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</binding>
</webHttpBinding>
</bindings>
Although I believe the uploadReadAhead value in IIS needs not be touched (as I am not using SSL), I still modified it to have a value of 2147483647.
Tracing one of the apps that call the service in Chrome, I can see that the data Content-Length is 169786.
Really stumped where to look further related to this.
Appreciate any insight. Thanks
Update:
Additional Info
If I set the string data being passed to the service to a smaller length, I am not getting an error. Most of the search I did related to this all points to the maxReceivedMessageSize needs to be adjusted to the maximum possible value, but setting it in the web config seems to have no effect.
Update:
Enabled logging and I got this message:
Exception details: System.ServiceModel.ProtocolException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.
First of all: on your server side, you define the binding configuration with larger message size, but you don't reference it from your endpoint.
<service behaviorConfiguration="WCFReferrals.Service1Behavior"
name="WCFReferrals.Referrals">
<endpoint
address=""
binding="wsHttpBinding"
bindingConfiguration="LargeSizeMessages" <== you need to reference the binding config (by specifying its name
contract="WCFReferrals.IReferrals">
</endpoint>
.....
</service>
....
<binding name="LargeSizeMessages" <== give it a meaningful name
maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="32" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
</binding>
Source
Refer this too
Also need to do the same thing on your client-side as well. Does your client-side config (app.config also include that large message size binding configuration.
As Vignesh said, you don't have a name assigned to your defined binding. This makes it the default configuration for that binding (in WCF 4.0+ later), so you actually have two choices. You can give it a name, create an explicit endpoint and reference it via the bindingCongifuration, per Vignesh's suggestion.
Or, you can use the <proctolMapping> part of the <system.serviceModel> section to assign the webHttpBinding as the default binding for http (the normal WCF default binding for http is basicHttpBinding:
<system.serviceModel>
<protocolMapping>
<add binding="webHttpBinding" scheme="http" />
</protocoalMapping>
</system.serviceModel>
This goes in your service's config file.
For me, I just needed to add this chunk to my web.config:
<bindings>
<webHttpBinding>
<binding maxReceivedMessageSize="2147483647"
maxBufferPoolSize="2147483647777" >
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</binding>
</webHttpBinding>
</bindings>
My web.config was already using the webHttpBinding binding (as shown below), it just needed this <bindings> section to allow it to upload large files.
<services>
<service name="PocketCRMServices.Service1">
<endpoint address="../Service1.svc"
binding="webHttpBinding"
contract="PocketCRMServices.IService1"
behaviorConfiguration="webBehaviour" />
</service>
</services>

BasicHttpBinding fails when sharing endpoint with WsHttpBinding - The server certificate is not provided

I have a WCF service endpoint that uses WsHttpBinding and BasicHttpBinding with different addresses to allow them to share the endpoint. There is no security on the BasicHttpBinding. The BasicHttpBinding works fine when my service and client are on the same machine. When they are on different machines the BasicHttpBinding fails and I get this error in the service's trace log: The service certificate is not provided. Specify a service certificate in ServiceCredentials.
The error stops happening if I remove the WsHttpBinding from the service's config.
Service's web.config:
<bindings>
<basicHttpBinding>
<binding name="MyBasicBinding"
maxBufferPoolSize="5242880"
maxReceivedMessageSize="5242880" />
</basicHttpBinding>
<wsHttpBinding>
<binding name="MyWsBinding"
bypassProxyOnLocal="false"
hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="5242880"
maxReceivedMessageSize="5242880"
allowCookies="false">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="Message">
<message clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<services>
<service name="MyService">
<endpoint address="basic" binding="basicHttpBinding" bindingConfiguration="MyBasicBinding"
contract="MyFramework.IMyService" bindingNamespace="http://MyFramework/Services/"/>
<!-- The basic binding fails when the WS binding is present.
If I remove the WS binding, the basic binding will work. -->
<endpoint address="" binding="wsHttpBinding" bindingConfiguration="MyWsBinding"
contract="MyFramework.IMyService" bindingNamespace="http://MyFramework/Services/"/>
</service>
</services>
FYI I'm using a different address for the basic binding which allows the 2 bindings to share the same endpoint. The URL for WsHttpBinding is http://server/MyService.svc and for BasicHttpBinding is http://server/MyService.svc/basic.
Why does the presence of the WsHttpBinding force the BasicHttpBinding to expect a certificate?
When the service goes up it needs to ensure all endpoints are valid. Since one of the endpoints (The WSHttp one) uses certificate authentication, the server will not go up if this certificate is not defined. So the error is not related to the BasicHttp. That still does not explain why everything works if on the same machine, check if the exact same configuration is used.

How to consume multiple binding WCF Service method without mentioning the endpoint name

Currently I’m using BaciHttpBinding and WsHttpBindin for same Service. Before introduce the BasicHttpBing, My Client Windows app consuming the WsHttpBindin, so i didn't mention the endpoint name. After introduce the BasicHttpBinding i need to mension the Name of the endpoint in my client when it going to consume the Desired Service. My problem is, I have to change all the existing code with endpoint name. How can i overcome this situation or is there any method which i can set the default binding in config level and it'll use when i didn't supply the endpoint name.
You can not define multiple endpoints on same address, assign two different address for both the bindings.
You can leave the address blank in case of contracts and it will automatically points to the address of mex endpoint, which is being used for defining your metadata.
Similarly you can BindingConfiguration tag to configure the bindings.
Do something like this, i am using binding configuration and transmode is streamed and using this binding configuration in my endpoints
<binding name="StreamBinding" closeTimeout="00:59:00" openTimeout="00:10:00"
sendTimeout="00:10:00" maxBufferPoolSize="700000000" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647" transferMode="Streamed">
<readerQuotas maxStringContentLength="2147483647" maxArrayLength="1000" />
<reliableSession inactivityTimeout="02:00:00" />
<security mode="None"></security> </binding>
<endpoint address="" binding="netTcpBinding" bindingConfiguration="StreamBinding"
bindingName="" contract="DBSInterface.Common.IFileTransfer">
<identity>
<dns value="localhost" />
</identity>
</endpoint>

How can I bypass Operation Contract limitation of a WCF Service when calling "Update Service Reference" in VS 2008

I am having trouble with a single Wcf Service that we have in an application. It has about 150 [OperactionContract] within it. I can now no longer Update Service Reference within Visual Studio 2008.
I receive all kinds of strange errors, varying from "Socket Forcibly Closed" to "Invalid Type" and other strange messages when I try to call an update. If I comment out 10-20 operations it works fine.
I have read all kinds of posts here, on MSDN, and many blogs. They all point to binding configurations that need to be changed, either on the main binding or on the MetadataExchange binding.
My problem is that I have tried all of this and have yet to get it to work reliably.
I am self hosting the service in an application, and that same application is also the client. They share the same configuration file (currently) because we are in the process of breaking the application into 2 pieces via the Wcf service layer.
Here is an excerpt showing my bindings I have defined:
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="NetTcpBinding_IRhinoServices"
closeTimeout="00:05:00"
openTimeout="00:05:00"
receiveTimeout="00:15:00"
sendTimeout="00:05:00"
transactionFlow="false"
transferMode="Buffered"
transactionProtocol="OleTransactions"
hostNameComparisonMode="StrongWildcard"
listenBacklog="100"
maxBufferPoolSize="2147483647"
maxBufferSize="2147483647"
maxConnections="100"
maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
<reliableSession ordered="true"
inactivityTimeout="00:10:00"
enabled="false" />
<security mode="None">
</security>
</binding>
</netTcpBinding>
<customBinding>
<binding name="customMex">
<textMessageEncoding>
<readerQuotas maxDepth="2147483647"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</textMessageEncoding>
<tcpTransport transferMode="Buffered"
maxReceivedMessageSize="2147483647"
maxBufferSize="2147483647"/>
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="net.tcp://localhost:8523/RhinoServices"
binding="netTcpBinding"
bindingConfiguration="NetTcpBinding_IRhinoServices"
contract="RhinoServicesReference.IRhinoServices"
name="NetTcpBinding_IRhinoServices">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
<services>
<service behaviorConfiguration="CounterSketchServer.RhinoServicesBehavior"
name="CounterSketchServer.RhinoServices">
<endpoint address=""
binding="netTcpBinding"
contract="CounterSketchServer.IRhinoServices">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex"
binding="customBinding"
contract="IMetadataExchange"
name=""
bindingConfiguration="customMex"
listenUriMode="Explicit" />
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:8523/RhinoServices" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="CounterSketchServer.RhinoServicesBehavior">
<serviceMetadata httpGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
I need to be able to generate the proxy class by clicking on Update Service Reference, which has worked well this past 2 weeks, till I hit this mysterious limit.
Most of the examples I have seen to resolve this talk about http bindings for mex, but I would like to stick with just netTcp if possible since I am self hosting.
Can anyone please help me?
Thank you.
* UPDATE *
I have tried #Aliostad suggestion, and it appeared to work well at first. Until I tried some of our Wcf calls which update UI elements. These happened to work when using NetTCP bindings with the Proxy Class generated by Visual Studios (Add Service Reference) tool. But when using the Channel Factory it does not work.
I have tried looking at the SyncrhonizationContext in Juval's WCF book, but nothing I did seemed to work.
I have tried using both Named Pipes and NetTCP as the binding for the Channel I create using the ChannelFactory, and they do seem to behave very differently from eachother related to long running Wcf operations, but neither work to update UI elements.
My services are actually running in a plugin for the Rhino 3D CAD engine, and ceratin calls (Render, etc.) trigger UI in Rhino to update. I assume this is causing a thread boundary issue. The exception I receive is:
attempted to read or write protected memory
If anyone has any suggestions to use the ChannelFactory method effectively in this scenario or to fix my problem with too many Operations in a given Wcf class to generate the Service Proxy I would appreciate your help.
Thank You!
First of all, I believe the only solution is to remove the reference, and add it back again.
Alternatively, if you own both the Client and the Service - which I seem to get from reading your question that you do - may I strongly suggest that you share you service interfaces with your clients - instead of using a service reference?
This is definitely the preferred approach when you own both client and the server (and will save you from all the troubles you are having) and I believe it is also preferred if you do not own the client, you just share the entities/dtos and the interfaces.
This requires you to:
Create a class library project for you entities/dtos. Share it with the client.
Create a class library project for you service interfaces. Share it with the client.
Create a class library project for you service implementation. Stays only on the server.
The client uses ChannelFactory<T> to create factory and then create a proxy by calling CreateChannel()
I have got the Update Service Reference working again from both SvcUtil.exe and from Visual Studio 2008.
To do so I added the following section to the config files for both devenv.exe.config and SvcUtil.exe.config:
<!-- CUSTOM MetaDataExchaning Binding to all for LARGE WCF Services -->
<client>
<endpoint name="net.tcp" binding="netTcpBinding" bindingConfiguration="GenericBinding"
contract="IMetadataExchange" />
<endpoint name="http" binding="wsHttpBinding" bindingConfiguration="SecureBinding" contract="IMetadataExchange" />
</client>
<bindings>
<netTcpBinding>
<binding name="GenericBinding" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647" >
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
<security mode="None"/>
</binding>
</netTcpBinding>
<wsHttpBinding>
<binding name="SecureBinding" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647" >
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
<security mode="Message">
<transport clientCredentialType="Windows" />
</security>
</binding>
</wsHttpBinding>
</bindings>
Then in my application Server plugin, I am still programmatically creating the ServiceHost so to enable meta data exchange I added another endpoint:
// DATA ENDPOINT
NetTcpBinding binding = new NetTcpBinding(SecurityMode.Transport, true);
Uri baseAddress = new Uri("net.tcp://localhost:8555/RhinoServices");
_rhinoServicesHost = new ServiceHost(typeof(RhinoServices), baseAddress);
_rhinoServicesHost.AddServiceEndpoint(typeof(IRhinoServices), binding, baseAddress);
// META ENDPOINT
BindingElement bindingElement = new TcpTransportBindingElement();
CustomBinding customBinding = new CustomBinding(bindingElement);
ServiceMetadataBehavior metadataBehavior = _rhinoServicesHost.Description.Behaviors.Find<ServiceMetadataBehavior>();
if (metadataBehavior == null)
{
metadataBehavior = new ServiceMetadataBehavior();
_rhinoServicesHost.Description.Behaviors.Add(metadataBehavior);
}
_rhinoServicesHost.AddServiceEndpoint(typeof(IMetadataExchange), customBinding, "MEX");
_rhinoServicesHost.Faulted += RhinoServicesHost_Faulted;
_rhinoServicesHost.Open();
I can now update the references regardless of the number of contracts.
I have to admit though, during this whole process the Attempted to read or write protected memory error that cropped up hasn't gone away since I switched back to this method.
So I guess I have to still track that down...
Also I found this solution on a different question (click to view), answered by #trendl. Thank you for your help.