protegidas - operadores de acceso c#

El miembro privado repentinamente pierde la llamada al método API

Question

Cosas raras están sucediendo: en mi aplicación web, inyecto un repositorio en el controlador al resolver usando Ninject. El repositorio se almacena en una variable privada de solo lectura. Funciona perfectamente bien! Cuando se llama a un método api, accedo a la variable, ¡solo para ver que de repente es nulo!

Pseudo ejemplo:

public class MyController : ApiController {

  private readonly IRepo _repo;

  public MyController(IRepo repo) {
     Guard.AgainstNullArgument("repo", repo); // guarding to 
                                                          // make sure it''s not null
                                                          // (would throw ex)
     _repo = repo; <--- successfully injected
  }

  // calling this method
  public HttpResponseMessage TestMethod() {
     _repo.. <--- suddenly null
  }

}

He rastreado el problema hasta un pequeño detalle: uno de los métodos del controlador (no el que se accede) se anota con un atributo personalizado que dirige ninject para interceptar el método con una unidad de trabajo. Si elimino el atributo, todo vuelve a funcionar mágicamente.

UnitOfWorkAttribute.cs

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class | AttributeTargets.Interface)]
public class UnitOfWorkAttribute : Attribute
{
}

AttributeInterceptionStrategy.cs (para ninject)

http://pastebin.com/Qg6tQWye

StartupConfig.cs (raíz de composición, configuración de IoC, etc.)

http://pastebin.com/fcuSdujj

EfUnitOfWorkInterceptor.cs

public class EfUnitOfWorkInterceptor : SimpleInterceptor
{

    private readonly IUnitOfWork _unitOfWork;

    public EfUnitOfWorkInterceptor(IUnitOfWork unitOfWork)
    {
        Guard.AgainstNullArgument("unitOfWork", unitOfWork);
        _unitOfWork = unitOfWork;
    }

    protected override void AfterInvoke(IInvocation invocation)
    {
        if(!_unitOfWork.Commited)
            _unitOfWork.Commit();

        _unitOfWork.Dispose();
    }
}

EDITAR

Literalmente he puesto puntos de interrupción en todas partes para descubrir qué está pasando. Hice un destructor en el controlador para asegurarme de que toda la clase no se guarde en el paquete y también cambié el miembro de solo lectura a una propiedad con getter / setter donde punteé en el setter para verificar si se asignó dos veces. Nada sospechoso sucede en absoluto.

EDIT 2

Apilar

http://pastebin.com/pQULHLT0

Ninject.Extensions.Interception.dll!Ninject.Extensions.Interception.Injection.Dynamic.DynamicMethodInjector.Invoke(object target = {EIT.Management.Configuration.Web.Api.Controllers.SetupGroupController}, object[] arguments = {object[2]})   Unbekannt
    Ninject.Extensions.Interception.dll!Ninject.Extensions.Interception.Invocation.Invocation.CallTargetMethod()    Unbekannt

EDIT 3 *

Código del mundo real: http://pastebin.com/SqpR9KNR

Answer 1

Si usa LinFu (que debería, porque DynamicProxy aún necesita un constructor sin parámetros), la solución es bastante sencilla: simplemente haga que el método anotado con el UnitOfWorkAttribute virtual .

Encontré esto a través de algunas pruebas: después de algunos intentos, noté que todo funcionaba si simplemente plan.Add(new ProxyDirective()); . Por supuesto, el interceptor no se aplicó, pero esto apuntó al hecho de que la clase proxy era la culpable.

Answer 2

¡Es extraño! Supongo que quizás tengas otro constructor que no haya configurado tu _repo , luego una nueva instancia del controlador instanciado por eso.