In my MVC web-app I get the following error thrown:
The request lifetime scope cannot be created because the HttpContext
is not available
When I google it I found a solution would be to upgrade my autofac.Mvc dll but I only use autofac dll, Autofac.Integration.Mvc dll etc and I can't find any dll with autofac.MVC
Am I missing any dll?
What is the difference between Autofac , Autofac.MVC ,Autofac.Integration.Mvc dlls?
The documentation on MVC integration may be of help to you going forward, but let me also answer your question.
First, it's good to understand that there's a difference between NuGet packages and DLLs (aka assemblies). Many times the name of the assembly inside a NuGet package is the same as the package, but sometimes the assembly inside has a different name. (And sometimes a NuGet package has more than one assembly.)
So, to answer your question:
NuGet Package Assembly Inside Purpose
------------- --------------------------- -------------------------
Autofac Autofac.dll Core Autofac
Autofac.Mvc5 Autofac.Integration.Mvc.dll ASP.NET MVC 5 integration
So, when you see that you need to update your MVC integration, what it translates to is that you need the latest version of the Autofac.Mvc5 NuGet package.
Autofac.mvc is used when you integrate autofac to your mvc application same as the autofac. WebAPI which is used when you integrate autofac for WebAPI's application.
MVC integration provides dependency injection integration for controllers, model binders, action filters, and views. It also adds per-request lifetime support.
Because the RegisterModelBinders() extension method uses assembly scanning to add the model binders you need to specify what type(s) the model binders (IModelBinder implementations) are to be registered for.
This is done by using the Autofac.Integration.Mvc.ModelBinderTypeAttribute
Likewise there are many other mvc integration supported by this dll, which are listed down in this link
https://autofac.org/apidoc/html/F26C16A.htm
Autofac lets you inject your constructor parameters along with property and method injection
Hence we need all three dlls to make autofac up and functional in mvc application.
Do let me know if you need any further clarification on this.
Thanks!!
Related
I'm a little confused as to what integrated options I have for DI. I see it's pretty straightforward for .net core (for my particular projects), but I don't need to build a cross platform app and don't see the advantage to using core. However, it doesn't look like .net framework applications are still setup with Global.asax and without Startup.cs so does that mean there is no integrated DI option for .net framework 4.7? Do I still need to get a 3rd party solution or is there a way to use the same DI workflow in a .net framework project as is used in a core project?
Dependency Injection is not integrated by default in classic asp.net, you need to add a nuget package to handle DI (only integrated by default in asp.net core).
EDIT: Even though I found out how to do it as explained below, I still ended up going with Autofac because I didn't realize the Microsoft's solution only supports constructor injection, but not property injection.
I found instructions on how to do it here. I know link answers are bad, but I don't have time to do any more than this. If someone else wants to make an answer with full instructions I will mark it.
https://scottdorman.blog/2016/03/17/integrating-asp-net-core-dependency-injection-in-mvc-4/
Also note that if you are not using Owin already, it is not required. You can set it up just the same in Application_Start method of Global.asax. Only change you would need to make is when it references the Startup class in a statement that reflectively gets all the Controller classes, you will need to change that to be the class the code is in (or any other class in your assembly).
I'm having trouble getting started setting up dependency injection in my project.
Is there Microsoft provided functionality to do dependency injection with Mvc 5.2.3? If so where is it because I can't find it.
All the articles I can find are about the DI functionality in Core. According to Wikipedia that is the next version of Mvc. I'd rather just use what is built in to my version.
If nothing is built in, then I'll go do research myself on third party solutions.
There's no built-in DI functionality in ASP.NET MVC 5.2.3. You will need to use a third party DI container or write your own. If you are looking for one written by Microsoft you may checkout Unity.
I would like to create a standalone class library project that acts as my composition root. I want to keep the concrete implementations of types out of projects where they are never intended to be used directly. This is not possible if I'm forced to construct my Ninject registrations inside my MVC web application. For example I would have to map: IAbstraction to ImplementationThatIsNotValidForDirectUseInThisLayer.
I have created the composition root specific project and added references to all my projects so that I can bind my abstractions to their corresponding concrete implementations. I have installed the Ninject.MVC5 Nuget package (and all of its dependencies) into the composition root specific project.
When I reference my composition root project in my main MVC5 web application I can set a break point on the Start and Stop methods and the code executes. This means WebActivator is correctly bootstrapping these classes at run-time.
The problem is when I hit a controller that is not parameterless I get the dreaded: "No parameterless constructor defined for this object." error message.
Why isn't Ninject being used to construct controllers and all of their dependencies? Is there some additional configuration I need to do?
I have a project reference from MyApp.WebApp to the MyApp.WebApp.CompositionRoot.Ninject project where all of my bindings are being configured.
The problem seems to occur only when the initial ASP.NET project is created from the Empty project template in Visual Studio (I'm using 2013 for what its worth) with MVC added via Nuget. If I create my ASP.NET web application using the MVC template and keep my composition root in an external class library referenced by the MVC application, the controllers are correctly constructed by Ninject. I've looked at the project created from the MVC template and the only reference that sounded potentially important that was missing was "System.Web.Abstractions. I added the reference but it did not fix the issue.
I decided to define my Ninject modules in the separate composition root only class library project, but installed the Ninject.MVC5 Nuget package into the web application. The goal of keeping the concrete implementations unavailable to the web application is maintained, but I do have to keep some references to Ninject in the MVC web application. This is a minor issue, at least this maintains my layered architecture and guarantees that a type cannot be used where it was not intended (without adding references of course!).
I have integrated Ninject into an MVC 4 project using the Nuget Ninject.MVC3 package. I can see that App_Start now contains a class called NinjectWebCommon, with a 'bootstrapper'. Following the standard instructions I can inject a concrete instance of an interface into a controller, and the debugger shows me that this is being served up by the NinjectDependencyResolver class.
However: I can't find out, by poking into the Ninject code, where this NinjectDependencyResolver class is being set as the IDependencyResolver using the standard DependencyResolver.SetResolver method. So I'm not sure if I'm just being inept, or whether there's an alternative way this is getting hooked in. Can anyone enlighten me?
IDependencyResolver ships with asp.net MVC framework and allows implementing dependency injection into controllers and other components (asp.net MVC use it internaly) .
I won't explain benefits here but you can read a good introduction here.
When adding an IoC framework (Ninject, Unity, StructureMap, ...) into MVC, you have to plug the Ioc code to the native dependency resolver, with an implementation of IDependencyResolver.
The DependencyResolver static class is the registration point, especially DependencyResolver.SetResolver(IDependencyResolver resolver)
But now, many Ioc framework come with an MVC integration package such as Ninject.MVC our StructureMap.MVC. It's easier for us (and often more robust) and you don't really need to known how it is done.
A quick look at NinjectMvcHttpApplicationPlugin in repositoty Ninject.Web.Mvc will show you the glue.
I am working in Visual Studio 2013 RC and am testing Forms Authentication using new Microsoft.AspNet.Identity.* packages.
I would to integrate these concepts (Users, Roles, etc, etc) but want to use my own domain models (POCOs) which are in different assembly. I also don't want to create a dependency on Microsoft.AspNet.Identity.* dlls.
Is that even possible?
I found this article which says it is not, but the article is written based on Preview not RC versions of identity packages.
I have updated my sample project which you can find here: Identity RC1 sample
It now implements an entity framework model, it still require a reference to the Microsoft.AspNet.Identity.EntityFramework as I didn't want to reimplement all the Store classes also. But the sample shows how you can use your own POCO classes for the model.
If you want to completely remove the dependency on Microsoft.AspNet.Identity.EntityFramework from your model assembly you need to implement an class implementing the IIdentityStore interface which has properties of the following interfaces:
IUserLoginStore
IRoleStore
IUserSecretStore
ITokenStore
IUserClaimStore
IUserManagementStore
IUserStore
The IIdentityStore class should be in an assembly separate from your model assembly, with a reference to your model assembly. The IIdentityStore assembly would be dependent on ASP.Net Identity core.
Your custom implementation of IIdentityStore would need to somwhow be able to convert to and from your POCO classes to ASP.Net Identity interfaces such as IUser, IUserSecret etc.
Seems to me to be a lot of work for little gain, if you are using EF for your stores anyway.
Taking a dependency on the AspNet.Identity.Core assembly and have some of your POCO classes implementing one tiny interface each, seems a lot simpler to me.
Yes this is a fully supported scenario, basically you will want to use exclude using the Microsoft.AspNet.Identity.EntityFramework dll which has the default EF implementation, but you should be able to reuse the Manager classes and just implement your own custom Stores using your own POCOs which the manager will use just fine via the interface. For RTM its been streamlined and simplified a bit more, I believe the RC version was not quite as streamlined yet.
Updated You can get early access to the RTM bits here: MyGet
Just in case. Maybe I can help someone.
exorcising entity framework from asp.net.Identity
I'd created separate project(class library), then add ref to asp.identity.core,
then I'd implemented my UserStore class there, and feed it my Identity config in Web project.
It works fine in project with complex n-tier architecture.