8

Actualmente estoy migrando mi WCF RESTful service de .NET 3.5 (Starter Kit) a .NET 4. Inicié mi proyecto utilizando una plantilla de servicio WCF Rest de Visual Studio 2010. Tuve que encontrar la manera de mantener mi esquema de autorización (que se acaba de hacer con RequestInterceptor) usando ServiceAuthorizationManager. Después de un poco de trabajo e investigación, lo hice. Pero ahora tengo un problema colateral. Mi servicio solía informar a mi cliente de cualquier error de procesamiento mediante el código de estado HTTP y una breve descripción. Yo estaba usando WebOperationContext en muchos puntos de mi método de servicio para describir a los clientes lo que salió mal, así:El servicio WCF 4 REST no puede devolver un StatusDescription, solo StatusCode

protected void returnCode(HttpStatusCode code, string description) 
{ 
    WebOperationContext ctx = WebOperationContext.Current; 
    ctx.OutgoingResponse.StatusDescription = description; 
    ctx.OutgoingResponse.StatusCode = code; 
} 

Pero en WCF 4, sólo se trabaja StatusCode - statusDescription error de forma silenciosa. No puedo entender por qué. Mi única suposición es que WebOperationContext no funciona en este nuevo escenario de WCF 4, y debería usar OperationContext en su lugar, pero eso tampoco funciona. El siguiente método se utiliza en mi clase personalizada que se extiende ServiceAuthorizationManager, informar a los clientes de una solicitud no pudo ser porque el acceso de autenticación digest era mal formado:

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; 
} 

Incluso utilizando OperationContext direclty de aquí (insted de WebOperationContext), statusDescription no lo hace trabajo.

¿Qué es lo que falta aquí? ¿Por qué una cosa tan pequeña puede romperse de .NET 3.5 a 4?

+0

¿Alojado automáticamente o IIS? ¿Qué versión de servidor? Probé esto en 4.0 con Server 2008R2 auto-alojado, y funciona bien (devuelve la Descripción del estado tal como está configurado). – nitzmahone

+0

¿Alguna vez encontró una solución? Estoy enfrentando el mismo problema. – Hemant

Respuesta

4

Te recomiendo que uses WebFaultException en .NET 4.0. Lea por ejemplo "Introducing WCF WebHttp Services in .NET 4". Trate

throw new WebFaultException<string> ("bad digest", HttpStatusCode.Forbidden); 
+0

Lo sentimos, pero usar .NET 4.0 no es una opción. ¿Alguna suerte con .NET 3.5? – Hemant

+0

@Hemant: lo siento por malentendido, pero comienza su pregunta con la palabra, que actualmente está migrando su servicio de .NET 3.5 (Starter Kit) a .NET 4 y tiene algunos problemas.Entonces lo entiendo, que ya tiene una solución de trabajo en .NET 3.5 y quiere que funcione en .NET 4.0. Yo tuve el mismo problema. En .NET 3.5 utilicé 'WebProtocolException' para reportar los errores. Después de la migración a .NET 4.0, decido ** no utilizar ** Kit de inicio REST WCF en desuso. .NET 4.0 tiene todas las características necesarias para el desarrollo WCF REST. En lugar de 'WebProtocolException' utilizo' WebFaultException'. – Oleg

+0

Gracias por responder. Originalmente no hice esta pregunta. Solo estaba luchando con el mismo problema y viendo que la pregunta anterior ya formulada no tiene respuestas, ponle una recompensa. – Hemant

1

Un problema potencial es que se está ajustando el RequestContext a nulo:

operationContext.RequestContext.Reply(reply);  
operationContext.RequestContext = null; 

Otra posibilidad es que el parámetro "Descripción" no se ha establecido.

También en el lado del cliente están comprobando que:

WebOperationContext.Current.IncomingResponse.StatusDescription 

una posibilidad más, podrían los valores se han sobrescrito después returnCode se llamaba?

2

OK! Esto es lo que descubrí. No hay nada malo con mi código. No hay nada de malo en .NET framework 3.5 o 4.0.

El problema es el servidor de desarrollo asp.net. Cuando está depurando su aplicación de servicio, es probable que esté alojada en el servidor de desarrollo asp.net e ignora por completo la descripción de estado dada por la aplicación. Refer this question.

Otorgando la recompensa a @Oleg que al menos trató de ayudarme.

+0

Por cierto, esta es también la razón por la que no funciona en Web Api. Encontré su respuesta y, tan pronto como ejecuté mi código en IIS, la frase ReasonPhrase cambió la descripción del estado. –

1

Asegúrese de regresar desde el objeto NULL del método de servicio ... para que la descripción del código de estado esté visible en los Encabezados de respuesta, funcionó para mí.

Cuestiones relacionadas