WCF Erste „Die primäre Signatur verschlüsselt werden müssen.“ Von FaultContract mit ProtectionLevel.None

Question

Ich habe eine asp.net Anwendung bestehender, die ausgewogenen WCF-Dienste laden spricht (iis in app-Pool gehostet, unter Konto läuft als service konfiguriert, etc.). Die WCF-Dienste zurückkehren ein paar individuelle Fehler, die alle mit FaultContract definiert (typeof (x), Protectionlevel = ProtectionLevel.None) - diese Dienste nicht der Öffentlichkeit ausgesetzt. Der Client verwendet die ‚Dienstverweis‘ generierten Klassen auf die Dienste zuzugreifen.

Das hat geklappt hat, aber jetzt, mit der neuesten Code-Basis, wir bekommen „Die primäre Signatur verschlüsselt werden muss.“ Ausnahmen auf dem Client, wenn der Dienst einer dieser Fehler zurückgibt. Der Service-Code und die Konfiguration unverändert ist (zumindest die Legacy-Teile, die die Fehler erzeugen). Der Client-Seite Dienstverweis generierte Code erscheint das geändert (es wird oft entfernt und neu erstellt).

Die Sicherheitskonfiguration ist seit über einem Jahr unverändert. Alle Updates sind ziemlich aktuell. Wir haben dies in drei Umgebungen getestet und sobald wir den neuen Code-Basis einsetzen, beginnen die Fehler Ausnahmen zu erzeugen. Scheint, wie es in den generierten Klassen sein muss, aber sie von Visual Studio generiert werden, so dass es sehr verwirrend ist.

Wer kennt das nicht zu anyone? Irgendwelche Vorschläge?

Update: Das Attribut Protection aus- und ermöglicht es macht das Problem ‚weggehen‘ auf Standard, aber ich bin neugierig, warum keine Angabe bewirkt, dass es zum Scheitern verurteilt. Vielleicht kollidiert es mit der Standard-Ebene des Betriebsvertrag oder Dienstleistungsvertrages, aber diese Werte nicht im vergangenen Jahr geändert, so dass nicht erklären, warum jetzt, was funktionierte nicht.

Update:. Für was es wert ist, diese Änderung im Code gen geschah zwischen 2.0.50727.3053 und 2.0.50727.3082 (entsprechend den Laufzeit-Version Kommentar im generierten Code)

Answer 1

Ich habe dieses Problem nicht selbst erlebt, aber meine questionn ist: Warum auf der Erde geben Sie eine „Protectionlevel = None“ in dem Fehler Vertrag? Ein besonderer Grund dafür?

Wenn nicht, würde ich empfehlen, dass überhaupt nicht spezifiziert - der Standard ist Protectionlevel = EncryptAndSign und das ist in der Regel die beste Wahl rundum. Versuchen Sie es, wenn Sie einen sehr starken und expliziten Grund dagegen haben.

Marc