Keyed Services Not Supported in Azure Functions
A while ago I was working on an Azure function application, and ran into a very weird problem. Suddenly I started getting a pretty confusing error, that actually pointed me away from the correct solution. The error I got was the following.
Expecting the instance to be stored in singleton scope, but unable to find anything here.
Likely, you've called UseInstance from the scoped container, but resolving from another container or injecting into a singleton.If you are looking for a solution to a similar error, you’ve come to the right place.
Initial Troubleshooting
In my function application, I have quite a few services registered. Many of them depend on other services. So at first I thought that this is an easy case, and I have tried to inject a scoped or transient service into a singleton service. So I started to dig deeper into my dependency chains for my services. But even after digging around for several hours, I could not find anything that would help me solve the problem. Finally I ended up registering all my services as singleton services, just to make sure that I am not injecting a scoped service into a singleton service. Guess what, I still got the same error.
Reproducing the Problem
Before I reveal the solution, which you probably already guesses from the title of this article, I’ll talk a bit about how to reproduce the problem. I’ve created a Github repository that contains code that demonstrates how you can reproduce this problem.
Note! This problem affects only Azure function applications that use the in-process worker model. Isolated worker model is not affected. So, this problem will probably go away during the coming year, since the in-process worker model will run out of support in November 2026.
One of the things that made this so tricky for me to resolve was that fact that I did not need keyed services in my application. I just used another library that we use in many different kinds of applications, which itself registers keyed services. If I would have injected a keyed service into my functions class using the FromKeyedServicesAttribute attribute, or requested a keyed service using the IServiceProvider.GetKeyedService method, I would have gotten a much more descriptive error message, such as the one below.
Anonymously Hosted DynamicMethods Assembly: This service provider doesn't support keyed services.That would have immediately told me where the actual problem is instead of pointing me in the wrong direction trying to find conflicts in my service scopes.
Below is the Configure method from the Startup class in my in-process function app that works.
public override void Configure(IFunctionsHostBuilder builder)
{
builder.Services
.AddSingleton<SharedServices.MiscService>();
}
The code below adds one keyed service of the same type as is already in use by the application as a “normal” registered service. This code will throw the exception described in the introduction of this article. Even if you don’t even use the keyed service.
public override void Configure(IFunctionsHostBuilder builder)
{
builder.Services
.AddSingleton<SharedServices.MiscService>()
.AddKeyedSingleton<SharedServices.MiscService>("foo")
;
}
The Problem – Keyed Services
As you probably guessed, the cause for the problem was keyed services. The in-process worker model in Azure functions does not support keyed services. I am writing this article in September 2025. Support for the in-process worker model will run out of support in November 2026. So I don’t expect this to be fixed in the in-process worker model. It is not a security related or otherwise a critical problem. As you can see from my code sample, this is not a problem in isolated worker model. I guess the official story is that if you need keyed services, you need to migrate to isolated worker model.
Further Reading
Over the years, I’ve come across several problems with Azure functions that have been quite tricky to resolve. You can read more about them in my other Azure functions articles.
0 Comments