Friday, August 30, 2013

Unity Dependency Resolution clarification

I have an MVC 4 application that I have configured to use Unity for dependency resolution. Because I like to know when things fail, I created a LogDecorator that sits around unity, and catches any type resolution failures, and writes out to our logs that the failure occurred.


I have found that on app startup, there are multiple resolution failures that occur, even though I am not explicitly resolving these. Here are the types:





IControllerFactory
IControllerActivator
IViewPageActivator
ModelMetadataProvider
ITempDataProvider
IActionInvoker
IAsyncActionInvoker





Even though these types fail to resolve, the app works just fine.


Here is what I am thinking is going on here (based on an answer from StackOverflow and my own research) - and the reason that I'm posting here is that I want confirmation from Microsoft that these suppositions are correct:


1) These types are being requested by MVC somewhere under the covers when the app starts up


2) These types are NOT being resolved, because I have not configured Unity to resolve them


3) MVC then uses its own defaults for these types.


4) This is done so that someone CAN override the default implementations if they wish, but they do not have to


5) Therefore, what I should do is to ignore these dependency resolution errors - when it is caught by my logging decorator, I should just promptly re-throw the error.


Does that sound accurate?


Thanks,


Silas


1 comment:

  1. I'm running into the same issue. I was wondering if it was because I pulled my Unity code out into a separate project so that I didn't have to have references to my EF context in my webapi. Is there a way to not get these errors pitched up when you're debugging on thrown CLR exceptions?

    ReplyDelete