Je suis en train de migrer mon service de reatteuse WCF de .NET 3.5 (Kit de démarrage) à .NET 4. J'ai commencé mon projet à l'aide d'un modèle de service de repos de WCF à partir de Visual Studio 2010. Je devais comprendre comment conserver mon schéma d'autorisation (formelement avec demandeInterceptor) à l'aide de ServiceAuthorizationManager. Après un travail et une recherche, je l'ai fait. Mais maintenant j'ai un problème de garantie. Mon service utilisé pour rétablir mon client de toutes les erreurs de traitement à l'aide du code d'état HTTP et une brève description. J'utilisais weboPerationContext à de nombreux points de ma méthode de service pour décrire aux clients ce qui s'est mal passé, comme celui-ci:
private void GenerateBadDigestMessage(ref OperationContext operationContext)
{
Message reply = Message.CreateMessage(MessageVersion.None, null, null, new DataContractJsonSerializer(typeof(object)));
HttpResponseMessageProperty hrp = new HttpResponseMessageProperty();
hrp.StatusCode = HttpStatusCode.Forbidden;
hrp.StatusDescription = "bad digest";
reply.Properties[HttpResponseMessageProperty.Name] = hrp;
operationContext.RequestContext.Reply(reply);
operationContext.RequestContext = null;
}
4 Réponses :
Je vous recommande d'utiliser webfaultexception in .NET 4.0. Lisez par exemple " Présentation des services wcf Webhttp dans .NET 4 ". Essayez
Désolé mais utiliser .NET 4.0 n'est pas une option. Toute chance avec .net 3.5?
@HEMANT: Désolé de mal comprendre, mais vous commencez votre question avec le mot, que vous migrez actuellement votre service de .NET 3.5 (Kit de démarrage) à .NET 4 et vous avez des problèmes. Je vous comprends donc que vous avez déjà une solution de travail dans .NET 3.5 et vous voulez qu'il fonctionne dans .NET 4.0. J'ai eu le même problème. Dans .NET 3.5 J'ai utilisé WebProtocolException pour signaler les erreurs. Après la migration vers .NET 4.0, je décide NON UTILISER Kit de démarrage de la WCF de retenue de la WCF. .NET 4.0 dispose de toutes les fonctionnalités nécessaires au développement de la WCF. Au lieu de WebProtocolException J'utilise WebfaultException .
Merci pour votre réponse. Je n'ai pas demandé à l'origine de cette question. Je me battais juste avec le même problème et je voyais que ce qui précède déjà une question n'a pas de réponses, mettez une prime à ce sujet.
@Hemant: Je vois maintenant ça. Utilisez-vous l'aperçu 2 Kit de démarreur de WCF 2 sous Visual Studio 2008 ou 2010? Sous VS2008, je n'avais aucun problème avec l'utilisation de l'aperçu de Kit de démarreur de WCF 2 Inclusif Erreur Reporting avec respect de WebProtocolException . Je n'avais que la migration quelques problèmes à .NET 4.0 et Visual Studio 2010. Quel problème avez-vous?
Un problème potentiel est que vous définissez la demandeContext sur NULL:
WebOperationContext.Current.IncomingResponse.StatusDescription
OK! Voici ce que j'ai découvert. Il n'y a rien de mal avec mon code. Il n'y a rien de mal avec .NET Framework 3.5 ou 4.0.
Le problème est ASP.NET Development Server. Lorsque vous déboguez de votre demande de service, il est probable qu'il est hébergé sur ASP.NET Developer Server et ignore complètement la description de l'état donné par application. Référez cette question .
attribuer la prime à @Oleg qui a au moins essayé de m'aider.
Incidemment, c'est aussi la raison pour laquelle cela ne fonctionne pas dans l'API Web. J'ai trouvé votre réponse et dès que je dirige mon code sous IIS, la raisonShrase a changé la description du statut.
Assurez-vous de revenir de la méthode de service Null Object ... de sorte que la description du code d'état est visible dans les en-têtes de réponse, cela a fonctionné pour moi.
Auto-hébergé ou IIS? Quelle version du serveur? J'ai testé ceci sur 4.0 avec Server 2008R2 Auto-hébergé, et cela fonctionne bien (renvoie la description de l'état comme définie).
Avez-vous déjà trouvé une solution? Je suis confronté au même problème.