J'ai une application asp.net existante qui parle de charger des services wcf équilibrés (iis hébergé, dans le pool d'applications fonctionnant sous un compte configuré comme servicePrincipalName, etc.). Les services wcf renvoient quelques fautes personnalisées, toutes définies 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 'référence de service' pour accéder aux services.WCF Obtention "La signature principale doit être cryptée." de FaultContract avec ProtectionLevel.None
Cela a bien fonctionné mais maintenant, avec la dernière base de code, nous obtenons "La signature principale doit être cryptée". exceptions sur le client lorsque le service renvoie l'un de ces défauts. Le code de service et la configuration sont inchangés (au moins les parties héritées qui génèrent les fautes). Le code généré par la référence de service côté client apparaît le plus modifié (il est souvent supprimé et recréé).
La configuration de sécurité est inchangée depuis plus d'un an. Toutes les mises à jour sont assez actuelles. Nous avons testé cela dans trois environnements et dès que nous déployons la nouvelle base de code, les erreurs commencent à générer des exceptions. On dirait que cela doit être dans les classes générées mais elles sont générées par Visual Studio donc c'est très perplexe.
Cela vous semble familier? Aucune suggestion?
Mise à jour: La suppression de l'attribut ProtectionLevel et son activation par défaut permettent de résoudre le problème, mais je suis curieux de savoir pourquoi la spécification de None entraîne l'échec. Peut-être que cela est en conflit avec le niveau par défaut du contrat d'exploitation ou du contrat de service, mais ces valeurs n'ont pas changé au cours de la dernière année, ce qui n'explique pas pourquoi ce qui fonctionnait maintenant ne l'est pas.
Mise à jour: Pour ce que cela vaut, ce changement de code gen s'est produit entre 2.0.50727.3053 et 2.0.50727.3082 (selon le commentaire de la version d'exécution dans le code généré).
C'est une bonne question. Cela a été fait il y a plus de deux ans en réponse à des problèmes avec des fautes personnalisées qui renvoyaient "Une faute non garantie ou incorrectement garantie a été reçue de l'autre partie". Définir le niveau de protection sur Aucun "fait fonctionner" à l'époque et en voyant comment c'était un service interne, l'idée de ne pas avoir les frais généraux semblait OK. Étant si nouveau à la WCF, et WCF étant si nouveau, et étant sous les délais, nous étions heureux que cela a fonctionné et a évolué ... puis oublié tout cela. – ongle