This project is read-only.

How to exclude AccountController in MVC5 application?

Jan 28, 2015 at 11:52 PM
Just putting together a demo application that uses SimpleInjector with an out-of-the-box ASP.NET MVC 5 + Identity application.

Getting exceptions related to the AccountController and I was wondering if there was a way to simple exclude it so SI doesn't even look at it?

Thanks - wg
Jan 29, 2015 at 7:50 AM
Can you supply us with more information? Things such as your configuration and detailed information about the exception (message, type, stack trace of the exception and inner exceptions) would be very helpful.
Jan 29, 2015 at 5:14 PM
Thanks for the reply.

Basically, I'm getting all the exceptions described in this thread about duplicate constructors, SI knowing about ApplicationUserManager, ApplicationSignInManager, etc.... For the sake of the demo, I just want SI to leave this crap, I mean wonderfully discombobulated and overly-complicated wonderful authentication feature, alone.

In other words, insofar as AccountController and ManageController and all the other wonderful OWIN bits, I just want SI to leave it alone rather than go through all the hoopla described in the aforementioned thread.

As an aside, are folks really using the default Identity crap in their apps with SI (or any other IoC)? If not, I'd be interested in what folks are doing because frankly, I think its a mess.

Thanks -wg
Jan 29, 2015 at 11:22 PM
Edited Jan 29, 2015 at 11:24 PM
I understand your frustration. I took me a lot of research to figure out how Identity works. It is obviously something we've never seen before. I personally have no experience with it's predecessor: MembershipProvider, so for me a research was necessary eitherway. Disadvantage of my research was that it was/is pretty new and therefore there was not so much information to do research on.

In my quest for information I talked to different people which had experience with Identity. All of them had the same initial opinion on Identity. But after some work to get to know this new framework they were all very enthusiastic, because of the following differences with MembershipProvider:
  • It is extensible - you can have Id to be int, Guid, String, whatever else.
  • You define your own User object, you can add there whatever you need.
  • You can provide your own storage mechanisms: Azure Tables, MySql, RavenDb, MongoDb, etc.
  • You can do unit testing or integration testing. All my login and account management commands/queries are fully tested.
  • Claims are a bliss. With MembershipProvider you had to have so-many hacks to get the same functionality as you do now with claims (this comment is borrowed as I have no experience with MembershipProvider and/or Claims).
All this could not be done with MembershipProvider.

The combination of Identity with Owin and the strange way Owin does something which looks like Dependency Injection makes it very difficult to understand. There are a lot of 'things' I disagree on in the design of Owin, but that is actually a different subject, although when you take your first look on Identity it is not clear where the boundary between Owin and Identity actually lies.

All that being said, yes I use Identity with great pleasure in my projects (Sometimes biting my lip when it comes to Owin and the Owin pipeline…).
When you get the hang of it, implementing the suggestions in the already mentioned blog discussing which adjustments to make to get it up and running is no more than 20 minutes of work.

Simple Injector has no, by my knowledge, mechanism to skip a certain instance. Nevertheless you could ‘skip’, or control, it yourself like this:
    container.RegisterMvcControllers(Assembly.GetExecutingAssembly());

    container.Options.AllowOverridingRegistrations = true;

    container.RegisterPerWebRequest<AccountController>(() =>
                {
                    var accountController = new AccountController();
                    //do something with accountcontroller
                    return accountController;
                });

    container.Options.AllowOverridingRegistrations = false
What is happening here is that we temporary allow overriding already registered objects and replace the existing registration with our own. We than have the possibility to register a delegate in which we can supply whatever initialization you need. You still need the AccountController to have a single constructor. You could decide that to be the default constructor and use the built-in (from the template) service locator anti pattern to resolve the authentication manager, and application user manager.

If you would use that approach, there is no need to override the registration. This is only necessary if you need to do some custom initialization or what so ever.