[otlp] Remove Grpc.Core Deprecated Package Dependency from OTLP Exporter

[rajkumar-rangaraj]

Background

The current implementation of the OTLP Exporter targets net462 and netstandard2.0 and relies on Grpc.Core, which has been officially marked for deprecation. Continued use of this deprecated package significantly increases security risks, including potential vulnerabilities due to lack of active maintenance and ongoing security updates. Eliminating this dependency is crucial to ensure a secure, maintainable, and reliable implementation moving forward.

Impact

• No Impact to .NET Targets: There is no impact to .NET targets as they currently do not have any direct dependency on Grpc.Core APIs.
• Impact on .NET Framework Applications: .NET Framework applications will lose the ability to send telemetry data via gRPC when using either HTTP or HTTPS URLs. This limitation exists because the .NET Framework lacks built-in or fully supported APIs capable of handling gRPC communication consistently across both secure (HTTPS) and non-secure (HTTP) protocols. Although some packages offer limited HTTPS support, they do not provide comprehensive support for both protocols.

Workarounds

• Use WinHttpHandler:
  Customers can continue using gRPC over HTTPS by leveraging the OpenTelemetry.Exporter.OtlpExporterOptions.HttpClientFactory property. Adding a WinHttpHandler as shown below will enable telemetry data to be sent successfully, but only when using an HTTPS endpoint, such as https://localhost:4317/.

  The WinHttpHandler class is available through the NuGet package System.Net.Http.WinHttpHandler.

  exporterOptions.HttpClientFactory = () => new HttpClient(new WinHttpHandler());

• Stay with an earlier version: Alternatively, customers can continue using a version equal to or lower than OpenTelemetry.Exporter.OpenTelemetryProtocol version 1.11.2 to maintain existing functionality without changes.

SIG Discussion (3/25/2025)

During the SIG meeting on March 25, we discussed this dependency removal, highlighting agreement on prioritizing security by phasing out deprecated dependencies. The consensus was clear about moving forward with this change, acknowledging potential impacts, and providing suitable workarounds.

Runtime Version

net462, netstandard2.0

cc: @open-telemetry/dotnet-maintainers @open-telemetry/dotnet-approvers

[Kielek]

I fully understand the idea of removing deprecated dependency due to lack of support for this package.

1. From the stable OTel specification.

- `grpc` for protobuf-encoded data using gRPC wire format over HTTP/2 connection
- `http/protobuf` for protobuf-encoded data over HTTP connection
- `http/json` for JSON-encoded data over HTTP connection

SDKs SHOULD support both `grpc` and `http/protobuf` transports and MUST
support at least one of them. If they support only one, it SHOULD be
`http/protobuf`. They also MAY support `http/json`.

If no configuration is provided the default transport SHOULD be `http/protobuf`
unless SDKs have good reasons to choose `grpc` as the default (e.g. for backward
compatibility reasons when `grpc` was already the default in a stable SDK
release).

2. There was a decisions that grpc is the default protocol for all supported frameworks.

3. From the versioning part of OTel specification

### Language version support

Each language implementation SHOULD define
how the removal of a supported language/runtime version
affects its versioning.
As a rule of thumb,
it SHOULD follow the conventions in the given ecosystem.

## Long Term Support

![long term support](../internal/img/long-term-support.png)

### API support

Major versions of the API MUST be supported for a minimum of **three years** after the release of the next major API version.
API support is defined as follows.

* API stability, as defined above, MUST be maintained.

* A version of the SDK which supports the latest minor version of the last major version of the API will continue to be maintained during LTS.
Bug and security fixes MUST be backported. Additional feature development is NOT RECOMMENDED.

* Contrib packages available when the API is versioned MUST continue to be maintained for the duration of LTS.
Bug and security fixes will be backported.
Additional feature development is NOT RECOMMENDED.

### SDK Support

SDK stability, as defined above, will be maintained for a minimum of **one year** after the release of the next major SDK version.

### Contrib Support

Contrib stability, as defined above, will be maintained for a minimum of **one year** after the release of the next major version of a contrib package.

From the specification perspective it should be fine to drop the support both for .NET Framework and .NET Standard.

What is the risky part is to manage communication with this breaking change.

The most natural for path is to do all changes directly in OpenTelemetry.Exporter.OpenTelemetryProtocol package. As it is breaking change, it requires version bump to 2.x.y.
It will force us to maintain old package by 1 year from the 2.0.0. It should be limited to the security fixes and the functional fixes.

Alternative approach I can see (IMO it is still breaking change from the end user perspective) is to fully EoL existing package and release new under new name (spliting?). It still requires the same level of support for the 1.x branch for old OTLP package.

---

I think that v2.0.0 version is better path.

