DEV Community: Polymind

OpenApiWeaver: Generate Type-Safe C# Clients from OpenAPI at Compile Time with Source Generators

Tatsuro Shibamura — Fri, 10 Apr 2026 06:59:59 +0000

TL;DR

I built OpenApiWeaver, a C# library that generates HTTP clients from OpenAPI definitions at compile time using Source Generators. Just drop your OpenAPI file into your project, add one ItemGroup entry, and build — no codegen CLI, no reflection at runtime, full NRT and required support, and clean handling of string-based enums via readonly record struct.

shibayan / openapi-weaver

OpenAPI documents into strongly typed C# HTTP clients at build time with an incremental Roslyn source generator.

OpenApiWeaver

OpenApiWeaver is an incremental Roslyn source generator that turns OpenAPI 3.x documents, including OpenAPI 3.2, into strongly typed C# HTTP clients at build time. No runtime code generation, no reflection - just plain C# emitted during compilation.

Quick Start

1. Install the package

<ItemGroup>
  <PackageReference Include="OpenApiWeaver" Version="x.y.z" PrivateAssets="all" />
</ItemGroup>

2. Add your OpenAPI document

<ItemGroup>
  <OpenApiWeaverDocument Include="openapi\petstore.yaml"
                         ClientName="PetstoreClient"
                         Namespace="Contoso.Generated" />
</ItemGroup>

Use OpenApiWeaverDocument rather than AdditionalFiles; the package's MSBuild targets project these items into compiler inputs automatically.

3. Use the generated client

