WCF Obtenir « La signature primaire doit être crypté. » De FaultContract avec ProtectionLevel.None

Question

J'ai une application asp.net existante qui parle de charger les services WCF équilibrés (iis hébergé, dans la piscine d'applications en cours d'exécution sous le compte configuré comme servicePrincipalName, etc.). Les services WCF reviennent quelques défauts personnalisés, tous définis avec FaultContract (typeof (x), ProtectionLevel = ProtectionLevel.None) - ces services ne sont pas exposés au public. Le client utilise les classes générées 'de référence de service' pour accéder aux services.

Cela a bien fonctionné, mais maintenant, avec la dernière base de code, nous obtenons « La signature primaire doit être crypté. » exceptions sur le client lorsque le service retourne un de ces défauts. Le code de service et la configuration sont inchangées (au moins les parties traditionnelles qui génèrent des défauts). La référence de service côté client code généré apparaît le plus changé (il se retrouve souvent supprimés et recréés).

La configuration de sécurité est inchangé depuis plus d'un an. Toutes les mises à jour sont assez courant. Nous avons testé cela dans trois environnements et dès que nous déployons la nouvelle base de code, les défauts commencent à générer des exceptions. On dirait que ce doit être dans les classes générées, mais ils sont générés par Visual Studio il est donc très perplexe.

Est-ce son familier à tout le monde? Toutes les suggestions?

Mise à jour: Suppression de l'attribut ProtectionLevel et permettant à un défaut rend le problème « aller loin », mais je suis curieux de savoir pourquoi la spécification Aucun fait échouer. Peut-être en conflit avec le niveau par défaut du contrat d'exploitation ou d'un contrat de service, mais ces valeurs ont pas changé au cours de la dernière année afin que n'explique pas pourquoi ce qui avait fonctionné fait maintenant pas.

Mise à jour. Pour ce qu'il vaut, ce changement dans le code général passé entre 2.0.50727.3053 et 2.0.50727.3082 (selon le commentaire runtime-version dans le code généré)

Answer 1

Je ne l'ai pas connu ce problème moi-même, mais mon questionn est: pourquoi diable ne vous spécifiez un « ProtectionLevel = Aucun » dans votre contrat de faute? Une raison particulière pour cela?

Sinon, je vous recommande fortement de ne pas préciser que tout - la valeur par défaut est ProtectionLevel = EncryptAndSign et qui est habituellement votre meilleur pari tout autour. Essayez-le, sauf si vous avez une raison très forte et explicite contre.

Marc