dd-trace-dotnet: the Datadog tracer and continuous profiler for .NET

Two separate products in one repository

The repository holds the sources for the client-side components of the Datadog product suite for Application Telemetry Collection and Application Performance Monitoring for.NET applications, and it contains two distinct pieces of software.

The Datadog.NET Tracer is a set of.NET libraries that let you trace any piece of your.NET code. It automatically instruments supported libraries out of the box and also supports custom instrumentation to instrument your own code. The Datadog.NET Continuous Profiler is a separate set of libraries that automatically profile your application.

The reason they live together is what they share. The library powers Distributed Tracing, Application Security Management, Continuous Integration Visibility, Dynamic Instrumentation and more, which is a broader scope than tracing alone, and a profiler attached to the same runtime as the tracer gets the same service and version tagging, so a slow frame can be correlated with the request that caused it.

The primary language is C#, the licence is Apache-2.0, the default branch is master, and the homepage for the product documentation is https://docs.datadoghq.com/tracing/. The recent releases are 3.56.0 from 2026-10-19, 3.55.2 from 2026-10-15 and 3.55.1 from 2026-10-09, and the last push was on 2026-10-22, so the release cadence is a matter of days rather than months.

What you download, and the two distribution channels

The downloads table has three rows and they correspond to three different decisions.

Windows and Linux Installers come from the GitHub releases page, as a single archive containing the native components.

The Datadog.Trace package is on NuGet, and so is Datadog.Trace.OpenTracing. The second one exists for the OpenTracing API, and the repository topics list opentracing among the tags, so the OpenTracing compatibility layer is still a first-class part of the distribution rather than a historical leftover.

The two channels are not interchangeable. The NuGet package is how the managed libraries reach your application, and the installer is how the native profiler agent and its native dependencies get onto the machine. A .NET application that wants automatic library instrumentation and a continuous profiler needs both, and the documentation for local development points at the setup docs in the tracer directory for the specifics.

The OpenTracing package is the option for code that is already written against the OpenTracing API, which is a useful migration path for a codebase that has moved from another tracer.

Automatic instrumentation, and the custom path when it is not enough

The two modes of use are the practical difference between a tracer you turn on and a tracer you build around.

Automatic instrumentation is the default path. The tracer instruments supported libraries out of the box, which means that if you use a supported HTTP client, database driver or messaging library, the spans appear without you writing a line. This is what makes the adoption cost low: the work is adding the package and setting the connection details, not annotating every call site.

Custom instrumentation is the escape hatch, and it is where the library's own API lives. You instrument your own code by wrapping the method you care about, and that is the pattern you use for domain operations that no library instrumentation can see, such as a business rule or a queue consumer of your own.

The trade-off is the usual one. Automatic instrumentation gives broad coverage of the code you did not write, which is where most of the unknown latency lives, and it gives you spans you did not have to think about. Custom instrumentation gives you exactly the spans you asked for and nothing else, and it costs you code and review. The right answer is usually both, with automatic instrumentation as the floor and custom spans added where a product owner will ask a question about the numbers.

One thing to plan for is version coverage. The README does not list which library versions are supported in the visible text, so that list is something to check in the documentation before you promise coverage of a particular stack.

The continuous profiler and the native side of the tracer

The profiler is a separate product that happens to share a repository, and it deserves to be understood on its own terms. The libraries automatically profile your application, which means sampling a running process rather than instrumenting it.

That difference has practical consequences. A profiler that samples the stack periodically has almost no startup cost and negligible runtime overhead, which is why it can be left on in production, and it gives you the hot path without you knowing in advance which path would be hot. A tracer that instruments gives you a distributed view with the request context attached, and it tells you which call was slow in the context of a particular request.

Running both is the point of the shared repository, and it is the reason the installers matter. The native components are what sample the process, and the repository tree shows how much of it there is. There are separate solution files for the profiler, the native parts, the OSX build, the debugger, the minimal build and the security build, which tells you that different pieces ship to different platforms and different products.

