{"action":"created","issue":{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/180","repository_url":"https://api.github.com/repos/simpleinjector/SimpleInjector","labels_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/180/labels{/name}","comments_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/180/comments","events_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/180/events","html_url":"https://github.com/simpleinjector/SimpleInjector/issues/180","id":130118093,"number":180,"title":"Add support for IServiceCollection and IServiceScope","user":{"login":"qujck","id":4510990,"avatar_url":"https://avatars.githubusercontent.com/u/4510990?v=3","gravatar_id":"","url":"https://api.github.com/users/qujck","html_url":"https://github.com/qujck","followers_url":"https://api.github.com/users/qujck/followers","following_url":"https://api.github.com/users/qujck/following{/other_user}","gists_url":"https://api.github.com/users/qujck/gists{/gist_id}","starred_url":"https://api.github.com/users/qujck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qujck/subscriptions","organizations_url":"https://api.github.com/users/qujck/orgs","repos_url":"https://api.github.com/users/qujck/repos","events_url":"https://api.github.com/users/qujck/events{/privacy}","received_events_url":"https://api.github.com/users/qujck/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/labels/discussion","name":"discussion","color":"d4c5f9"},{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2016-01-31T11:47:36Z","updated_at":"2016-06-03T10:18:24Z","closed_at":null,"body":"ASP.NET Core defines the abstractions `IServiceCollection` and `IServiceScope` to complement, and work in conjunction with, the `IServiceProvider` abstraction. Just as `IServiceProvider` defines a mechanism for retrieving object instances,  `IServiceCollection` defines a mechanism for capturing the abstraction to implementation mapping and the desired instance lifetime and `IServiceScope` holds references to object instances for each lifetime instance. \r\n\r\nI have read many well formed arguments detailing the problems implementing the abstractions and I have heard requests from our users to do so anyway. IMO the current Integration package is not fit for purpose as it does not seamlessly integrate object instances resolved by Simple Injector and those same objects resolved by the default container.\r\n\r\n`IServiceCollection` contains the definitions for registrations and should easily map to Simple Injector equivalents (especially since the addition of `DefaultScopedLifestyle`). `IServiceScope` is an abstraction for explicit lifetime management that does not seamlessly fit with Simple Injectors *Ambient Scopes* but this, in itself, is not a reason to not attempt a Simple Injector implementation. For example, a `SimpleInjectorServiceScope` could be resolved within the *Scope* it is instantiated within and registered for disposal along with its owning *Scope* - doing so would directly link the lifetime of each `IServiceScope` instance with the *Scope* instance it represents.\r\n\r\nThese 2 new abstractions are part of ASP.NET Core, EF Core and will become a requirement for other modern libraries and frameworks in the future. I propose we add first class support for both `IServiceCollection` and `IServiceScope` to ensure that Simple Injector remains a simple option for the future. We may not be able to achieve 100% compatibility with the expectations made by the ASP.NET team but we can achieve 100% compatibility with the expectations of our users: a Simple Injector for ASP.NET Core."},"comment":{"url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/comments/223543718","html_url":"https://github.com/simpleinjector/SimpleInjector/issues/180#issuecomment-223543718","issue_url":"https://api.github.com/repos/simpleinjector/SimpleInjector/issues/180","id":223543718,"user":{"login":"Reonekot","id":2690013,"avatar_url":"https://avatars.githubusercontent.com/u/2690013?v=3","gravatar_id":"","url":"https://api.github.com/users/Reonekot","html_url":"https://github.com/Reonekot","followers_url":"https://api.github.com/users/Reonekot/followers","following_url":"https://api.github.com/users/Reonekot/following{/other_user}","gists_url":"https://api.github.com/users/Reonekot/gists{/gist_id}","starred_url":"https://api.github.com/users/Reonekot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Reonekot/subscriptions","organizations_url":"https://api.github.com/users/Reonekot/orgs","repos_url":"https://api.github.com/users/Reonekot/repos","events_url":"https://api.github.com/users/Reonekot/events{/privacy}","received_events_url":"https://api.github.com/users/Reonekot/received_events","type":"User","site_admin":false},"created_at":"2016-06-03T10:18:24Z","updated_at":"2016-06-03T10:18:24Z","body":"Currently I'm not sure I do - but I anticipate that we'll have components (internal Nuget packages) that will follow the above pattern, which should be registered with SimpleInjector and I'm not sure how to handle this, without having the components depend on SimpleInjector. I don't want to force a dependency on SimpleInjector on the rest of company, if they want to use the same components. Maybe I'm missing an obvious way to do that...\r\n\r\nI have the same problem with SaasKit.Multitenancy, which has a similar registration model:\r\nhttps://github.com/saaskit/saaskit/blob/master/src/SaasKit.Multitenancy/MultitenancyServiceCollectionExtensions.cs\r\n\r\nI'm not 100% sure, but I assume I can get away with just adding this to the SimpleInjector container, but then I need to make either a SaasKit.Multitenancy.SimpleInjector package (I assume SaasKit has a StructureMap package for this reason, but haven't looked at it) or copy the registration code into my own project. (Which might miss updates made on the official version of AddMultitenancy().)\r\n\r\nSo this isn't about registering the services in both containers, but about that the components shouldn't care and currently are exposing IServiceCollection to wire up the components."}}
{"actor":{"display_login":"Reonekot"}}