ApplicationInsights-dotnet: the Azure Monitor client rebuilt on OpenTelemetry

What the SDK is and where the data ends up

This is the .NET SDK for sending data to Azure Monitor and Application Insights. That sentence is the whole product description, and it is worth being precise about what it means, because the SDK is a client, not a platform.

The library collects telemetry inside a .NET process and transmits it to the Azure Monitor service, where Application Insights is the application-centric view over that data. The code is C#, the licence is MIT, and the package names follow the Microsoft.ApplicationInsights convention.

That scope has an important consequence for anyone evaluating it. There is no storage, no dashboard and no query engine in this repository. What lives here is the collection layer inside your process, the configuration that decides what to collect, and the channel that ships it to Azure. If the data is going to end up somewhere other than Azure, the interesting part of this design has to be replaced, and the 3.x rewrite is what makes that replacement possible.

The repository is organised around that distinction. There are separate directories for the ASP.NET and ASP.NET Core paths, a NETCORE directory, a BASE directory for the core API, a LOGGING directory for the NLog adapter, a WEB directory, plus docs, examples, troubleshooting guidance and a skills folder.

The 3.x rewrite puts OpenTelemetry underneath everything

The change that defines the current line is architectural. The SDK now uses OpenTelemetry as the underlying telemetry collection framework, with the Azure Monitor Exporter for transmission.

That has three consequences, and they pull in different directions.

The first is that collection is no longer proprietary. You can extend telemetry collection using standard OpenTelemetry patterns, with Activity Processors, Resource Detectors and custom instrumentation, rather than through a Microsoft specific extension point. The second is that the SDK fits into the wider OpenTelemetry ecosystem, which means telemetry can be sent to multiple backends rather than only to Azure. The third is that the old API surface moved, which is why the repository carries a BreakingChanges.md file describing what changed between 2.x and 3.x, and a separate MigrationGuidance.md with detailed migration instructions.

For a team already running OpenTelemetry, the third point is mostly a cost. The 2.x SDK had its own pipeline, its own initialisation and its own configuration, and moving to 3.x means deleting some of that and reusing the instrumentation you already have.

For a team starting fresh, the rewrite is a benefit with no migration attached. The collector is a standard OpenTelemetry pipeline, the destination is a standard exporter, and the Azure specific layer is thinner than it used to be.

Four packages, and picking the one that fits your application

The quick start is organised as a decision tree rather than a single install command, which is a good sign about the shape of the product. Four situations are listed.

For an ASP.NET Core web application, the ASP.NET Core SDK provides automatic instrumentation, published as Microsoft.ApplicationInsights.AspNetCore. For a worker service, console app or background service, the Worker Service SDK is the simplified route, published as Microsoft.ApplicationInsights.WorkerService. For a custom scenario that needs the core TelemetryClient API, the base SDK is the one to use, published as Microsoft.ApplicationInsights. And for a team that needs compatibility with NLog, the Logging SDK is published as Microsoft.ApplicationInsights.NLogTarget.

The ASP.NET path for the older stack is published as Microsoft.ApplicationInsights.Web, and the README states that customers are encouraged to use the latest stable version, because that is the version that receives fixes and updates.

The packages are published from this repository, so the source you read and the binary you install are the same artefact. The example projects make the choice concrete: the examples directory holds an AspNetCoreWebApp, a ClassicAspNetWebApp, a BasicConsoleApp, a ConsoleApp, a WorkerService, a BackgroundTasksWithHostedService, an NLogConsoleApp and a .NET Config File example, all tied together in an Examples.sln.

One warning belongs with the package table. Beta packages are not recommended for production use and support is limited, and when a new stable version is released the old beta packages are unlisted and the old minor version is marked as deprecated.

A portable skill that sets the SDK up for you

The repository ships a setup assistant of a kind that was rare two years ago. The skills/applicationinsights-setup folder contains a portable AI skill that guides developers through setting up, migrating or enhancing Application Insights, and it is written to work with Claude Code, Cursor, GitHub Copilot, Codex and other AI agents.

The install step for Claude Code is a single copy of that directory into the skills folder of the agent configuration.

cp -r skills/applicationinsights-setup ~/.claude/skills/

After that, the intended interaction is a plain sentence, add Application Insights to my app, and the skill detects the application type and produces step by step guidance. AGENTS.md carries the installation instructions for the other agents.

Two things are worth saying about this. The first is that it is scoped to setup, migration and enhancement, which is a sensible boundary for a skill file, and it does not attempt to be a general reference for the SDK. The second is that a skill file is a set of instructions, so the quality of the guidance is bounded by the documentation it was written from, and the concepts it leans on live in docs/concepts.md.

