OperationContext.Current es nulo después de aguardar cuando se utiliza async/await en el servicio WCF

Question

Estoy usando el patrón async/await en .NET 4.5 para implementar algunos métodos de servicio en WCF. Servicio Ejemplo:

Contrato:

[ServiceContract(Namespace = "http://async.test/")] 
public interface IAsyncTest 
{ 
    Task DoSomethingAsync(); 
} 

Implementación:

MyAsyncService : IAsyncTest 
{ 
    public async Task DoSomethingAsync() 
    { 
     var context = OperationContext.Current; // context is present 

     await Task.Delay(10); 

     context = OperationContext.Current; // context is null 
    } 
} 

El problema que estoy teniendo es que después de las primeras declaraciones de awaitOperationContext.Currentnull y no puedo acceder OperationContext.Current.IncomingMessageHeaders.

En este sencillo ejemplo esto no es un problema ya que puedo capturar el contexto antes del await. Pero en el mundo real se está accediendo al caso OperationContext.Current desde el interior de la pila de llamadas y realmente no quiero cambiar muchos códigos solo para pasar el contexto más allá.

¿Hay alguna forma de obtener el contexto de operación después del punto await sin pasarlo por la pila manualmente?

Answer 1

Creo que su mejor opción es capturarlo y pasarlo manualmente. Puede encontrar que esto mejora la capacidad de prueba de su código.

Dicho esto, hay un par de otras opciones:

1. Añadir al LogicalCallContext.
2. Instale su propio SynchronizationContext que establecerá OperationContext.Current cuando haga un Post; así es como ASP.NET preserva su HttpContext.Current.
3. Instale su propio TaskScheduler que establece OperationContext.Current.

Es posible que también desee plantear este problema en Microsoft Connect.

Answer 2

Desafortunadamente, esto no funciona y veremos cómo solucionarlo en una versión futura.

Por el momento, no existe una manera de volver a aplicar el contexto de la rosca actual, de modo que usted no tiene que pasar el objeto en torno a:

public async Task<double> Add(double n1, double n2) 
    { 

     OperationContext ctx = OperationContext.Current; 

     await Task.Delay(100); 

     using (new OperationContextScope(ctx)) 
     { 
      DoSomethingElse(); 
     } 
     return n1 + n2; 
    } 

En el ejemplo anterior, el DoSomethingElse () El método tendrá acceso a OperationContext.Current como se esperaba.

Answer 3

Afortunadamente para nosotros, nuestra implementación del servicio real se instancia a través del contenedor IoC Unity. Eso nos permitió crear un IWcfOperationContext que fue configurado para tener un PerResolveLifetimeManager que simplemente significa que habrá solo una instancia de WcfOperationContext para cada instancia de nuestro RealService.
En el constructor de WcfOperationContext capturamos OperationContext.Current y luego todos los lugares que lo requieren lo obtienen de IWcfOperationContext. Esto es lo que Stephen Cleary sugirió en su respuesta.

Answer 4

Aquí está un ejemplo de implementación SynchronizationContext:

public class OperationContextSynchronizationContext : SynchronizationContext 
{ 
    private readonly OperationContext context; 

    public OperationContextSynchronizationContext(IClientChannel channel) : this(new OperationContext(channel)) { } 

    public OperationContextSynchronizationContext(OperationContext context) 
    { 
     OperationContext.Current = context; 
     this.context = context; 
    } 

    public override void Post(SendOrPostCallback d, object state) 
    { 
     OperationContext.Current = context; 
     d(state); 
    } 
} 

y uso:

var currentSynchronizationContext = SynchronizationContext.Current; 
try 
{ 
    SynchronizationContext.SetSynchronizationContext(new OperationContextSynchronizationContext(client.InnerChannel)); 
    var response = await client.RequestAsync(); 
    // safe to use OperationContext.Current here 
} 
finally 
{ 
    SynchronizationContext.SetSynchronizationContext(currentSynchronizationContext); 
} 

Answer 5

Ampliando la opción # 1 del Sr. Cleary, el siguiente código se puede colocar en el constructor del servicio WCF para almacenar y recuperar el OperationContext en el contexto de llamada lógica:

if (CallContext.LogicalGetData("WcfOperationContext") == null) 
{ 
    CallContext.LogicalSetData("WcfOperationContext", OperationContext.Current); 
} 
else if (OperationContext.Current == null) 
{ 
    OperationContext.Current = (OperationContext)CallContext.LogicalGetData("WcfOperationContext"); 
} 

Con eso, en cualquier lugar que está teniendo problemas con un contexto nulo se puede escribir algo como lo siguiente:

var cachedOperationContext = CallContext.LogicalGetData("WcfOperationContext") as OperationContext; 
var user = cachedOperationContext != null ? cachedOperationContext.ServiceSecurityContext.WindowsIdentity.Name : "No User Info Available"; 

responsabilidad: Este es el código de años de edad y no recuerdo la razón por la que necesitaba el else if en el constructor, pero tenía algo que ver con la asincronización y sé que era necesario en mi caso.

Answer 6

Actualización: Como se señala en los comentarios a continuación, esta solución no es segura para subprocesos, por lo que supongo que las soluciones discutidas anteriormente siguen siendo la mejor manera.

Me muevo por el problema registrando el HttpContext en mi contenedor DI (Application_BeginRequest) y lo resuelvo cuando lo necesito.

Registro:

this.UnityContainer.RegisterInstance<HttpContextBase>(new HttpContextWrapper(HttpContext.Current)); 

Resolve:

var context = Dependencies.ResolveInstance<HttpContextBase>(); 

Answer 7

Parece ser fijado en .Net 4.6.2. Ver the announcement