Related to #2852 and #2828

Just spent a good few days trying to figure out why App Insights was not working until I finally discovered it is because I added some keyed services.
I think this should be fixed with the highest priority.

We worked around it by registering application insights BEFORE any other (keyed) services. In our case that was Orleans 8

The root cause is at this line which fails if any keyed service is added to the service collection at the time. What needs to be done is to first check if the service is a keyed service.

Anyway, there is another place that might be discussed. It effectively swallows any exception and makes debugging incredibly difficult. Could we possibly change the function to throw and let its caller to decide if it's safe to swallow the exception or not?

We have had the same issue. App Insights just silently stopped working due to a new dependency being used.

See: #5421

Same here, spent two days trying to figure out what the issue was.
When we commented out the KeyedService everything works fine.

We worked around it by registering application insights BEFORE any other (keyed) services. In our case that was Orleans 8

Thanks! This workaround does work for me.

I had the same issue and it was only surfaced because of Scrutor uses KeyedServices for the decorator pattern starting with version 5 (released September 25).
Just for the next one struggling with AI and Scrutor to find.

For my own reproes of this, the culprit appears to be this method:

o.ImplementationInstance is null for my keyed services. I believe it would be a quick change to at least tolerate such cases by adding some defensiveness:

internal static void AddSingletonIfNotExists<TService, TImplementation>(this IServiceCollection services)
    where TService : class
    where TImplementation : class, TService
{
-    if (!services.Any(o => o.ImplementationFactory == null && typeof(TImplementation).IsAssignableFrom(o.ImplementationType ?? o.ImplementationInstance.GetType())))
+    if (!services.Any(o => o.ImplementationFactory == null && typeof(TImplementation).IsAssignableFrom(o.ImplementationType ?? (o.ImplementationInstance is not null ? o.ImplementationInstance.GetType() : null))))
    {
        services.AddSingleton<TService, TImplementation>();
    }
}

That's probably not the cleanest way, but I just wanted to share the general idea.

We worked around it by registering application insights BEFORE any other (keyed) services. In our case that was Orleans 8

It worked, or at least I thought. It stopped throwing the exception, but nothing was being sent to my app insights
Can't believe it's been so long with this problem still

Any update on this. Just spent hours to find out this was the issue. Any chance there's a fix in a preview version?

For my own reproes of this, the culprit appears to be this method:

ApplicationInsights-dotnet/NETCORE/src/Shared/Extensions/ApplicationInsightsExtensions.cs

Lines 293 to 301 in e34286b

internal static void AddSingletonIfNotExists<TService, TImplementation>(this IServiceCollection services)
where TService : class
where TImplementation : class, TService
{
if (!services.Any(o => o.ImplementationFactory == null && typeof(TImplementation).IsAssignableFrom(o.ImplementationType ?? o.ImplementationInstance.GetType())))
{
services.AddSingleton<TService, TImplementation>();
}
}
o.ImplementationInstance is null for my keyed services. I believe it would be a quick change to at least tolerate such cases by adding some defensiveness:

internal static void AddSingletonIfNotExists<TService, TImplementation>(this IServiceCollection services)
where TService : class
where TImplementation : class, TService
{

• if (!services.Any(o => o.ImplementationFactory == null && typeof(TImplementation).IsAssignableFrom(o.ImplementationType ?? o.ImplementationInstance.GetType())))

• if (!services.Any(o => o.ImplementationFactory == null && typeof(TImplementation).IsAssignableFrom(o.ImplementationType ?? (o.ImplementationInstance is not null ? o.ImplementationInstance.GetType() : null))))
  {
  services.AddSingleton<TService, TImplementation>();
  }
  }
  That's probably not the cleanest way, but I just wanted to share the general idea.

Just spent my afternoon tracking down what was going on and traced it down to this line as well, you are on the right track.