To jedno z tych „pytań” SO, na które już odpowiedziałem, ale piszę b / c, wydaje się, że jest tam prawie zero informacji na podstawie tygodnia Google.

TL; DR: BasicHttpBinding klienta BasicHttpBinding zakodowany przez WCF z zewnętrzną / trzecią częścią, dławiki usług internetowych innych niż. .. i nie udaje się deserializować SOAP / XML do obiektu wykonawczego, powodując błąd w tytule tego pytania.

Błąd: oczekiwano elementu końcowego „MyBinaryData” z przestrzeni nazw „http://mynamespace”. Znaleziono element „xop:Include” z przestrzeni nazw „http://www.w3.org/2004 /08/xop/'

Jak wcześniej wspomniano, niewiele jest tam na ten temat, zgaduję, że b / c MS napisało większość swojej dokumentacji WCF w oparciu o rozwój usług, a nie tak dużo klienta (chociaż jest trochę, żeby być uczciwym).

Nie zamierzam przechodzić do podstawowej konfiguracji początkowej b / c Mam zamiar odpowiedzieć na własne pytanie, ale poprzedzę odpowiedź, mówiąc, że było to znacznie bardziej zbliżone do domyślnej konfiguracji WCF MTOM niż nie.

Wiem też, że WCF jest stary, nudny i nie jest już aktywnie rozwijany przez MS, ale nadal jest obsługiwany i ma wiele zastosowań. Właściwie nie miałem wielkiego wyboru i musiałem znaleźć sposób, aby to zadziałało. Dlatego dzielę się swoimi odkryciami z każdym, kto ma do czynienia z tego rodzaju bólem głowy.

1
isandburn 20 listopad 2019, 23:07

1 odpowiedź

TL; DR: sprawdź nagłówki http, aby zobaczyć, czy odpowiedź usługi to „Transfer-Encoding: chunked” (przesyłana strumieniowo), a jeśli tak, użyj transferuMode = „StreamedResponse” w konfiguracji powiązania.

Więc po Googlingu przez kilka dni bez pomocy, włączyłem Fiddlera do przechwytywania ruchu http – wymaga to podstawowej konfiguracji wiązania http WCF do serwera proxy w Fiddler (http://localhost:8888 domyślnie, jak sądzę) iw zależności od tego, gdzie znajduje się twoja usługa docelowa, możesz lub nie musisz konfigurować ustawień Fiddler's Gateway (firmowy serwer proxy itp.).

Pozwoliło mi to zobaczyć nieprzetworzony tekst przesyłany między moim klientem do / z jego usługi; wszystkie ładunki przychodziły w porządku, co w moim przypadku oznaczało, że odpowiedź MTOM / XOP z usługi była całkowicie przesyłana, a środowisko uruchomieniowe WCF nie interpretowało poprawnie odpowiedzi. Inną krytyczną rzeczą, jaką zobaczyłem, było to, że nagłówek HTTP Transfer-Encoding był „porcjowany” i nie było nagłówka Content-Length… oznaczało to, że usługa przesyłała strumieniowo odpowiedź, w przeciwieństwie do odpowiedzi buforowanej. A teraz mała uwaga dodatkowa: dokumentacja MS WCF MTOM zawiera wzmiankę mówiącą, że powinieneś zawsze używać "Buffered" jako swojego transferuMode w konfiguracji powiązań ... ale nie wspomniałem, że tak naprawdę ma zastosowanie tylko w usługach, niekoniecznie w klientach!

Więc naturalnie po prostu wszedłem do mojego pliku konfiguracyjnego, znalazłem kolekcję system.serviceModel >> bindings >> basicHttpBinding, znalazłem moją specyficzną konfigurację wiązania i ustawiłem transferMode = "StreamedResponse" (ponieważ usługa innej firmy przesyłała strumieniowo moją odpowiedź z powrotem do mojego klienta ).

1
isandburn 20 listopad 2019, 23:07