• more natural for NuGet (better dicoverability),
• deprecation notices/obsolete attributes (we can consider 1.12.0(?) release with appriopriate changelog nad obsolete attributes. It can be followed by 2.x, even during the same day if needed.

The worst part - technical way how to manage release with diffent versions in the same repository (we have precedence in contrib, and also here for non-stable packages).
One more option, we can follow the [https://github.com/open-telemetry/opentelemetry-js/releases/tag/v2.0.0](OTel JS) pattern and decide to bump all packages from this reposirotu to 2.x (except API).

Any other thoughts? Scenarios to be considered?

---

@open-telemetry/dotnet-instrumentation-approvers, dropping support for GRPC seems to be a breaking change also for Auto Instrumentation and will leads us to 2.0 release.

[RassK]

Some old haunting contradictions I see:

SDKs SHOULD support both grpc and http/protobuf transports and MUST
support at least one of them. If they support only one, it SHOULD be
http/protobuf. They also MAY support http/json.

There was a decisions that grpc is the default protocol for all supported frameworks.

If grpc is poorly supported on .NET FX, I don't see the point to push it further from OTel side. At least spec seems to agree with this, to drop it.

Otherwise SDK has been dropping exporter packages (Jaeger) before without bumping major version. But I guess because grpc was tied to defaults / spec, then it's a more problematic change.

@open-telemetry/dotnet-instrumentation-approvers, dropping support for GRPC seems to be a breaking change also for Auto Instrumentation and will leads us to 2.0 release.

Does it affect us if our default was http/protobuf from the beginning?

[Kielek]

Last SIG notes

• Continue with minor version upgrade
• Make http/protobuf as default for .NET Framework
• If possible, throw exception if default factory with Grpc is used

---

I will bring this discussion for re-consideration #2855.

Nothing change by last 3 years. IMO we are not able to switch default/remove grpc without major bump. It will leads to tons of the issues for the manual usages.

Other, IMO lest important topics for consideration causing some problems for the customer:

• bumping .NET dependencies, even if they are backward compatible: [bug] targets other than net9.0 shouldn't be forced to use 9.0 dependencies #5973
• dropping metrics support for clearly not-supported runtime versions: [Instrumentation.AspNetCore] metrics - cleanup code after dropping support for .NET6 opentelemetry-dotnet-contrib#2360

---

I do not think that bumping this versions is so problematic, we need to maintain only security fixes and potentially important bugfixes by 1 year. OTLP Exporter in 1.11.2 seems to be pretty solid, I hope that we will no need to make any other hotfixes there.

[rajkumar-rangaraj]

Based on the SIG discussion held on April 1, 2025, we decided to proceed with a minor version release (1.12.0) to remove the Grpc.Core dependency in the OTLP exporter. While this change will affect .NET Framework users who explicitly use OtlpExportProtocol.Grpc, the group agreed to treat it as a supportability fix rather than a breaking change requiring a major version bump. The public API remains unchanged, and a supported alternative—HttpProtobuf—is already available for .NET Framework.

The group also agreed to change the default export protocol to HttpProtobuf for .NET Framework. Additionally, we discussed exploring the option of throwing an exception when .NET Framework applications attempt to use the default factory with the Grpc protocol, to make the unsupported usage clear at runtime.

This approach allows us to remove a deprecated and unsupported dependency while continuing to support .NET Framework through safer and maintainable means—all without the disruption of a major version bump.

SIG Notes: https://docs.google.com/document/d/1yjjD6aBcLxlRazYrawukDgrhZMObwHARJbB9glWdHj8/edit?tab=t.0
SIG Recording: https://zoom.us/rec/share/xOwnwj46AlRnUnF9OpTNkkf_mhYeOKlBzztUsFvDPAA2CkZR_xtRmAaTNKir2pO4.dnFWqRm-yo7E7-IK

Introducing a major version would necessitate maintaining both 1.x and 2.x branches in parallel, fragmenting engineering focus and increasing overhead for ongoing development, security updates, and support. Given that this change does not alter public APIs and impacts only a subset of users, the cost of a major version release would be disproportionate to the scope of the actual change.

I do not think that bumping this versions is so problematic, we need to maintain only security fixes and potentially important bugfixes by 1 year. OTLP Exporter in 1.11.2 seems to be pretty solid, I hope that we will no need to make any other hotfixes there.

Thanks for the input. That’s a fair point—and to clarify, we agree that supporting occasional patch releases in the 1.11.x line (e.g., for security fixes or high-impact bugs) is reasonable and does not carry the same long-term cost as maintaining full parallel major versions. As you mentioned, the OTLP exporter in 1.11.2 is in a stable state, and we don’t anticipate frequent patching needs. So maintaining 1.11.x in parallel for essential updates should be manageable without significant overhead.

[pellared]

The public API remains unchanged

Yet the default behavior changes completely, It will basically send the data to a different destination (different endpoint and different protocol). There may be lots of users that depend on this behavior (e.g. have a Colllector that has only an OTLP gRPC receiver).

There is a reason why SemVer stands for "semantic versioning". From https://semver.org/#what-if-i-inadvertently-alter-the-public-api-in-a-way-that-is-not-compliant-with-the-version-number-change-ie-the-code-incorrectly-introduces-a-major-breaking-change-in-a-patch-release:

What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release)?

Use your best judgment. If you have a huge audience that will be drastically impacted by changing the behavior back to what the public API intended, then it may be best to perform a major version release, even though the fix could strictly be considered a patch release. Remember, Semantic Versioning is all about conveying meaning by how the version number changes. If these changes are important to your users, use the version number to inform them.

Introducing a major version would necessitate maintaining both 1.x and 2.x branches in parallel, fragmenting engineering focus and increasing overhead for ongoing development, security updates, and support.

OpenTelemetry values end-user experience over the maintenance experience. I think it would be more valuable to make the software good for the users and seek ways to manage it efficiently. I think it is fine do start working 2.x and create 2.x hot-fix releases only when it is necessary. Maybe it won't be ever needed. Please consider what would be better for the users. From https://opentelemetry.io/community/mission/#we-value-stability:

As many libraries take dependencies on OpenTelemetry APIs, API stability and backwards compatibility is vital for our end-users.