OpenTelemetry.Extensions.Logging in .NET: Why the NuGet Package Is Missing and What to Use Instead

If you have tried to add OpenTelemetry.Extensions.Logging to a .NET project, you already know how this ends. The restore fails, NuGet tells you the package cannot be found, and you start second-guessing whether your package source is broken. It is not. The reason dotnet add package OpenTelemetry.Extensions.Logging fails is simple and slightly maddening: that package has never existed on nuget.org. It is one of the most searched-for phantom packages in the .NET observability ecosystem, and almost everyone who looks for it is one small naming assumption away from the real answer.

I have watched this exact detour eat an afternoon on more than one team. Someone wires up traces and metrics in twenty minutes, then hits a wall trying to find "the logging one" because every other piece of the puzzle followed a predictable naming pattern. If you want the full observability stack assembled rather than a single fix, the annotated production setup lives on Patreon, wired end to end with exporters, resource attributes, and the sampling decisions that matter once real traffic hits.

Getting logging right is really about knowing how it sits next to metrics, tracing, and health checks in the same pipeline. Chapter 14 of the Zero to Production course builds exactly that: structured logging, OpenTelemetry traces and metrics and logs, and Kubernetes-aware health endpoints, all inside one running ASP.NET Core API so the wiring is never abstract.

What the Error Actually Says

When you run the command, NuGet returns an NU1101:

error NU1101: Unable to find package OpenTelemetry.Extensions.Logging.
No packages exist with this id in source(s): nuget.org

The wording matters here. NU1101 is not "the version you asked for is unavailable" and it is not "the feed is unreachable". Per the official NuGet error reference, it means no package with that id exists in any configured source. When nuget.org is listed in your sources and you still get NU1101, the package id itself is wrong.

This is worth internalising, because the usual NU1101 advice sends you down the wrong path. Most search results for this error talk about missing feeds, offline Visual Studio package sources, or V2 versus V3 endpoints. Those are real causes in corporate environments. None of them apply here. Running dotnet nuget list source and adding https://api.nuget.org/v3/index.json will not conjure up a package that was never published.

Why Does OpenTelemetry.Extensions.Logging Not Exist?

Because OpenTelemetry .NET ships its ILogger integration inside the core OpenTelemetry SDK package rather than in a separate logging package. There is no dedicated logging package to install, so the id you are searching for was never created.

That single design decision breaks the naming symmetry developers expect. The ecosystem trains you to assume otherwise:

What you expect	What actually exists
OpenTelemetry.Extensions.Logging	Does not exist
OpenTelemetry.Extensions.Hosting	Exists, stable (1.17.0)
OpenTelemetry.Extensions	Exists, pre-release only
OpenTelemetry.Instrumentation.AspNetCore	Exists, stable
OpenTelemetry.Exporter.OpenTelemetryProtocol	Exists, stable

Every other slot in that table resolves to a real package. Logging is the one that does not, and it is the one people reach for first.

The Three Reasons Developers Search for This Package

Cause 1: Pattern Matching the Microsoft.Extensions.Logging Convention

This is the dominant cause, and it is an entirely reasonable inference. In .NET, logging providers follow a rigid convention: Microsoft.Extensions.Logging, Microsoft.Extensions.Logging.Console, Microsoft.Extensions.Logging.Debug, Serilog.Extensions.Logging, NLog.Extensions.Logging. Serilog and NLog both publish a *.Extensions.Logging bridge package, so when you go looking for the OpenTelemetry equivalent, OpenTelemetry.Extensions.Logging is the obvious guess.

It is a good guess. It is just wrong. OpenTelemetry chose to fold the ILoggerProvider implementation into the SDK itself instead of shipping a bridge package.

Cause 2: Confusing It With OpenTelemetry.Extensions

There is a package called OpenTelemetry.Extensions, currently at 1.17.0-beta.1, and this trips people up in both directions. Some developers half-remember it and search for the longer name. Others find it, assume it is the logging package with a truncated name, and install it expecting ILogger export.

It is not that package. OpenTelemetry.Extensions is a contrib package of extras that sit outside the OpenTelemetry specification: log processors that attach logs to activities as events or copy baggage entries onto log records, plus tracing helpers like AutoFlushActivityProcessor, BaggageActivityProcessor, and RateLimitingSampler. Genuinely useful once you are past the basics, but it enriches telemetry that is already flowing. Install it before the core wiring exists and you get no logs at all, which sends you back to searching.

Note that it is pre-release only. If your build pipeline blocks prerelease packages, as most production pipelines should, it will not restore even with the correct id.

Cause 3: Following a Tutorial Written Against an Older Layout

OpenTelemetry .NET moved fast through its beta years, and package boundaries shifted along the way. Blog posts and Stack Overflow answers from that era reference package names and registration calls that no longer map cleanly onto the current SDK. A snippet that was accurate in 2022 can now leave you hunting for an id that was reorganised long ago.

The tell is usually the registration code, not the package list. If a tutorial calls anything other than AddOpenTelemetry on the logging builder or the service collection, treat the whole snippet as suspect.

The Packages You Actually Need

For an ASP.NET Core API on .NET 10 exporting logs over OTLP, this is the real list:

<PackageReference Include="OpenTelemetry.Extensions.Hosting" Version="1.17.0" />
<PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.17.0" />

That is it for logging. OpenTelemetry.Extensions.Hosting pulls in the core OpenTelemetry package transitively, and the core package is what carries the ILogger integration and the AddOpenTelemetry extension method on ILoggingBuilder. You do not reference a logging package because there is nothing separate to reference.

