{"action":"created","issue":{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/93","labels_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/93/labels{/name}","comments_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/93/comments","events_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/93/events","html_url":"https://github.com/simpleinjector/SimpleInjector/issues/93","id":101424376,"number":93,"title":"How to use Simple Injector in ASP.NET vNext with Asp.Net Identity","user":{"login":"kawazoe","id":406575,"avatar_url":"https://avatars.githubusercontent.com/u/406575?v=3","gravatar_id":"","url":"https://api.github.com/users/kawazoe","html_url":"https://github.com/kawazoe","followers_url":"https://api.github.com/users/kawazoe/followers","following_url":"https://api.github.com/users/kawazoe/following{/other_user}","gists_url":"https://api.github.com/users/kawazoe/gists{/gist_id}","starred_url":"https://api.github.com/users/kawazoe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kawazoe/subscriptions","organizations_url":"https://api.github.com/users/kawazoe/orgs","repos_url":"https://api.github.com/users/kawazoe/repos","events_url":"https://api.github.com/users/kawazoe/events{/privacy}","received_events_url":"https://api.github.com/users/kawazoe/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-08-17T13:49:22Z","updated_at":"2015-08-18T12:01:17Z","closed_at":null,"body":"I've been trying to implement a vnext website with SimpleInjector using the pattern recommended in issue #41. I really like the separation it brings between first-party and third-party services, but I'm hitting a wall when trying to add support for Asp.Net Identity v3 using a custom UserStore.\r\n\r\nYou see, Asp.Net Identity normally gets registered through the DNX DI system during service configuration.\r\n\r\n```csharp\r\nservices.AddIdentity<FooIdentityUser, FooIdentityRole>()\r\n    .AddDefaultTokenProviders()\r\n    .AddUserStore<FooUserStore>()\r\n    .AddRoleStore<FooRoleStore>();\r\n```\r\n\r\nThis means that the entire Asp.Net Identity dependencies, including the custom FooUserStore and FooRoleStore, class will be registered on the the default DNX container. Already, this breaks the nice separation between the two containers, but the main issue comes from the AccountController class. Since this class needs access to Asp.Net Identity's UserManager and SignInManager, then it needs to access classes registered on the DNX container.\r\n\r\nWith the suggested integration method, controller activation is completely handled by SimpleInjector through the SimpleInjectorControllerActivator. There is no place to inject DNX registered services from there.\r\n\r\nI thought about registering the Asp.Net Identity types in the DNX container and use SimpleInjector as a forwarder to the DNX's container.\r\n\r\n```csharp\r\ncontainer.Register(app.ApplicationServices.GetRequiredService<UserManager<FooIdentityUser>>)\r\n```\r\n\r\nThe main problem with this solution is that the DNX container now have to know about my data access layer which means more forwarding; and in both direction this time.\r\n\r\nTo me, this feels like a road to hell. I'm sure there must be a simpler way to get this working. What do you recommend to do in this case?"},"comment":{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/comments/132186955","html_url":"https://github.com/simpleinjector/SimpleInjector/issues/93#issuecomment-132186955","issue_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/93","id":132186955,"user":{"login":"dotnetjunkie","id":1506621,"avatar_url":"https://avatars.githubusercontent.com/u/1506621?v=3","gravatar_id":"","url":"https://api.github.com/users/dotnetjunkie","html_url":"https://github.com/dotnetjunkie","followers_url":"https://api.github.com/users/dotnetjunkie/followers","following_url":"https://api.github.com/users/dotnetjunkie/following{/other_user}","gists_url":"https://api.github.com/users/dotnetjunkie/gists{/gist_id}","starred_url":"https://api.github.com/users/dotnetjunkie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dotnetjunkie/subscriptions","organizations_url":"https://api.github.com/users/dotnetjunkie/orgs","repos_url":"https://api.github.com/users/dotnetjunkie/repos","events_url":"https://api.github.com/users/dotnetjunkie/events{/privacy}","received_events_url":"https://api.github.com/users/dotnetjunkie/received_events","type":"User","site_admin":false},"created_at":"2015-08-18T12:01:17Z","updated_at":"2015-08-18T12:01:17Z","body":"There are a several possible paths to walk here, depending on to what extend you would like the SOLID principles guide you here.\r\n\r\nIf you're just interested to get this working quickly, you can add the following configuration to vNext's `Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)` method:\r\n\r\n``` c#\r\nIServiceProvider provider = app.ApplicationServices;\r\n\r\ncontainer.Options.AllowOverridingRegistrations = true;\r\ncontainer.Register<AccountController>(provider.GetRequiredService<AccountController>);\r\ncontainer.Options.AllowOverridingRegistrations = false;\r\n```\r\n\r\nWhat this does is simply telling Simple Injector to delegate the construction of the `AccountController` to ASP.NET's built-int DI container. This will work, because with the default template, the `AccountController`  can already be resolved. \r\n\r\nThis does mean however that you will have to register the `IEmailSender` and `ISmsSender` abstractions in the ASP.NET container. This is weird of course, because although these abstractions are defined by the VS template, they are application-specific services and it's likely that other parts of your application will want to use these abstractions as well.\r\n\r\nSo instead, you can let the `AccountController` and `AuthMessageSender` to be created by Simple Injector, while the `UserManager`, `SignInManager` and `ApplicationDbContext` are redirected to the vNext container:\r\n\r\n``` c#\r\nIServiceProvider provider = app.ApplicationServices;\r\n\r\ncontainer.Register<IEmailSender, AuthMessageSender>();\r\ncontainer.Register<ISmsSender, AuthMessageSender>();\r\ncontainer.Register(provider.GetRequiredService<UserManager<ApplicationUser>>);\r\ncontainer.Register(provider.GetRequiredService<SignInManager<ApplicationUser>>);\r\ncontainer.Register(provider.GetRequiredService<ApplicationDbContext>);\r\n```\r\n\r\nThe decision we made with the first option is to see the `AccountController` as framework type, or at least, we don't really care about the maintainability of this type, even though its code in our application. This might be reasonable way of looking at this, although I would argue that after the code got injected into our project, it has become our problem and responsibility to maintain.\r\n\r\nWith the second option, we decided that the `AccountController` is actually part of our code base and is our control to maintain. Still we (implicitly) chose to violate the SOLID principles (especially DIP, SRP, and ISP) by injecting `UserManager<T>`, `SignInManager<T>` and `ApplicationDbContext` into the `AccountController. Our `AccountController` is:\r\n* violating the Dependency Inversion Principle (DIP), because it takes a hard dependency on concrete types that are defined by an external tool;\r\n* it violates the Interface Segregation Principle (ISP), because it is forced to depend on methods on `UserManager<T>`, `SignInManager<T>` and `ApplicationDbContext` that it doesn't use;\r\n* and it violates Single Responsibility Principle (SRP), because it implements lots of logic should not be part of the `AccountController`.\r\n\r\nSo the third option is to actually refactor the `AccountController` into a SOLID class. How this looks will completely depend on your application, because the generated code supplies us with a full implementation that almost no one will ever need. So you as application developer will have to strip out the code that you don't use and from that proper application-specific abstraction can be distilled.\r\n\r\nI won't be able to post an example of how a SOLID `AccountController` might look like right now (because of time constraints), but I will update this answer within a few days with an example. Please stay tuned...\r\n"}}