I took a shot at making the required changes to get this to work with the MVC4 RC changes to IDependencyResolver. The main changes that I made were based on the following:
Blog Post & Comments: http://www.strathweb.com/2012/05/using-ninject-with-the-latest-asp-net-web-api-source/
Source code from blog post: https://github.com/filipw/Ninject-resolver-for-ASP.NET-Web-API/
I also updated the SampleApplication to be an MVC4 RC website. Finally, I did the work in the VS 2012 RC, so the Solution and Projects were upgraded, but they are backwards compatible with VS 2010.
Let me know if you have any suggestions or questions.
Implement new IDependencyResolver changes for MVC4 RC
Upgrade SampleApplication to MVC4 RC
Update NuGet poackage dependency to Microsoft.AspNet.WebApi
Remove upgrade backup files
Updates for scope behavior. Based on blog source comments.
BeginScope can also just return this since the NinjectDependencyResolver itself already inherits Ninject Scope and has a reference to the kernel already.
I just made this change and added the commit to the pull request. Thanks for pointing this out.
Begin scope can just return this, since NinjectDependencyResolver alr…
…eady inherits NinjectScope and has a refernce to the kernel already
I actually don't think BeginScope should return this - please see my version here: https://gist.github.com/2947483
I wanted the NinjectResolver to be disposed but not the NinjectScope.
@jacobe I do not see any difference in returning a new NinjectScope or this, since as @StephenHead pointed out, NinjectResolver already inherits from NinjectScope... It is due to the ability to Dispose of the _kernel.
@paigecook Yep - you're right. The only difference of matter is to make sure _kernel is disposed.
@jacobe Actually I now see that the Dispose method on NinjectScope is marked as virtual as well. Sorry I missed that yesterday. Making your suggested change breaks functionality, because we are back to Disposing the entire _kernel as the NinjectResolver is disposed after each use and since _kernel is a reference to the actual Kernel object created in the Application Start, we effectively throw the whole thing away if we do this... Again this is a case where letting ASP.NET try to manage the per-request scoping will not work, because Ninject already handles that for us. If you pull my fork, make your changes and run the SampleApplication navigating to the /api/values url, you will see the error.
Added support for MVC4 final in c0b1a97