Automapper: Cannot consume scoped service 'AutoMapper.IMapper' from singleton service

[adnan-kamili]

Hi,

I recently changed some service types from being transient to singleton, which caused automapper to throw error:

Cannot consume scoped service 'AutoMapper.IMapper' from singleton service
The error is clear enough, but I wonder why Automapper is a scoped service and not a singleton. It doesn't contain any state information.

Is there any way to register it as singleton or that will create issues. I am using .Net Core 2.0

Version: x.y.z

6.1.1

[jbogard]

Singleton can’t consume scoped services. Change your singleton to scoped.

IMapper is marked scoped because anything that depends on a factory should
be scoped as the Mapper class does. The configuration is singleton, because
it does not create other things. Mapper depends on the configuration, so
scoped can depend on singletons but not the other way.

On Fri, Mar 16, 2018 at 10:44 PM Adnan Kamili [e-mail]
wrote:

Hi,

I recently changed some service types from being transient to singleton,
which caused automapper to throw error:

Cannot consume scoped service 'AutoMapper.IMapper' from singleton service
The error is clear enough, but I wonder why Automapper is a scoped server
and not a singleton. It doesn't contain any state information.

Is there any way to register it as singleton or that will create issues. I
am using .Net Core 2.0
Version: x.y.z

6.1.1

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2569, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMu9bcnP1YXP5viEryrPDkdQoqYE-ks5tfIa5gaJpZM4Sup25
.

[adnan-kamili]

Thanks for clarifying.

[michael-freidgeim-webjet]

@jbogard , could you please explain(or provide a link) why "anything that depends on a factory should
be scoped"?

[jbogard]

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.0#service-lifetimes-and-registration-options

On Fri, May 4, 2018 at 7:51 PM, michael-freidgeim-webjet <
[email protected]> wrote:

@jbogard https://github.com/jbogard , could you please explain(or
provide a link) why "anything that depends on a factory should
be scoped"?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2569#issuecomment-386767346,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMt4u2Nm1aiRuQOG_vLn2h3-H844rks5tvPeagaJpZM4Sup25
.

[ChristianSauer]

Honestly I think this is a bad decision - I am constantly running into this problem and it's just annoying as hell

[jbogard]

@ChristianSauer it's not a decision that was or was not made, it's a fundamental design constraint. You can't have singletons depend on transients or scoped items. It's not a fault of the container, those lifecycles are incompatible. If you want compatible lifecycles, choose different lifecycles.

Singleton <- Singleton GOOD
Singleton <- Scoped BAD
Singleton <- Transient BAD
Scoped <- Singleton GOOD
Scoped <- Scoped GOOD
Scoped <- Transient GOOD
Transient <- Singleton GOOD
Transient <- Scoped GOOD inside a scope, BAD outside a scope
Transient <- Transient GOOD

So really there's only 2 scenarios that are "always bad", and one scenario that is "sometimes bad".

ASP.NET Core DI makes this pretty explicit, even passing factory methods into context objects for things like filters. A filter is Singleton, so you can't have constructor dependencies. Instead, you use the various XyzContext objects passed in to the filter methods to resolve dependencies.

[HalidCisse]

I'm using this inside a generic hosted job.

[jholovacs]

The reference is for ASP.NET Core, but AutoMapper is not dependent on ASP.NET Core. There is no reason to have a scoped life cycle for a .NET Core console app that relies on a factory, is there? This is a bad idea, based off a bad reason, and has a leaky abstraction smell. If ASP.NET Core standards should have it as scoped, then it should be made scoped only for ASP.NET Core... not for every application.

[jbogard]

FYI the MS Extensions DI is explicitly designed for ASP.NET Core and
nothing else. As the other container authors can attest, it is an enormous
leaky abstraction, with behaviors that only exist because ASP.NET Core
needs them, and PRs that get rejected to add behaviors because ASP.NET Core
wouldn’t use them. See my currently open PR in the DI repo as an example.

I’m assuming this will change as other frameworks start to use the MS DI
and run into similar scenarios. Right now for example to include
AppInsights in a Worker I have to reference all of ASP.NET Core.

On Mon, Apr 22, 2019 at 3:03 PM Jeremy Holovacs [e-mail]
wrote:

The reference is for ASP.NET Core, but AutoMapper is not dependent on
ASP.NET Core. There is no reason to have a scoped life cycle for a .NET
Core console app that relies on a factory, is there? This is a bad idea,
based off a bad reason, and has a leaky abstraction smell. If ASP.NET
Core standards should have it as scoped, then it should be made scoped only
for ASP.NET Core... not for every application.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2569#issuecomment-485533431,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMVWLHDOCQWOE5D6IWDPRYKXZANCNFSM4EV2TW4Q
.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.