Author Archives: Larry House

Setting Up Dependency Injection in ASP.NET MVC with AutoFac

There are lots of IOC (Inversion of Control) containers out there that you can use to do dependency injection in your ASP.NET MVC project.  Honestly, most of them are pretty good, and having chosen to use one is really far more important than which one in most cases.  Having said that, there can be some significant differences in performance and features.  I typically use Autofac because it is one of the fastest and it can reliably and automatically call Dispose() on the IDisposables that it creates in a per http request scope.

Adding Autofac To Your Project

Thanks to the magic of NuGet, you can quickly and painlessly add Autofac to your solution and get started.  In my example here I’ll be adding Autofac support to an ASP.NET MVC 5.2 web application with Web API 2.2.  To do that I’ll need to add 2 packages to my project, Autofac ASP.NET MVC 5 Integration (Id: Autofac.Mvc5 / Version: 3.3.3) and Autofac ASP.NET Web API 2.2 Integration (Id: Autofac.WebApi2 / Version: 3.4.0) .  Adding those packages will add the dependent package Autofac (Id: Autofac / Version 3.5.0), which is the actual core Autofac assembly.  Once completed I have the following packages installed:

ASP.NET MVC AutoFac NuGet Packages

Configuring The Container

Now that we have the packages installed we will need to configure our IOC container and register it with the system.  In keeping with the pattern already in place for handling start up application configuration in ASP.NET MVC, I add a DependencyConfig class to the App_Start folder of my MVC project.  This is a static class that has only a single public method named RegisterDependencyResolvers() and two private methods.

public static IContainer RegisterDependencyResolvers()
{
    ContainerBuilder builder = new ContainerBuilder();
    RegisterDependencyMappingDefaults(builder);
    RegisterDependencyMappingOverrides(builder);
    IContainer container = builder.Build();
    // Set Up MVC Dependency Resolver
    DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
    // Set Up WebAPI Resolver
    GlobalConfiguration.Configuration.DependencyResolver= new AutofacWebApiDependencyResolver(container);
    return container;
}

In the above code snippet line 3 creates a container builder that we will use to configure and create our IOC container.  Lines 4 and 5 call our private methods to configure the type mappings our container will use, we’ll circle back to that in just a minute here.  Line 6 actually creates our Autofac container and line 8 registers a new AutofacDependencyResolver (using our container) as the dependency resolver for ASP.NET MVC.  That means that not only have we set up a dependency resolver for services that we need in our code, but also for the services that ASP.NET MVC will need as well.  For example when ASP.NET needs to create an instance of a controller to handle requests to our site, it will use the container we just created to create an instance of that controller (and all of it’s dependencies).  Line 10 does the same thing as line 8, but this time it is registering a dependency resolver with the WebAPI engine.  Finally line 11 returns an instance of the container we created.  I sometimes use this for unit testing that the dependency mappings have been set up correctly.

Registering Types With The Container

In order for the Autofac container to resolve the dependencies we need we’ll need to tell it what to use for the implementation of the service interfaces our items require.  This is not the only way to do this, but it is the way I prefer and it seems to work out pretty well.  In the first method below we are going to create some global registrations to put in place some general rules so we don’t have to explicitly specify the type for every single thing we need.

private static void RegisterDependencyMappingDefaults(ContainerBuilder builder)
{
    Assembly coreAssembly = Assembly.GetAssembly(typeof (IStateManager));
    Assembly webAssembly = Assembly.GetAssembly(typeof (MvcApplication));
    builder.RegisterAssemblyTypes(coreAssembly).AsImplementedInterfaces().InstancePerRequest();
    builder.RegisterAssemblyTypes(webAssembly).AsImplementedInterfaces().InstancePerRequest();

    builder.RegisterControllers(webAssembly);
    builder.RegisterModule(new AutofacWebTypesModule());
}