For a team onboarding several developers onto the SDK at once, this is a legitimate way to standardise the first hour of setup, and it is also a quick way to find out which of the four packages the assistant thinks your application needs.

How the repository is laid out for a multi target SDK

The top level looks like a large product, and the structure explains why.

There is a BASE directory for the core SDK, a NETCORE directory holding the .NET Core and .NET 5 and later work, a LOGGING directory for the logging adapters, a WEB directory for the classic ASP.NET path, and separate directories for the ASP.NET Core auto collectors. Alongside them sit docs, examples, troubleshooting guidance and the skills folder.

The build infrastructure is just as visible. There is an Everything.sln solution, plus Everything.Linux.slnf and Everything.Windows.slnf filtered solutions for the two platforms, a Directory.Build.props and a Directory.Packages.props for central package version management, a NuGet.config, an EnlistmentRoot.marker for the older enlistment based build, a ProjectsForSigning.sln for the signing pipeline, and .pipelines, .scripts, .config, .props and .rulesets directories.

The .publicApi directory is the one to notice if you care about compatibility. It is the place where a public API surface is recorded, which is what makes a break in that surface visible in review rather than in production. Combined with BreakingChanges.md and MigrationGuidance.md at the root, the project takes the 2.x to 3.x transition seriously enough to document it in three places.

The other root files are the usual ones for a Microsoft repository: CHANGELOG.md, SECURITY.md, a licence, a contribution guide, AGENTS.md and a readme.

Where the SDK is the wrong choice

The limits here are about coupling and about the migration, and they are not small.

The first is the Azure coupling. Even in the OpenTelemetry based 3.x line, the transmission path is the Azure Monitor Exporter, and the support path is Azure. The project asks that support requests for the Application Insights .NET SDK be filed as an Azure Support Request through the Azure portal rather than as a GitHub issue, because subscription management, billing support and technical support are all part of an Azure Support Plan. A team that has decided its telemetry should not depend on a cloud vendor will find the OpenTelemetry foundation genuinely useful and the Azure destination still hardwired.

The second is the migration cost. This is a large SDK with a long history, and moving from 2.x to 3.x is a project rather than a package bump, whatever the OpenTelemetry foundation makes easier. Teams that adopted 2.x recently and are happy should stay on the 2.x branch, which the project keeps for the previous release.

The third is scope. There is no trace of a local or self hosted backend, no file based sink, and no dashboard. If what you want is to see your own application's telemetry in a tool you run, this SDK is not the way there.

There is a fourth, smaller trap. Because telemetry collection is often enabled by a one line registration, an application can start sending data to a resource that nobody is watching, and the cost shows up as a bill rather than as an error.

Release cadence, deprecation policy and what the licence covers

The version history shows a project that moved quickly through the 3.x line. Version 3.1.1 was published on 2026-05-08, 3.1.2 on 2026-05-28 and 3.2.0 on 2026-10-12, and the last push to the default branch was on 2026-10-15. The repository is not archived, and main is the branch for all development and releases, with a 2.x branch kept for the previous 2.x release.

Deprecation is handled by a written policy rather than by accident. Application Insights follows the Azure SDK lifecycle and support policy, and the README spells out what that means in practice with a worked example: when 2.20.0 is released, 2.20.0-beta1 is unlisted and 2.19.0 is marked as deprecated. Every release has a matching tag, and the releases and tags pages are linked from the readme.

The licence is MIT, so the code can be read, copied, modified and redistributed, including inside a commercial product, as long as the notice is retained. That is a permissive grant with no copyleft obligation on your own code, and it is not legal advice.

The upgrade path for a team is therefore predictable in shape if not in detail. Move to the latest stable version rather than a beta, expect the previous minor version to be marked deprecated rather than deleted, and keep a 2.x branch in your dependency plan for as long as you have applications that have not migrated.

Editorial conclusion

ApplicationInsights-dotnet is the right tool for a .NET team that already runs on Azure Monitor, especially one moving an existing 2.x application onto the OpenTelemetry based 3.x line, and for a team that wants Azure as the destination while keeping standard OpenTelemetry instrumentation. It is the wrong tool for a team that wants vendor neutral collection with no Azure dependency, since the exporter and the support path are tied to Azure, and for a team starting fresh that has no reason to accept a 2.x to 3.x migration. Before adopting, read BreakingChanges.md and MigrationGuidance.md, confirm which of the four packages your application type needs, and check the Azure SDK lifecycle policy before pinning a version.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/ApplicationInsights-dotnet on GitHub
4. README
5. Releases