var client = new PetstoreClient(accessToken: "your-token");
// Operations are grouped by OpenAPI tag
var pet = await client.Pets.GetAsync(petId: 1

…

View on GitHub

Why another OpenAPI client generator?

If you've needed a C# client from an OpenAPI definition, you've probably reached for OpenAPI Generator, AutoRest, or NSwag. They all work, but each has its quirks, and I've often found myself compromising on one thing or another.

What I really wanted was dead simple: drop an OpenAPI file in my project, and have the client appear seamlessly at build time — no external tools, no checked-in generated files, no separate codegen step in CI. That's exactly what Source Generators are for, so I built OpenApiWeaver.

Design goals

The core idea is to push as much work as possible into compile time via Source Generators. This gives us two nice properties:

No runtime reflection in the generated code itself
Type-safe output that takes full advantage of modern C# features

Because the generated code leans on recent language features, consumers need .NET 8 or later. In practice, this shouldn't be a real constraint for anyone today.

There are plenty of similar libraries out there, so I put a lot of effort into the quality of the generated code. Specifically:

Nullable reference types and required modifiers are applied faithfully based on the OpenAPI schema
Enums — particularly string-based ones — are generated in a form that's actually pleasant to use from C#
XML doc comments are emitted from OpenAPI description and summary fields, so IntelliSense just works

The generated client code itself contains no reflection. However, because it relies on System.Text.Json, reflection is still used internally there. That means NativeAOT is not supported yet — but once the System.Text.Json source generator can be composed cleanly with this one, it should be achievable.

Usage

Usage is about as simple as I could make it: install the OpenApiWeaver package from NuGet, and you're done. Once installed, you get a new MSBuild item type called OpenApiWeaverDocument. Point its Include attribute at your OpenAPI definition file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="OpenApiWeaver" Version="1.0.0" />
  </ItemGroup>

  <ItemGroup>
    <OpenApiWeaverDocument Include="petstore.json" ClientName="PetStoreClient" />
  </ItemGroup>

</Project>

OpenApiWeaverDocument also accepts ClientName and Namespace attributes, which let you override the generated client's class name and namespace.

What you get after a build

That's the whole setup. Build the project, and the client is generated from the OpenAPI definition. For larger specs, the generator splits clients per OpenAPI Tag, so you end up with one client class per logical grouping in your API — which keeps things manageable.

The sample petstore.json has Pet, Store, and User tags, and you can see a client was generated for each.

Each client exposes its operations as methods, so for the most part you can drive development purely through IntelliSense. (The naming of auto-generated methods still has room for improvement, I'll admit.)

When the OpenAPI definition includes description or summary fields, those flow through to XML doc comments on the generated classes and methods, so you get nice tooltips in the editor:

The generated type definitions

Operations are relatively straightforward, but the type definitions generated from Schemas are where I spent most of my effort. Take the Pet class from the sample — here's what actually gets generated:

/// <summary>
/// Pet
/// </summary>
public sealed class Pet
{
    /// <summary>
    /// Id
    /// </summary>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("id")]
    public long? Id { get; init; }
    /// <summary>
    /// Name
    /// </summary>
    [JsonPropertyName("name")]
    public required string Name { get; init; }
    /// <summary>
    /// Category
    /// </summary>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("category")]
    public Category? Category { get; init; }
    /// <summary>
    /// PhotoUrls
    /// </summary>
    [JsonPropertyName("photoUrls")]
    public required IReadOnlyList<string> PhotoUrls { get; init; }
    /// <summary>
    /// Tags
    /// </summary>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("tags")]
    public IReadOnlyList<Tag>? Tags { get; init; }
    /// <summary>
    /// Status
    /// </summary>
    /// <remarks>
    /// pet status in the store
    /// </remarks>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("status")]
    public Pet.StatusEnum? Status { get; init; }

    /// <summary>
    /// Pet.StatusEnum
    /// </summary>
    /// <remarks>
    /// pet status in the store
    /// </remarks>
    [JsonConverter(typeof(StatusEnumJsonConverter))]
    public readonly record struct StatusEnum(string Value)
    {
        public static readonly StatusEnum Available = new("available");
        public static readonly StatusEnum Pending = new("pending");
        public static readonly StatusEnum Sold = new("sold");

        public override string ToString() => Value;
    }

    public sealed class StatusEnumJsonConverter : JsonConverter<StatusEnum>
    {
        public override StatusEnum Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
        {
            return new StatusEnum(reader.GetString()!);
        }

        public override void Write(Utf8JsonWriter writer, StatusEnum value, JsonSerializerOptions options)
        {
            writer.WriteStringValue(value.Value);
        }
    }
}

A few things worth pointing out:

NRT and required are applied correctly, so mistakes get caught at compile time
String-based enums are not mapped to C# enum. Instead they become readonly record struct, which lets you treat them as strings while still keeping named well-known values like Available, Pending, Sold

This string-enum pattern has become pretty common in modern .NET libraries, and I think it strikes a good balance between type safety and the reality that string enums in OpenAPI often need to tolerate unknown values.

There are a few other niceties I won't cover here — the full documentation goes into more detail:

🔗 OpenApiWeaver documentation

A note on the OpenAPI parser

OpenApiWeaver only owns the "generate a client from an already-parsed OpenAPI document" half of the problem. Parsing itself is delegated to Microsoft.OpenApi, which keeps the surface area small. The docs say OpenAPI 3.x is supported, but really it's whatever that library supports:

🔗 OpenAPI.NET release announcements (Microsoft DevBlogs)

Closing note: this was built with AI coding tools

One last thing worth sharing. This entire library — Source Generator, runtime pieces, and documentation — was built heavily with AI coding assistance. I did the PoC in Codex with GPT-5.4, then moved to GitHub Copilot Chat using GPT-5.4 and Opus 4.6 High for the actual implementation.

Honestly, I've always considered hand-writing Source Generator code to be a painful endeavor, and I'd been putting off projects like this for exactly that reason. Leaning on AI coding tools let me focus on design decisions — API shape, code quality goals, naming — while the assistant handled most of the mechanical work of emitting C# source.

From PoC to release, including docs, it took about three days of real work. That still surprises me.

If you try OpenApiWeaver out, I'd love to hear what you think — issues and PRs welcome on the repo.

Built a Lightweight GitHub Action for Deploying to Azure Static Web Apps

Tatsuro Shibamura — Mon, 06 Apr 2026 06:17:15 +0000

TL;DR

I created shibayan/swa-deploy — a lightweight GitHub Action that only deploys to Azure Static Web Apps, without the Docker-based build overhead of the official action. It wraps the same StaticSitesClient that SWA CLI uses internally, includes automatic caching, and supports both Deployment Token and azure/login authentication.

The Problem with the Official Action

When deploying static sites (built with Astro, Vite, etc.) to Azure Static Web Apps, the standard approach is to use the official Azure/static-web-apps-deploy action that gets auto-generated when you link a GitHub repo to your SWA resource.

Unlike other Azure deployment actions (e.g., for App Service or Azure Functions), this action uses Oryx — the build engine used across Azure App Service — to build your application internally. It runs inside Docker, which means:

The build process is a black box with hidden behaviors
Docker image creation adds significant overhead
Customizing the build pipeline is limited

While Oryx is a capable multi-platform build engine, the Docker-based approach makes deploys slower than they need to be, especially when you just want to push pre-built static files.

The `skip_app_build` Option Isn't Enough

You can set skip_app_build: true in the official action to skip the application build step. This lets you build in GitHub Actions and only deploy through the action. However, it still needs to pull/build the Docker image, so the overhead remains.

For reference, the official documentation covers this configuration:

Build configuration for Azure Static Web Apps | Microsoft Learn

Using SWA CLI: Better, But Not Ideal

To avoid the Docker overhead, I switched to using the Static Web Apps CLI for deploy-only workflows. This approach works well — it's lighter than Docker — but comes with its own trade-offs:

Installation time: npm install -g @azure/static-web-apps-cli takes a while
Cache complexity: To speed things up, you need to add npm global cache steps, which adds more workflow YAML than the actual deploy
Cognitive overhead: You end up thinking more about caching npm packages than deploying your app

The Solution: `shibayan/swa-deploy`

I finally decided to build a dedicated GitHub Action that does one thing well: deploy to Azure Static Web Apps.

shibayan / swa-deploy

A GitHub Action to deploy prebuilt frontend assets and Azure Functions APIs to Azure Static Web Apps

Deploy Azure Static Web Apps

A GitHub Action that deploys prebuilt frontend assets, Azure Functions APIs, and staticwebapp.config.json to Azure Static Web Apps.

It follows the same deployment model as swa deploy from the Azure Static Web Apps CLI — download the StaticSitesClient binary, resolve paths, and upload content using a deployment token. When deployment-token is omitted, this action can also resolve the token at runtime through Azure Resource Manager after azure/login The binary is cached automatically across workflow runs.

Note

This action does not build your application. Run your build step before calling this action.

Usage

Deploy a built frontend

name: Deploy
on:
  push:
    branches: [master]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: npm ci && npm run build

      - name: Deploy to Azure Static Web Apps
        id: deploy

…

View on GitHub

Under the hood, this action uses the same StaticSitesClient binary that SWA CLI uses. It's essentially a thin wrapper around that CLI with automatic caching built in.

Using a Deployment Token

The simplest approach — just pass your deployment token:

- name: Deploy to Azure Static Web Apps
  id: deploy
  uses: shibayan/swa-deploy@v1
  with:
    app-location: dist
    deployment-token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}

Using `azure/login`

If you prefer using azure/login with a service principal or federated credentials, pass app-name instead. The action will automatically look up the resource via the Azure Resource Manager API, retrieve the deployment token, and deploy:

- name: Azure login
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Deploy to Azure Static Web Apps
  uses: shibayan/swa-deploy@v1
  with:
    app-location: dist
    app-name: my-static-web-app
    resource-group-name: my-resource-group

Note: The resource-group-name parameter is optional. You only need it if you have multiple SWA resources with the same name across different resource groups in your subscription — since SWA names are unique at the resource group scope, not the subscription scope.

Why Use This?

Compared to the official action and SWA CLI:

No Docker overhead — no image build step
Automatic caching — the StaticSitesClient binary is cached automatically
Simple workflow YAML — no npm cache boilerplate
Lightweight — does exactly one thing: deploy

I've migrated all of my SWA deployments to this action and it's been working great.

Implementation Note

The entire action was built using GitHub Copilot Chat with GPT-5.4 and Claude Opus 4.6, starting from the official template. AI-assisted development made it straightforward to implement and test.

Deep Dive into Azure Cosmos DB Physical Partitions

Tatsuro Shibamura — Tue, 31 Mar 2026 14:21:33 +0000

Deep Dive into Azure Cosmos DB Physical Partitions

When using Azure Cosmos DB effectively, the most important aspect is designing the partition key. However, when we talk about “partitions” in Cosmos DB, there are actually two types: logical partitions and physical partitions.

This topic is briefly covered in the official documentation, so it’s a good idea to review it first. In most cases, physical partitions are fully managed by Azure, so you rarely need to think about them.

Partitioning and horizontal scaling - Azure Cosmos DB | Microsoft Learn

Learn about partitioning, logical, physical partitions in Azure Cosmos DB, best practices when choosing a partition key, and how to manage logical partitions.

learn.microsoft.com

When designing your data model, the partition key corresponds to logical partitions. Both logical and physical partitions have their own limits, but in most cases, you only need to care about the 20 GB limit of logical partitions.

Although you usually don’t need to think about physical partitions, understanding them can be very helpful during design. So here’s a concise summary based on my experience.

Basics of Physical Partitions

As described in the official documentation, physical partitions are part of Cosmos DB’s internal implementation and represent the unit of compute that processes queries and operations.

Each physical partition has four replicas, and quorum-based consistency is implemented across them.

Global Distribution With - Under the Hood - Azure Cosmos DB | Microsoft Learn

This article provides technical details relating to global distribution of Azure Cosmos DB

learn.microsoft.com

In globally distributed configurations, replication is performed at the physical partition level.

A container always has at least one physical partition. However, Azure automatically increases the number of physical partitions when:

Storage exceeds 50 GB, or
Provisioned throughput exceeds 10,000 RU/s

Throughput and Physical Partitions

Each physical partition has a maximum throughput of 10,000 RU/s. In practice, however, I’ve found that hitting the 50 GB storage limit happens more often than hitting the RU limit.

A common issue occurs when:

A container originally has 4000 RU/s on a single physical partition
Storage exceeds 50 GB
The system splits into 2 physical partitions

Since RU is evenly distributed across physical partitions:

1 partition → 4000 RU
2 partitions → 2000 RU each
4 partitions → 1000 RU each

This effectively reduces the throughput available per partition, which can lead to sudden 429 Too Many Requests errors.

In such cases, you should follow the official guidance and adjust RU accordingly:

Best Practices for Scaling Provisioned Throughput - Azure Cosmos DB | Microsoft Learn

Learn about best practices for scaling manual and autoscale provisioned throughput for databases and containers.

learn.microsoft.com

If you already know your data will exceed 50 GB, it can be a good strategy to provision enough RU upfront so that the required number of physical partitions are allocated early.

Also note that when new physical partitions are created, data replication occurs, temporarily consuming additional RU. This can lead to temporary throughput degradation.

Connection Modes and Physical Partitions

To improve performance, the C# and Java SDKs recommend using Direct mode.

SQL SDK Connectivity Modes - Azure Cosmos DB | Microsoft Learn

Learn about the different connectivity modes available on the Azure Cosmos DB SQL SDKs.

learn.microsoft.com

As the name suggests, Direct mode connects directly to backend physical partitions, reducing overhead.

To make this work, the SDK must know which physical partition stores a given partition key.

If you’ve enabled Application Insights, you may have seen requests to pkranges during application startup. This API returns the mapping between partition keys and physical partitions:

Get Partition Key Ranges - Azure Cosmos DB REST API | Microsoft Learn

Get partition key ranges REST API syntax. Request and response headers, body, status codes and examples.

learn.microsoft.com

This API is not intended for direct use in user code.

Because this mapping is fetched when a container is first accessed, the first request can be slower. However, recent versions of the .NET SDK provide an API to explicitly initialize this mapping:

CosmosClient.CreateAndInitializeAsync Method (Microsoft.Azure.Cosmos) - Azure for .NET Developers | Microsoft Learn

Creates a new CosmosClient with the account endpoint URI string and TokenCredential. In addition to that it initializes the client with containers provided i.e The SDK warms up the caches and connections before the first call to the service is made. Use this to obtain lower latency while startup of your application. CosmosClient is thread-safe. Its recommended to maintain a single instance of CosmosClient per lifetime of the application which enables efficient connection management and performance. Please refer to the performance guide.

learn.microsoft.com

By calling this during application warm-up, you can minimize overhead for subsequent requests.

Cross-Partition Queries and Physical Partitions

In Cosmos DB design, cross-partition queries should generally be avoided. However, this rule can be relaxed if all data fits within a single physical partition.

In the following documentation, the term “partition” refers to physical partitions:

Query a Container - Azure Cosmos DB | Microsoft Learn

Learn how to query containers in Azure Cosmos DB by using both in-partition and cross-partition queries.

learn.microsoft.com

If all logical partitions are contained within a single physical partition, indexes can be used effectively, making cross-partition queries relatively low-cost.

Problems arise when a container spans multiple physical partitions, as queries must be executed across all of them, increasing cost.

The most efficient cross-partition query is one that targets only partition keys within a single physical partition, but this is not something you can control directly from user code.

Instead, you should rely on SDK features. A good example is the ReadMany API, which efficiently handles cross-partition access.

That said, designing everything around cross-partition queries should always be avoided.

Change Feed and Physical Partitions

Physical partitions are closely related to the Change Feed feature.

While Change Feed guarantees ordering at the logical partition level, its actual processing is based on physical partitions.

This is easier to understand when looking at the Pull model.

In the Pull model, parallel processing is achieved using the FeedRange class, which is assigned per physical partition. By distributing FeedRange across multiple machines, you can process Change Feed in parallel.

Change Feed Pull Model - Azure Cosmos DB | Microsoft Learn

Learn how to use the Azure Cosmos DB change feed pull model to read the change feed. Understand the differences between the change feed pull model and the change feed processor.

learn.microsoft.com

FeedRange Class (Microsoft.Azure.Cosmos) - Azure for .NET Developers | Microsoft Learn

Represents a unit of feed consumption that can be used as unit of parallelism.

learn.microsoft.com

As a result, even a single Change Feed Processor can only scale up to the number of physical partitions. In other words, processing is effectively single-threaded per physical partition, which simplifies writing logic that depends on ordering.

However, this also means that scale-out limits are reached relatively quickly.

To address this, you should minimize processing within each Change Feed Processor and instead create multiple smaller processors for different purposes.

Metrics and Physical Partitions

By now, you should have a solid understanding of physical partitions, so let’s move on to monitoring.

Even with careful partition key design, data can still become skewed toward specific physical partitions (so-called hot partitions).

To identify them, you can split metrics by PartitionKeyRangeId.

Monitor Normalized Request Units - Azure Cosmos DB | Microsoft Learn

Learn how to monitor the normalized request unit usage of an operation in Azure Cosmos DB. Owners of an Azure Cosmos DB account can understand which operations are consuming more request units.

learn.microsoft.com

Recently, new metrics such as Physical Partition Throughput have been introduced, making it easier to troubleshoot partition-level issues.

You can also view these metrics in Cosmos DB Insights in Azure Monitor, which significantly improves observability.

Operations on Physical Partitions (Preview)

At Build 2022, several Cosmos DB updates were announced, including preview features that allow direct operations on physical partitions.

One of them is Merge partitions, which combines physical partitions.

Merge partitions (preview) - Azure Cosmos DB | Microsoft Learn

Reduce the number of physical partitions used for your container with the merge capability in Azure Cosmos DB.

learn.microsoft.com

Since RU is evenly distributed across physical partitions, fewer partitions can result in higher effective throughput per partition. Merging excess partitions helps optimize performance.

Another feature allows redistributing throughput across physical partitions.

Redistribute Throughput Across Partitions (Preview) - Azure Cosmos DB | Microsoft Learn

Learn how to redistribute throughput across partitions in Azure Cosmos DB to optimize performance. To improve partition performance, follow these step-by-step instructions and best practices.

learn.microsoft.com

No matter how carefully you design your partition key, data skew is inevitable in real-world scenarios. This feature allows you to assign more RU to hot partitions without increasing total RU, improving overall efficiency.

Conclusion

By understanding physical partitions, you can push Cosmos DB optimization further in terms of both performance and cost.

However, this is not mandatory knowledge for most use cases.

Rather than focusing on physical partitions from the beginning, the most important thing is to design a good partition key during data modeling.

Most physical partition-related optimizations can be handled later, so invest your effort where it matters most: your initial data model design.

Migrating Azure Functions Monitoring to OpenTelemetry

Tatsuro Shibamura — Tue, 31 Mar 2026 14:05:40 +0000

A while ago, version 3.0 of the Application Insights SDK was released, and its internal implementation was migrated to be based on OpenTelemetry. While it is generally recommended to use the OpenTelemetry Distro directly, being able to support OpenTelemetry just by updating the Application Insights SDK is a clear advantage.

Along with this change, one of the Application Insights SDKs used in Azure Functions .NET Isolated—Microsoft.ApplicationInsights.WorkerService—has also been updated to version 3.0. If you are managing both Azure Functions and ASP.NET Core projects in a single solution, you may often update them together.

In a typical .NET Worker application, this update does not cause any issues. However, in Azure Functions, simply updating the package leads to runtime exceptions like the one below. Since the build succeeds without errors, this can be particularly tricky to notice.

This issue occurs because the Microsoft.Azure.Functions.Worker.ApplicationInsights package—required for Azure Functions' built-in Application Insights integration—has a strong dependency on the v2 SDK. While this would be resolved if the package were updated for v3, it appears from GitHub issues that there are no plans to provide a v3-compatible version. Therefore, in the long term, migrating to an OpenTelemetry-based approach will be necessary.

Comment for #3322

RohitRanjanMS commented on Mar 12, 2026

We do not plan to release a new version of Microsoft.Azure.Functions.Worker.ApplicationInsights that is compatible with the 3.0 release of Microsoft.ApplicationInsights.WorkerService. Our current package relies heavily on Telemetry Initializers and Telemetry Processors, and the new 3.0 SDK no longer supports these extensibility points. Supporting it would require a full rewrite of the Functions worker package. The same limitation may also affect customers who depend on Initializers or Processors in their applications. Our recommendation is to move to OpenTelemetry‑based monitoring. This is the direction we are investing in, and we are committed to improving observability by aligning with the OpenTelemetry ecosystem. You can follow Functions OpenTelemetry guidance here: https://learn.microsoft.com/en-us/azure/azure-functions/opentelemetry-howto?tabs=app-insights%2Cihostapplicationbuilder%2Cmaven&pivots=programming-language-csharp

View on GitHub

Azure Functions now supports OpenTelemetry, but if you create a project from the default template, it still uses the Application Insights SDK. Therefore, some additional steps are required to switch.

You can follow the official documentation below for the migration steps, but there are a few pitfalls I encountered during the process.

https://learn.microsoft.com/en-us/azure/azure-functions/opentelemetry-howto

Removing Application Insights Packages

First, check your existing Azure Functions project. You will likely find the following two Application Insights-related packages installed. Remove them:

Microsoft.ApplicationInsights.WorkerService
Microsoft.Azure.Functions.Worker.ApplicationInsights

These packages depend on the Application Insights SDK and are no longer needed.

Adding OpenTelemetry Packages

Instead, install the following OpenTelemetry-related packages:

Microsoft.Azure.Functions.Worker.OpenTelemetry
Azure.Monitor.OpenTelemetry.Exporter
OpenTelemetry.Extensions.Hosting

In ASP.NET Core, a single package is often sufficient, but in Azure Functions, you need to install them individually.

Updating Program.cs

At this point, your project will no longer build. Remove the existing Application Insights initialization code in Program.cs and replace it with the following:

using Azure.Monitor.OpenTelemetry.Exporter;

using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Azure.Functions.Worker.OpenTelemetry;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.AddOpenTelemetry()
    .UseFunctionsWorkerDefaults()
    .UseAzureMonitorExporter();

builder.Build().Run();

If you need customization, you can pass options to UseAzureMonitorExporter.

Local Development Pitfall

After this change, the project builds successfully. However, when running locally, you may encounter an error indicating that the Application Insights connection string is missing, causing the application to fail at startup.

With the Application Insights SDK, telemetry was automatically disabled if no connection string was provided. However, with the OpenTelemetry Distro, it is now required.

To avoid forcing Application Insights in local development, you could disable it using preprocessor directives. However, I personally found that approach messy.

Instead, I added a dummy connection string like this:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "APPLICATIONINSIGHTS_CONNECTION_STRING": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
}

This allows the application to start correctly in a local development environment.

Verifying Telemetry

Finally, connect to Application Insights and verify that telemetry is being sent correctly.

You will notice that property names follow the OpenTelemetry schema. However, telemetry generated by the Azure Functions host remains unchanged.

Real-World Example

Here is the Pull Request where I migrated Acmebot to an OpenTelemetry-based setup:

Add OpenTelemetry support and remove Application Insights initializer #996

shibayan posted on Mar 20, 2026

This pull request updates the application's telemetry and monitoring stack by migrating from Application Insights to OpenTelemetry with Azure Monitor Exporter. This modernizes observability, aligns with current best practices, and simplifies related configuration and code. The most important changes are grouped below.

Migration to OpenTelemetry and Azure Monitor Exporter:

Removed dependencies on Microsoft.ApplicationInsights.WorkerService and Microsoft.Azure.Functions.Worker.ApplicationInsights, and added new dependencies for Azure.Monitor.OpenTelemetry.Exporter, Microsoft.Azure.Functions.Worker.OpenTelemetry, and OpenTelemetry.Extensions.Hosting in Acmebot.App.csproj.
Replaced Application Insights telemetry setup in Program.cs with OpenTelemetry initialization using AddOpenTelemetry(), UseFunctionsWorkerDefaults(), and UseAzureMonitorExporter().
Updated host.json to set "telemetryMode": "OpenTelemetry" and removed Application Insights-specific logging configuration.

Codebase cleanup:

Removed the custom ApplicationVersionInitializer class and its registration, as it was specific to Application Insights. [1] [2]

General code and dependency updates:

Updated using statements in Program.cs to remove Application Insights references and add OpenTelemetry/Azure Monitor references as needed.

View on GitHub

The changes are relatively simple—for example, removing ITelemetryInitializer. Equivalent functionality is now built in, so it is no longer necessary.

Final Thoughts

Migrating applications that rely heavily on ITelemetryProcessor or other advanced customizations may require more effort. However, it seems feasible to migrate even filtering logic to OpenTelemetry.

If I get the time, I plan to write another post covering those advanced scenarios.

DEV Community: Polymind

OpenApiWeaver: Generate Type-Safe C# Clients from OpenAPI at Compile Time with Source Generators

TL;DR

shibayan / openapi-weaver

OpenAPI documents into strongly typed C# HTTP clients at build time with an incremental Roslyn source generator.

OpenApiWeaver

Quick Start

Why another OpenAPI client generator?

Design goals

Usage

What you get after a build

The generated type definitions

A note on the OpenAPI parser

Closing note: this was built with AI coding tools

Built a Lightweight GitHub Action for Deploying to Azure Static Web Apps

TL;DR

The Problem with the Official Action

The skip_app_build Option Isn't Enough

Using SWA CLI: Better, But Not Ideal

The Solution: shibayan/swa-deploy

shibayan / swa-deploy

A GitHub Action to deploy prebuilt frontend assets and Azure Functions APIs to Azure Static Web Apps

Deploy Azure Static Web Apps

Usage

Deploy a built frontend

Using a Deployment Token

Using azure/login

Why Use This?

Implementation Note

Deep Dive into Azure Cosmos DB Physical Partitions

Deep Dive into Azure Cosmos DB Physical Partitions

Basics of Physical Partitions

Throughput and Physical Partitions

Connection Modes and Physical Partitions

Cross-Partition Queries and Physical Partitions

Change Feed and Physical Partitions

Metrics and Physical Partitions

Operations on Physical Partitions (Preview)

Conclusion

Migrating Azure Functions Monitoring to OpenTelemetry

Removing Application Insights Packages

Adding OpenTelemetry Packages

Updating Program.cs

Local Development Pitfall

Verifying Telemetry

Real-World Example

Final Thoughts

The `skip_app_build` Option Isn't Enough

The Solution: `shibayan/swa-deploy`

Using `azure/login`