On lines 3 & 4 I am getting a reference to the assemblies that contain types I want to register in my solution.  In this case I have a core assembly that contains my models and logic and a web assembly which contains my web UI (Controllers, Views, etc…).  Lines 5 & 6 register every type in the assembly as the implementation for any interface they implement.  Let’s assume that I have a class Foo that implements the IBar interface in one of these assemblies.  With this registration I have registered Foo as the implementation of IBar and if I ask the container to resolve an IBar it will give me an instance of Foo.  It also means that if I ask the container to resolve an item that requires an IBar as a constructor parameter that it will create a Foo and pass it into the constructor of the type I am asking for.   The last part of these two lines defines the lifetime or scope of the objects created.  In this case we are specifying InstancePerRequest.  That means that the container will create one instance of any given type per http request and use it to fulfill any requests for that type.  At the end of the request any objects created will be destroyed.  There are a number of scopes you can choose.  InstancePerRequest and SingleInstance are the two I use the most.  See the docs for more details.

Line 8 registers the MVC Controllers in the web assembly so that ASP.NET can use our resolver to resolve them.  Line 9 then registers an Autofac Module with the container that allows the container to resolve certain web types (like HttpContextBase) so that they can be injected into our classes. (This makes it much simpler to mock & unit test our classes that depend on these web types!)

Now that we have our global registration in place we will probably want to be specific in a few cases.  For example, if you have more than one implementation of a given interface you may want to be specific about which one to use (FYI: last one registered wins…), or you may want certain objects to be create in a different scope as I have done below.

private static void RegisterDependencyMappingOverrides(ContainerBuilder builder)
{
    builder.RegisterType<WebSettingManager>().AsImplementedInterfaces().SingleInstance();
}

In this case I have registered the WebSettingManager class as the implementation of it’s interface(s) and set it to use a SingleInstance scope effectively making it a singleton that lives across http requests.

Final Set Up – The Global.Asax

The last thing you will need to do is actually invoke the RegisterDependencyResolvers method during application start up so that everything gets hooked up properly.

In your global.asax file in Application_Start you will need to add one line of code.

DependencyConfig.RegisterDependencyResolvers()

Here is the entire DependencyConfig.cs

public static class DependencyConfig
{
    public static IContainer RegisterDependencyResolvers()
    {
        ContainerBuilder builder = new ContainerBuilder();
        RegisterDependencyMappingDefaults(builder);
        RegisterDependencyMappingOverrides(builder);
        IContainer container = builder.Build();
        // Set Up MVC Dependency Resolver
        DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
        // Set Up WebAPI Resolver
        GlobalConfiguration.Configuration.DependencyResolver=new AutofacWebApiDependencyResolver(container);
        return container;
    }

    private static void RegisterDependencyMappingDefaults(ContainerBuilder builder)
    {
        Assembly coreAssembly = Assembly.GetAssembly(typeof (IStateManager));
        Assembly webAssembly = Assembly.GetAssembly(typeof (MvcApplication));

        builder.RegisterAssemblyTypes(coreAssembly).AsImplementedInterfaces().InstancePerRequest();
        builder.RegisterAssemblyTypes(webAssembly).AsImplementedInterfaces().InstancePerRequest();

        builder.RegisterControllers(webAssembly);
        builder.RegisterModule(new AutofacWebTypesModule());
    }

    private static void RegisterDependencyMappingOverrides(ContainerBuilder builder)
    {        
        builder.RegisterType<WebSettingManager>AutofacDependencyResolver()
                  .AsImplementedInterfaces().SingleInstance();
    }
}

Resources

Project Home Page: http://autofac.org/

Project Documentation: http://autofac.readthedocs.org/en/latest/#

Project Source Code: https://github.com/autofac/Autofac

NuGet Packages: http://www.nuget.org/packages?q=autofac

Windows 8 Consumer Preview- Diving in head first