The tree also shows the native build system directly. There is a CMakeLists.txt, a vcpkg-configuration.json for the C++ dependencies, a .clang-format file, and a docker/ directory with several compose files, including docker-compose.serverless.yml and docker-compose.windows.yml, alongside a .devcontainer/ directory.

The test environment is a wall of emulated services

The docker-compose.yml in the repository root is the most revealing file in the tree, because it shows exactly what the integration tests need running.

  localstack_arm64:
    image: localstack/localstack:4.14.0@sha256:3ebc37595918b8accb852f8048fef2aff047d465167edd655528065b07bc364a
    environment:
      - SERVICES=sns,sqs,kinesis,dynamodb,events,s3,stepfunctions,lambda
      - DEBUG=1
      - DATA_DIR=/tmp/localstack/data
      - DEFAULT_REGION=us-east-1
    ports:
      - "4566:4566"

LocalStack stands in for a large slice of AWS, with sns, sqs, kinesis, dynamodb, events, s3, stepfunctions and lambda enabled, which matches the list of libraries the tracer instruments. The other services in the file are older datastores used as instrumentation targets, each pinned by digest: elasticsearch 7.10.1, mongo 5.0.31, mysql-server 8.0, postgres 10.5-alpine, rabbitmq 3-management and redis 4-alpine.

Two details show the care taken. Every image is pinned by sha256 digest rather than by tag, so a rebuild does not silently pick up a different base image. And every service name carries the _arm64 suffix, with the comment that they are ARM64 dependencies, so the test suite runs the same way on Apple silicon and on x86.

This is also a warning about the project's own testing scope. The tracer is verified against local emulations of these services, not against AWS itself, so a behaviour that depends on a subtle detail of a real service is not something this suite would have caught.

Where this is the wrong choice

There are three limits, and the first is a strategic one rather than a technical one.

The first is that this is a vendor client. The data model, the configuration keys, the service naming and the span semantics are Datadog's, and the emitted data is consumed by the Datadog platform. If your goal is open, portable telemetry, the alternative is the OpenTelemetry SDK for.NET, where the tracer is one implementation among several and the backend is your choice. The Datadog.Trace.OpenTracing package in this repository shows the vendor is not closed to that world, but the product you install here is still pointed at one backend.

The second is that the profiler is a native component. Automatic instrumentation of your own.NET code is pure managed code in a NuGet package, but the continuous profiler needs the native agent installed on the machine, which means an installer, a service, and a process that sits next to your application. On a locked-down environment, a container image or a platform where you cannot install a native service, that changes the deployment story, and the NuGet package alone will not give you profiling.

The third is the operational surface. The repository is large and has many solution files, several compose files, a.nuke/ directory for build automation, a shared/ directory, a tools/ directory, static analysis configuration and its own AGENTS.md and CLAUDE.md files. A project of that shape is maintained by a team with the tooling to keep it moving, which is reassuring for support but means the contribution surface is not one you pick up in an afternoon.

On the licensing question, the repository is Apache-2.0 with the licence information in the LICENSE file, and there is a separate LICENSE-3rdparty.csv and a NOTICE file for the third-party components the native build pulls in. For a commercial application, the Apache-2.0 grant on your own code is straightforward; the third-party list is where a careful review belongs, since the native profiler links against libraries that carry their own terms.

Security issues are handled through a direct address to the security team rather than a public issue, and other feedback goes through the support channel.

Editorial conclusion

Adopt dd-trace-dotnet if you already send.NET telemetry to Datadog or want to start, since the tracer and the profiler are the supported client path for that platform. Do not adopt it if you are after vendor-neutral tracing, since the data model and the configuration are Datadog's. Before you turn it on, check which library versions the automatic instrumentation covers, and note the last push was on 2026-10-22 with release 3.56.0 on 2026-10-19.

Frequently asked questions

Official sources

1. DataDog/dd-trace-dotnet on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases