Azure Monitor Telemetry Client — Reinvented

Recently, I was brought on board of yet another project to help build an enterprise-grade IT solution based on Microsoft Power Platform and Azure. Like any well-architected system, the solution required robust observability — the ability to track operational behavior, diagnose issues, and maintain visibility across all components. Naturally, Azure Monitor was the go-to choice. One of the core components of the solution was a custom plugin for Power Platform. To capture application-level telemetry from the plugin, the obvious approach was to use a telemetry client that integrates with Azure Application Insights, a feature of Azure Monitor. By default, Application Insights allows unauthenticated data ingestion — which makes it a potential target for abuse. To address this, the instance was configured to require Entra authentication for secure access. And that’s where things began to fall apart. After investing time trying to integrate both OpenTelemetry with the Azure Monitor Exporter and the legacy Application Insights SDK, it became clear that neither option worked reliably in plugin environments. As a result, I made the decision to build my own telemetry client library for Application Insights. Creating yet another telemetry library for a service already backed by a major corporation may seem unnecessary — even questionable. But in this case, there were good reasons to build it. Plugin-Specific Constraints Before diving deeper, it’s important to understand the unique constraints of plugin development — especially within the context of Microsoft Power Platform. Plugins face several critical limitations: Lightweight Plugins can be dynamically loaded and unloaded by the host application, so DLL size and dependency count directly impact performance and reliability. Must manage dependencies carefully A plugin may be loaded into an application domain where other versions of the same libraries are already present. This creates a real risk of binding conflicts. Host-specific execution rules Power Platform handles plugins in a very specific way — caching instances and calling the Execute method multiple times. As a result, certain rules must be followed. Target .NET Framework 4.6.2 It may not be the most modern runtime, but within the Power Platform ecosystem, it’s the only supported option — and there’s no way around it. In short, plugin development demands tight control, a minimal footprint, and strict compatibility — none of which are priorities in the design of most modern SDKs. Why OpenTelemetry with Exporter Is Not an Option According to Microsoft documentation, OpenTelemetry with Azure Monitor Exporter is the recommended way to integrate with Application Insights for modern .NET applications. However, this approach falls short — especially in plugin development, and even more so in Power Platform plugin scenarios. File Count and Size When using packages OpenTelemetry 1.11.2 and Azure.Monitor.OpenTelemetry.Exporter 1.3.0 in a .NET project targeting .NET Framework 4.6.2, the resulting output includes 126 files, totaling 5243 KB. That’s far from lightweight. The Problem with Static Classes The OpenTelemetry model relies heavily on static fields of ActivitySource class. Due to the way Power Platform manages plugin lifecycles — reusing cached instances and calling the Execute method multiple times — this leads to repeated initialization and duplicate telemetry data being sent to Application Insights. Maybe it is possible to implement a thread-safe singleton wrapper to control initialization. But doing so introduces complexity, and more importantly, violates Microsoft’s own plugin development recommendations for Power Platform. Verdict Even without considering the excessive file count and size, the use of static state in OpenTelemetry makes it fundamentally incompatible with plugin-based architectures. For Power Platform plugins, OpenTelemetry with Azure Monitor Exporter is simply a no-go solution. What’s Wrong with the Microsoft Application Insight SDK Let’s take a look at the issues encountered when attempting to use the Microsoft Application Insights SDK in plugin development. File Count and Size When using packages Microsoft.ApplicationInsights 2.23.0 and Azure.Core 1.45.0 in a .NET project targeting .NET Framework 4.6.2, the resulting output includes 109 files, totaling 4643 KB. Not good as for me. Target Framework One of the first surprises is that the SDK doesn’t target .NET Framework 4.6.2, the only version supported for Power Platform plugins, and which support ends January 2027. Instead, it targets .NET 4.5.2 and .NET 4.6 — both of which reached end-of-support in April 2022. While this isn’t a critical blocker, it clearly signals that the SDK isn’t aligned with the needs of current, real-world development scenarios. Flaw in Authentication To

May 8, 2025 - 08:19

Azure Monitor Telemetry Client — Reinvented

Recently, I was brought on board of yet another project to help build an enterprise-grade IT solution based on Microsoft Power Platform and Azure.

Like any well-architected system, the solution required robust observability — the ability to track operational behavior, diagnose issues, and maintain visibility across all components. Naturally, Azure Monitor was the go-to choice.

One of the core components of the solution was a custom plugin for Power Platform. To capture application-level telemetry from the plugin, the obvious approach was to use a telemetry client that integrates with Azure Application Insights, a feature of Azure Monitor. By default, Application Insights allows unauthenticated data ingestion — which makes it a potential target for abuse. To address this, the instance was configured to require Entra authentication for secure access.

And that’s where things began to fall apart.

After investing time trying to integrate both OpenTelemetry with the Azure Monitor Exporter and the legacy Application Insights SDK, it became clear that neither option worked reliably in plugin environments.

As a result, I made the decision to build my own telemetry client library for Application Insights.

Creating yet another telemetry library for a service already backed by a major corporation may seem unnecessary — even questionable. But in this case, there were good reasons to build it.

Plugin-Specific Constraints

Before diving deeper, it’s important to understand the unique constraints of plugin development — especially within the context of Microsoft Power Platform.

Plugins face several critical limitations:

Lightweight

Plugins can be dynamically loaded and unloaded by the host application, so DLL size and dependency count directly impact performance and reliability.
Must manage dependencies carefully
A plugin may be loaded into an application domain where other versions of the same libraries are already present. This creates a real risk of binding conflicts.

Host-specific execution rules

Power Platform handles plugins in a very specific way — caching instances and calling the Execute method multiple times. As a result, certain rules must be followed.

Target .NET Framework 4.6.2

It may not be the most modern runtime, but within the Power Platform ecosystem, it’s the only supported option — and there’s no way around it.
In short, plugin development demands tight control, a minimal footprint, and strict compatibility — none of which are priorities in the design of most modern SDKs.

Why OpenTelemetry with Exporter Is Not an Option

According to Microsoft documentation, OpenTelemetry with Azure Monitor Exporter is the recommended way to integrate with Application Insights for modern .NET applications.

However, this approach falls short — especially in plugin development, and even more so in Power Platform plugin scenarios.

File Count and Size

When using packages OpenTelemetry 1.11.2 and Azure.Monitor.OpenTelemetry.Exporter 1.3.0 in a .NET project targeting .NET Framework 4.6.2, the resulting output includes 126 files, totaling 5243 KB. That’s far from lightweight.

The Problem with Static Classes

The OpenTelemetry model relies heavily on static fields of ActivitySource class.

Due to the way Power Platform manages plugin lifecycles — reusing cached instances and calling the Execute method multiple times — this leads to repeated initialization and duplicate telemetry data being sent to Application Insights.

Maybe it is possible to implement a thread-safe singleton wrapper to control initialization. But doing so introduces complexity, and more importantly, violates Microsoft’s own plugin development recommendations for Power Platform.

Verdict

Even without considering the excessive file count and size, the use of static state in OpenTelemetry makes it fundamentally incompatible with plugin-based architectures.

For Power Platform plugins, OpenTelemetry with Azure Monitor Exporter is simply a no-go solution.

What’s Wrong with the Microsoft Application Insight SDK

Let’s take a look at the issues encountered when attempting to use the Microsoft Application Insights SDK in plugin development.

File Count and Size

When using packages Microsoft.ApplicationInsights 2.23.0 and Azure.Core 1.45.0 in a .NET project targeting .NET Framework 4.6.2, the resulting output includes 109 files, totaling 4643 KB. Not good as for me.

Target Framework

One of the first surprises is that the SDK doesn’t target .NET Framework 4.6.2, the only version supported for Power Platform plugins, and which support ends January 2027.

Instead, it targets .NET 4.5.2 and .NET 4.6 — both of which reached end-of-support in April 2022.

While this isn’t a critical blocker, it clearly signals that the SDK isn’t aligned with the needs of current, real-world development scenarios.

Flaw in Authentication

To support Entra ID authentication, the SDK offers the method TelemetryConfiguration.SetAzureTokenCredential(object tokenCredential), which expects the provided object to derive from Azure.Core.TokenCredential.

However, the SDK does not directly reference Azure.Core.dll, the library that defines TokenCredential.

Instead, it attempts to perform a runtime type check by scanning all loaded assemblies in memory and matching type names via reflection.

It’s difficult to describe how flawed this design is — and what it implies about the quality of engineering behind it.

As you can probably guess, this is where things begin to fall apart. The type-checking logic ends up grabbing the first matching assembly loaded into memory, which may not be the version your plugin references.

Yes, you could try to work around this by referencing the same version of Azure.Core.dll as the one preloaded by Power Platform.
And yes — that might work.

But I don’t need to explain how quickly — and why — this kind of “solution” will break down over time.

Verdict

While it may be possible to use the Microsoft SDK in basic scenarios that don’t require authentication, that wasn’t an option in my case.
Authentication was a requirement — and that alone made the official SDK a clear no-go.

Introducing the Azure.Monitor.Telemetry library.

Faced with the limitations of both OpenTelemetry with Exporter and the Microsoft Application Insights SDK, I made the decision to build a custom telemetry client.

The goal was simple: create a lightweight, extensible, and reliable library that integrates with Azure Application Insights — without the overhead, complexity, or incompatibilities of the official options.

What began as a solution to a specific problem has since evolved into a fully-featured, enterprise-grade library.

Result

The result is a robust telemetry client that:

Ships as just 1 file and approximately 62 KB, compared to hundreds of files and thousands of kilobytes required by existing SDKs.
Targets .NET Framework 4.6.2, .NET 8, and .NET 9.
Supports all telemetry types available in Application Insights.
Works flawlessly in constrained environments like Power Platform, where static state and runtime collisions pose real risks.
Offers minimal abstractions and zero external dependencies.
Can be used for solutions and applications of any type: plugins, standalone applications, distributed systems, and other resource-constrained environments.

Check It out