Ich habe IErrorHandler implementiert, um Autorisierungsausnahmen zu behandeln, die im Konstruktor meines WCF-Diensts ausgelöst wurden. Wenn eine allgemeine Ausnahme abgefangen wird, wird mein benutzerdefinierter Typ wie erwartet zurückgegeben, aber der ContentType-Header ist falsch.
%Vor%Wenn der Fehlerhandler jedoch versucht, einen 401 Unauthorized http-Statuscode zurückzugeben, wird der Nachrichtentext auf den Standardtyp überschrieben, aber der ContentType-Header ist so, wie er sein sollte.
%Vor%Offensichtlich stimmt hier etwas nicht, aber ich bin mir nicht sicher was.
Wie implementiere ich IErrorHandler so, dass es meinen benutzerdefinierten Typ in json mit den richtigen Headern zurückgibt?
BaseDataResponseContract-Objekt:
%Vor%Dies ist das Objekt, das ich zurückgeben möchte. Alle anderen Objekte in meiner Anwendung erben von diesem Objekt. Wenn eine Ausnahme ausgelöst wird, interessiert uns nur der HTTP-Statuscode und die Fehlermeldung.
IErrorHandler-Implementierung (die Protokollierung wird der Kürze halber nicht gezeigt):
%Vor%IServiceBehavior Implementierung:
%Vor%Web.Config:
%Vor%Schließlich sehe ich ein ähnliches Verhalten bei der Verwendung von WebFaultException. Mein Gedanke ist, dass dies das Ergebnis einiger tief vergrabener .Net-Spielereien ist. Ich wähle die Implementierung von IErrorHandler, damit ich weitere Ausnahmen erfassen kann, die möglicherweise nicht behandelt werden.
Referenz:
Andere Beispiele:
IErrorHandler scheint nicht um meine Fehler in WCF zu behandeln .. irgendwelche Ideen?
Wie setzen Sie den Content-Type-Header für eine HttpClient-Anfrage?
Nachdem ich fast einen ganzen Tag damit zu kämpfen hatte, stellte ich fest, dass dies auf eine IIS-Einstellung zurückzuführen war.
Unter meinem API-Projekt in IIS hatte ich im Menü "Authentifizierung" die Option "Formularauthentifizierung" auf "Aktiviert" gesetzt. Ich habe diese Funktion deaktiviert und der obige Code hat wie erwartet funktioniert. Ich habe festgestellt, dass dies auf einen anderen Entwickler in meinem Team zurückzuführen ist, der Code in die Datei web.config geschrieben hat, die die Einstellungen in IIS geändert hat. Speziell:
%Vor%Außerdem konnte ich die Content-Type-Kopfzeile korrekt anzeigen, indem ich die ContentType-Eigenschaft für das WebOperationContext OutgoingResponse-Objekt verwendete.
%Vor%Ich bin mir nicht sicher, wie Ihre Anwendung implementiert ist. Basierend auf Ihrer Beschreibung, schlage ich vor, Visual Studio zu verwenden, um Ihren ErrorHandler zu debuggen, um zu sehen, ob die Ausnahme Ihren Rückruf erreicht.
Wenn ja, konstruieren Sie Ihre Soap-Fehler oder -Antworten manuell so, wie Sie möchten.
Wenn dies nicht der Fall ist, bedeutet dies, dass die Ausnahmebedingung vor dem Eintreffen des Dienstvorgangs auftritt. Dies kann bereits im Kanalstapel fehlschlagen. In diesem Fall besteht ein einfacher Ansatz darin, ein zusätzliches HttpModule hinzuzufügen oder die Antwort zuzuordnen. Oder Sie können den Encoder im Channel-Stack anpassen.
Basierend auf dem, was Sie schreiben, werfen Sie eine Exception in den Konstruktor der Service-Implementierung. Da WCF die Reflektion zum Erstellen Ihrer Dienstimplementierung verwendet, erhalten Sie eine TargetInvocationException, sofern Ihr Dienst nicht Singleton ist.
Beispiel (LINQPad verwenden):
%Vor%Vermeiden Sie grundsätzlich das Auslösen von Ausnahmen basierend auf Geschäftslogik in einem Konstruktor. Tun Sie das nur für die Behandlung von Programmierfehlern.
Tags und Links wcf c# json ierrorhandler