Today I faced a Castle Windsor dependency injection problem in an ASP.NET MVC app. The problem happened when using SignalR.

While implementing some UI real time user interaction I needed to have my persistence facility (Database context) injected inside my SignalR Hub class.

I Googled and found this awesome and to the point post by Mira Javora:

SignalR-Dependency Injection using Castle.Windsor

With the code he provided I was able to configure SignalR’s dependency resolver and everything was working as expected as Mira showed in his post.

In my case two objects are being injected in the Hub class:

public class AssessmentHub : Hub
{
    private MyContext _database { get; set; }

    private ILogger _logger { get; set; }

    public AssessmentHub(MyContext database, ILogger logger)
    {
        _database = database;
        _logger = logger;
    }
    
    ...
}        

They were being properly injected in my own Hub class methods but things started to go wrong when SignalR’s OnDisconnected method was being called:

public override Task OnDisconnected()
{
    try
    {
        Guid connectionId = Guid.Parse(Context.ConnectionId);

        // Database was null here! 
        var client = Database.HubConnections.Single(hc => hc.ConnectionId == connectionId);

        UnlockChapterAndUpdateClients(client);

        Database.HubConnections.Remove(client);

        Database.SaveChanges();
    }
    catch (Exception ex)
    {
        Logger.Error(ex.Message, ex);
    }

    return base.OnDisconnected();
}

This was the error I was getting:

HttpContext.Current is null. PerWebRequestLifestyle can only be used in ASP.Net.

The OnDisconnected method is an asynchronous method and as such it runs under a background thread ( not the one processing the request ). ASP.NET controls the threads and makes sure that only one thread is processing the request. This way HttpContext and as a consequence my _database injected object is null inside that method.

After some thinkering I remembered that I had my Persistence Facility registered PerWebRequest:

public class PersistenceFacility : AbstractFacility
{
    protected override void Init()
    {
        Kernel.Register(Component.For<MyContext>().          
            LifeStyle.PerWebRequest);
    }
}

Then, I Googled a little bit more and found this StackOverflow question:

Castle.Windsor lifestyle depending on context?

User Cuong Le shared a great post by Mauricio Scheffer called:

Hybrid lifestyles in Windsor

His post describes exactly what I needed (an Hybrid lifestyle ), that is, a way of keeping using the PerWebRequest life style when HttpContext is available but then resort to Transient lifestyle when it’s not.

An hybrid lifestyle is one that actually blends two underlying lifestyles: a main lifestyle and a secondary lifestyle. The hybrid lifestyle first tries to use the main lifestyle; if it's unavailable for some reason, it uses the secondary lifestyle. This is commonly used with PerWebRequest as the main lifestyle: if the HTTP context is available, it's used as the scope for the component instance; otherwise the secondary lifestyle is used.

I then grabbed Mauricio’s NuGet package Castle.Windsor.Lifestyles and changed my Persistence Facility code to:

public class PersistenceFacility : AbstractFacility
{
    protected override void Init()
    {
        Kernel.Register(Component.For<MyContext>().          
            LifeStyle.HybridPerWebRequestTransient());
    }
}

I’m back in business now.

I learn so much each day that I don’t have time to post about every interesting thing I discover.

Generally I get to these discoveries/solutions to overcome a wall that somehow appears while developing a given functionality.

I use Castle Windsor as my Inversion of Control [ IoC ] container. Recently I’ve been implementing some features that depend heavily on ASP.NET MVC action filter attributes and at some point I needed to get a reference to a service that hits the database for some data checking rules. Unfortunately one cannot ask a Windsor container to give back a dependency when inside an attribute because as Krzysztof Koźmic (the developer of Windsor) says in his answer for the question: Injecting dependency into CustomAttribute using Castle Windsor at StackOverflow:

You can't. Attributes are metadata. Putting behavior into them is wrong. Putting dependencies is even worse.

Although I understand the point I Googled a little bit more and found this great post by Dino Esposito called ASP.NET MVC: Resolve or Inject? That’s the Issue…. In this post Dino shows how to use ASP.NET MVC extension point called DependencyResolver that sits here System.Web.Mvc.DependencyResolver. It simplifies service location and dependency resolution…

With this I was able to do the following in a custom WindsorDependencyResolver.cs class:

public class WindsorDependencyResolver : IDependencyResolver
{
    private readonly IWindsorContainer _container;

    public WindsorDependencyResolver(IWindsorContainer container)
    {
        _container = container;
    }

    public Object GetService(Type serviceType)
    {
        return _container.Kernel.HasComponent(serviceType) ? _container.Resolve(serviceType) : null;
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        return _container.Kernel.HasComponent(serviceType) ? _container.ResolveAll(serviceType).Cast<object>() : new object[] { };
    }
}

The above code I took from this great question at StackOverflow: Castle Windsor Dependency Resolver for MVC 3. There’s an extensive list of useful info there.

In the container bootstrap code inside Global.asax file we put this class into use:

private static void BootstrapContainer()
{
    _container = new WindsorContainer().Install(FromAssembly.This());

    var controllerFactory = new WindsorControllerFactory(_container.Kernel);

    ControllerBuilder.Current.SetControllerFactory(controllerFactory);

    // Create and register the resolver
    var resolver = new WindsorDependencyResolver(_container);
    DependencyResolver.SetResolver(resolver);
}

See how we’re passing Windsor’s app container to the Dependency Resolver. This way when we ask the DependencyResolver for a service/repository/whatever it’ll get it from the container and we’ll take advantage of the container’s powerful capabilities. You can read about such awesome capabilities in this series of posts called Windsor tutorial - ASP.NET MVC 3 application (To be Seen) written by Windsor’s developer (Krzysztof Koźmic).

Now it’s just a matter of using the Dependency Resolver for our benefit:

public class MyAuthorizeAttribute : AuthorizeAttribute
{
    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        // Make sure the user is authenticated.
        if (httpContext.User.Identity.IsAuthenticated == false)
            return false;

        // If User has the "SuperUser" role he can surf all the app...
        if (httpContext.User.IsInRole(AccountController.SuperUser))
            return true;

        var permissionService = DependencyResolver.Current.GetService(typeof(PermissionService)) as PermissionService;

        return permissionService.UserHasPermission(httpContext);
    }
}

The real good thing about the Dependency Resolver is that once you set the resolver you can call it throughout your ASP.NET MVC…

OK. It diverges from Krzysztof’s main point that one should not put behavior in attributes, but it does the job and is working as expected in my case.

This has helped me to continue my development and I hope it’ll also help you.