Add instrumentation packages only for the signals you want:

<PackageReference Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.17.0" />
<PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.17.0" />

Those two cover incoming requests and outgoing HttpClient calls, and they affect traces and metrics rather than logs.

How to Wire Up OpenTelemetry Logging Correctly

The registration lives on builder.Logging, not on the OpenTelemetry builder:

builder.Logging.AddOpenTelemetry(logging =>
{
    logging.IncludeFormattedMessage = true;
    logging.IncludeScopes = true;
});

Both of those options are off by default and both are worth turning on. IncludeFormattedMessage preserves the rendered message text alongside the structured fields. IncludeScopes carries BeginScope values through to the exported log record, which is what makes correlation ids and tenant ids actually show up in your backend rather than vanishing at the export boundary.

Then register the OTLP exporter alongside your metrics and tracing:

builder.Services.AddOpenTelemetry()
    .WithMetrics(m => m.AddAspNetCoreInstrumentation())
    .WithTracing(t => t.AddAspNetCoreInstrumentation())
    .UseOtlpExporter();

UseOtlpExporter() applies the OTLP exporter to every signal that is configured, logs included, and reads its endpoint from the standard OTEL_EXPORTER_OTLP_ENDPOINT environment variable. Microsoft's OTLP and Aspire Dashboard walkthrough shows the same shape end to end if you want a running reference.

There is also a newer builder-style form that keeps all three signals in one chain:

builder.Services.AddOpenTelemetry()
    .WithLogging()
    .UseOtlpExporter();

WithLogging() registers the OpenTelemetry ILoggerProvider and enables the ILogger integration directly, so it replaces the builder.Logging.AddOpenTelemetry(...) call rather than supplementing it. Pick one style and stay with it. Mixing both in the same application is the fastest way to end up debugging duplicate log records.

One caveat that has cost me real time: AddOpenTelemetry on the service collection is intended for application host code only, and repeated calls do not create additional providers. If you call it from a library or a shared extension method and expect an isolated provider, you will not get one.

How to Avoid This Whole Class of Error

The general lesson is worth more than the specific fix. Before spending time debugging a restore failure, check whether the package id is real at all. Open https://www.nuget.org/packages/<PackageId> in a browser. A 404 means the id is wrong, and no amount of feed configuration will change that. That single check separates "the package does not exist" from "my sources are misconfigured" in about five seconds, and those two problems have nothing in common.

It is also worth being deliberate about where logging fits in your telemetry pipeline overall. If you are still deciding between provider stacks, our breakdown of Serilog vs NLog vs ILogger for structured logging covers that trade-off, and the complete OpenTelemetry guide for ASP.NET Core walks the full traces, metrics, and logs setup rather than just the logging slice.

Frequently Asked Questions

Is OpenTelemetry.Extensions.Logging deprecated or was it renamed?

Neither. It was never published under that id, so there is nothing to deprecate and no rename to trace. The ILogger integration has always lived in the core OpenTelemetry SDK package. If a tutorial references OpenTelemetry.Extensions.Logging, the author almost certainly wrote the name from memory using the Microsoft.Extensions.Logging convention rather than copying it from a working project file.

Which NuGet package do I install for OpenTelemetry logging in .NET?

Install OpenTelemetry.Extensions.Hosting plus an exporter such as OpenTelemetry.Exporter.OpenTelemetryProtocol. The hosting package brings in the core OpenTelemetry package transitively, and that core package provides the AddOpenTelemetry extension method on ILoggingBuilder. There is no separate logging package to add.

What is the difference between OpenTelemetry.Extensions and OpenTelemetry.Extensions.Hosting?

OpenTelemetry.Extensions.Hosting is a stable package that manages provider lifecycle in ASP.NET Core and Generic Host applications, and it is the one you almost certainly want. OpenTelemetry.Extensions is a pre-release contrib package of optional extras outside the OpenTelemetry specification, including baggage log processors and a rate-limiting sampler. Neither one is required to make basic ILogger export work, but the hosting package is the normal starting point.

Why does NU1101 still appear after I add nuget.org as a package source?

Because NU1101 reports that no package with that id exists in any configured source, which is a different failure from an unreachable or missing feed. Adding sources fixes the corporate-feed variant of this error. It cannot fix a package id that was never published. Verify the id on nuget.org first, then investigate sources.

Do I need OpenTelemetry.Instrumentation.AspNetCore to export logs?

No. That package instruments incoming HTTP requests to produce traces and metrics. Log export works without it. Add it when you want request spans and ASP.NET Core metrics alongside your logs, which in a production API you usually do, but it is not a dependency of the logging pipeline.

Can I use Serilog and OpenTelemetry logging at the same time?

Yes, and it is a common production setup. Serilog handles enrichment and local sinks while OpenTelemetry exports to your observability backend over OTLP. The thing to watch is double-writing: if both stacks are configured to emit to the same destination, you will pay twice for the same log line and see duplicates in your backend. Decide which layer owns the export path before wiring both.

---

About the Author

I'm Celin Daniel, Co-founder of Coding Droplets. I've been building .NET and ASP.NET Core systems in production for 13+ years - APIs, distributed backends, enterprise platforms. Everything I write here comes from real shipping experience: patterns that held up, trade-offs that bit us, and lessons learned the hard way.

• GitHub: codingdroplets

• YouTube: Coding Droplets

• Website: codingdroplets.com