On February 29th Microsoft released the Consumer Preview (Beta) of Windows 8 and at that time I installed it on the Build Developer Tablet and in a virtual machine (VMware player).  For the most part I have been pretty happy with my experiences with the new O/S so far, so…  After a playing with it a few weeks on the tablet (and a little in the VM), I have taken the plunge and Installed it on my primary desktop machine.  Ok, I’m only partly committed, I set up a boot from VHD configuration so I can boot Windows 7 still and get things done if needed, but the plan is to try to use the Consumer Preview as my day to day operating system. 

One of the big motivating factors for me is that I really want to be able to spend some time developing (or at least playing with developing) Metro Applications.  I have done a bit in the VM and on the tablet, but It just seemed it would be easier with a full blown desktop system.  Not so much for the horsepower, the Build Tablet has plenty of power and memory, but rather the ergonomics of the situation.  I wanted to be able to work on a system with dual displays, and a full mouse and keyboard.  (Call me spoiled if you want…)

As compared to the Developer Preview that was released at the Build Conference in September the operating system as a whole seems more polished and more stable.  I haven’t experienced any of the hard lockups (requiring a reboot to recover) that I saw a few times with the Dev. Preview.  Most of the included applications seem more polished and reliable as well. 

I personally have found the mouse interaction better than the Dev. Preview, although I have read a lot of posts to the contrary.  I thought a few of the mouse interactions still need a bit of polish, particularly some of the interactions around the corners of the screens seem a bit jumpy, but since I have moved to running on the metal it seems much smoother.

I can’t express how happy I am that I can now close my Metro applications.  (Yeah ! Smile)  To close a Metro application via touch grab it by the top edge with a finger and drag it to the bottom of the screen.  It takes a little experimenting to get the hang of it, but it quickly became second nature.  With a mouse you can move the pointer to the top edge of the screen and it will change to a hand, then just click and drag it down top the bottom edge.

Now that I have things running on dual displays there are a couple of things that are bugging me.

  1. I can only run the Start Screen and Metro Apps on the primary display which feels kind of odd.  Why can’t I put a Metro app on the second screen?  Weird…

    MetroApp

  2. Using an app on the desktop on the second screen while having the Start Screen up on the Primary screen results in some odd behavior.  (The Screen goes blank)

    BlankStartScreen

  3. If I have an app on the desktop running on the primary screen with the Start Screen up (Covering the desktop app) and I click on the desktop on the second screen I can’t get to my application.  The start screen goes blank, so it feels like the desktop has focus, but there doesn’t appear to be a way to get to my app.

    Windows 8 Desktop

Windows 8 Consumer Preview Released

