MaxReceivedMessageSize kann nicht über web.config festgelegt werden

7

Ich habe jetzt den 400 - BadRequest Code für die letzten zwei Stunden untersucht. Es gibt viele Hinweise darauf, dass das bindingConfiguration-Attribut richtig eingestellt ist, und in meinem Fall ist es das.

Nun, ich brauche deine Hilfe, bevor ich das Gebäude zerstöre, in dem ich mich befinde: -)

Ich führe einen WCF RestFull-Dienst aus (sehr leicht, mit dieser Ressource zur Inspiration: Ссылка ) ) das (vorerst) ein XmlElement (POX) akzeptiert, das über das POST-Verb bereitgestellt wird.

Ich benutze NUR den Request Builder von Fiddler, bevor ich einen echten Client implementiere (da dies gemischte Umgebungen sind).

Wenn ich dies für XML kleiner als 65K tue, funktioniert es gut - größer, es löst diese Ausnahme aus: 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.

Hier ist meine Datei web.config (zu der ich sogar den Client-Tag für (verzweifelte Zeiten!) hinzugefügt habe:

%Vor%

Vielen Dank im Voraus für jede Hilfe, die zu einem erfolgreichen Aufruf mit & gt; 65K XML führt; -)

    
Michael Mortensen 17.09.2009, 16:37
quelle

4 Antworten

12

Alles in allem hat mir dieser eine wirklich schwierige Zeit bereitet, die ich anderen ersparen werde. Die Herausforderung bestand darin, dass ich das <%@ ServiceHost Factory="System.ServiceModel.Activation.WebServiceHostFactory" Service="fullyQualifiedClassName" %> verwendet habe, was ein netter und einfacher Factory-Implementierungsansatz ist.

Dieser Ansatz hat jedoch Nachteile; Da in der Datei "web.config" keine Konfiguration erforderlich ist, liest die WebServiceHostFactory-Klasse nach Entwurf aus der Datei "web.config" nicht. Ich kenne; Ich könnte von dieser Klasse erben und die entsprechenden Änderungen vornehmen, damit sie tatsächlich aus der Konfigurationsdatei lesen kann, aber das schien etwas außerhalb des Geltungsbereichs zu liegen.

Meine Lösung war, zu der traditionelleren Art der Implementierung der WCF zurückzukehren; <%@ ServiceHost Service="fullyQualifiedClassName" CodeBehind="~/App_Code/Catalogue.cs" %> , und verwende dann meine bereits konfigurierten Werte in der Datei web.config.

Hier ist meine modifizierte web.config-Datei (in Bezug auf Maddox Kopfschmerzen):

%Vor%

Ein weiterer Vorteil dieser Änderung ist, dass Sie jetzt direkt von .NET auf Ihren WCF-Rest-Service verweisen können; Dies kann nicht mithilfe des Factory-Modells und meiner Implementierung von XmlElement durch die Lösung erfolgen.

Ich hoffe, dass dies anderen mit ähnlichen Problemen helfen kann ...

    
Michael Mortensen 18.09.2009, 14:22
quelle
6

Ich weiß, das ist eine sehr alte Frage und es hat bereits eine Antwort ...

Wie auch immer ...

Was ich getan habe, um dieses "Problem" zu lösen Ich habe eine Factory erstellt, die von WebServiceHostFactory geerbt wurde, und einen benutzerdefinierten Service-Host erstellt, der von WebServiceHost geerbt wurde

Und im Host überschreibe ich die OnOpening-Methode wie folgt

%Vor%     
jjchiw 19.01.2012 12:01
quelle
6

Ich denke, ich hatte das gleiche Problem, aber als ich die Standard-Bindung für webHttp konfiguriert habe, hat es funktioniert:

%Vor%

Beachten Sie: Kein Name auf der Bindung.

    
Goff 04.10.2012 08:36
quelle
0

Dies ist ein Blog-Eintrag, den ich geschrieben habe, der dieses Problem mit einem absolut minimalen WCF-Server und Client-Stück reproduziert:

WCF - Behebung von clientseitigen Stringlängen-Ausnahmen

Insbesondere benötigen Sie möglicherweise eine benutzerdefinierte Bindungskonfiguration. Wenn Sie dieses Beispiel zumindest reproduzieren, können Sie einige Ideen für Ihre spezielle Situation erhalten.

    
Michael Maddox 17.09.2009 17:56
quelle