If you hadn’t heard, Windows 8 Consumer Preview was released this morning (you can get it at http://preview.windows.com/).  So far I have installed it on both the Build Developer Tablet and in a Virtual Machine (VMware Player) and both installs were relatively quick and painless.

So far it seems stable (5 hours in LOL).  It seems to be coming together fairly nicely.  Once I have had some time to work with it a bit, I’ll post something a bit more substantial.  For now here is some screen shots. 

The Lock Screen

LockScreen

The Start Screen

StartScreen

Notice you can now choose from a few color schemes and texture patterns for the Start Screen.  Also you can now group items.

 

The App Store

Store

 

Included Apps

Weather

Weather

 

Calendar

Calendar

Calendar.Day

 

Maps

Maps

Maps.Traffic

 

Solitaire (of course)

Solitaire

 

Visual Studio 11 Beta on Windows 8

Microsoft also released the Beta version of Visual Studio 11 this morning.  Here’s a quick shot of the new Dark Theme.

VisualStudio.11

You can download the Visual Studio 11 Beta from http://www.microsoft.com/visualstudio/11/en-us

RollOvers with HTML5 data- attributes and jQuery

Here’s a nice, clean way to set up image roll over effects on your web sites using the new HTML5 data- attributes and a little jQuery.

To demonstrate I am going to create a new web project in Visual Web Developer Express 2010. For starters we’ll add the jQuery and Modernizr JavaScript libraries using the Nuget Package Manager.

nuget

Next we’ll set up a basic html page with 2 images on it.

<!DOCTYPE html>
<html>
    <head>
        <title>Index</title>
        <script src="/Scripts/modernizr-1.7.min.js" type="text/javascript"></script>
        <link href="/CSS/Demo.css" rel="stylesheet" type="text/css" />
    </head>
    <body>
        <div>
            <h1>RollOver Demo</h1>
            <img src="/Images/wordpress.png" data-hover="/Images/wordpress.hover.png" alt="WordPress" /> 
            <br /><br />
            <img src="/Images/twitter.png" data-hover="/Images/twitter.hover.png" alt="Twitter" />
        </div>
    </body>
    <script src="/Scripts/jquery-1.7.1.min.js" type="text/javascript"></script>
</html>

Note the reference to the Modernizr.js script near the top and to the jQuery script near the bottom.  Usually I place all my JavaScript references near the bottom so they don’t hold up the loading of the page itself and the images.  It is however important to load the Modernizr script near the top so that it can work correctly.  If we view our page now it should look something like this:

Screen

Next we need to add an external JavaScript file and add the following function inside this file.

function InitRollOvers() {
    $(function () {
        $('img[data-hover]').hover(function () {
            $(this).attr('tmp', $(this).attr('src')).attr('src',
                $(this).attr('data-hover')).attr('data-hover', 
                $(this).attr('tmp')).removeAttr('tmp');
        }).each(function () {
            $('<img />').attr('src', $(this).attr('data-hover'));
        }); ;
        $('input[data-hover]').hover(function () {
            $(this).attr('tmp', $(this).attr('src')).attr('src',
                $(this).attr('data-hover')).attr('data-hover', 
                $(this).attr('tmp')).removeAttr('tmp');
        }).each(function () {
            $('<input />').attr('src', $(this).attr('data-hover'));
        }); ;
    });
}

This script will find all of the <img /> and <input /> elements with data-hover attributes and wire up handlers for the hover events.

Now we’ll add a reference to the external JavaScript …

<script src="/Scripts/Demo.js" type="text/javascript"></script>

… and add a call to the InitRollOvers() function on document ready.

    <script type="text/javascript">
        $(document).ready(function () {
            InitRollOvers();
        });
    </script>

Here is the whole html page all finished up:

<!DOCTYPE html>
<html>
    <head>
        <title>Index</title>
        <script src="/Scripts/modernizr-1.7.min.js" 
                    type="text/javascript"></script>
        <link href="/CSS/Demo.css" rel="stylesheet" 
                                     type="text/css" />
    </head>
    <body>
        <div>
            <h1>RollOver Demo</h1>
            <img src="/Images/wordpress.png" 
                    data-hover="/Images/wordpress.hover.png" 
                    alt="WordPress" /> 
            <br /><br />
            <img src="/Images/twitter.png" 
                     data-hover="/Images/twitter.hover.png" 
                     alt="Twitter" />
        </div>
    </body>
    <script src="/Scripts/jquery-1.7.1.min.js" 
                type="text/javascript"></script>
    <script src="/Scripts/Demo.js" 
                type="text/javascript"></script>
    <script type="text/javascript">
        $(document).ready(function () {
            InitRollOvers();
        });
    </script>
</html>

If you view the html page now the images should “light up” when the mouse is over them.

Wrap Up

If you add the external script files and the document ready script to your ASP.Net Master Pages you can simply add the data-hover attributes to your images and your RollOver effects should just work.  Even better, since our InitRollOvers() function looks for both <img /> and <input /> tags you can just add data-hover attributes to your ASP.Net ImageButtons and they will get wired up as well. 

If you use this technique along with Microsoft ASP.Net Ajax Update Panels the hover effect handlers will break when the partial-postback occurs. To fix this you will want to add the following line to your document.ready function right after the InitRollOvers() call:

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(InitRollOvers);

This tells the script manager to call our InitRollOvers() function when an Ajax-postback completes.