DEV Community: Tatsuro Shibamura

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.

Generate sequence numbers in Cosmos DB

Tatsuro Shibamura — Sun, 15 Jan 2023 17:10:44 +0000

Azure Cosmos DB does not provide a function to generate sequence numbers like RDB such as SQL Server in order to achieve very high availability and global distribution.

Since RDB can always achieve strong consistency, sequence numbers can be easily generated as described in the following document, but they can be a bottleneck in scaling.

Sequence Numbers - SQL Server | Microsoft Learn

Data modeling is the most important part of using Cosmos DB, and the key to maximizing the benefits of Cosmos DB is to design a system that does not require sequence numbers at that point (a design that allows for high data distribution).

However, there are rare cases in which sequence numbers are required even at the expense of availability.

While it was possible to safely generate sequence numbers in RDB, it used to be surprisingly difficult to safely generate sequence numbers using Cosmos DB until Partial Update became available.

Partial document update in Azure Cosmos DB | Microsoft Learn

Now that Cosmos DB supports partial updates and provides increments to arbitrary properties as operations, it is now surprisingly easy to generate sequence numbers.

The following is a sample code. The data model to be stored in Cosmos DB is very simple as follows. The value property holds the current sequence number.

public class Sequence
{
    [JsonProperty("id")]
    public string Id { get; set; }

    [JsonProperty("value")]
    public long Value { get; set; }
}

The following JSON is stored in Cosmos DB in advance. Since partial update is a process to an already existing document, it is necessary to create the document itself separately.

{
    "id": "sample",
    "value": 0
}

As you have probably figured out by now, all that is left is for the Cosmos DB SDK to perform a +1 operation on the value property using partial updates.

var connectionString = "<connection_string>";

var cosmosClient = new CosmosClient(connectionString);

var container = cosmosClient.GetContainer("my-database", "my-sequence");

var operations = new[]
{
    PatchOperation.Increment("/value", 1)
};

var response = await container.PatchItemAsync<Sequence>("sample", new PartitionKey("sample"), operations);

Console.WriteLine($"Seq = {response.Resource.Value}");

Executing this code, you can see that the property increment is performed by Cosmos DB on the server side.

The difficulty with sequence numbers is whether they can be correctly generated without duplication when a large number of them are generated at the same time.

The sample code is extended as shown below to try parallel generation.

var tasks = new List<Task<ItemResponse<Sequence>>>();

for (var i = 0; i < 10; i++)
{
    tasks.Add(container.PatchItemAsync<Sequence>("sample", new PartitionKey("sample"), operations));
}

var response = await Task.WhenAll(tasks);

foreach (var itemResponse in response)
{
    Console.WriteLine($"Seq : {itemResponse.Resource.Value}, Consumed RU/s = {itemResponse.RequestCharge}");
}

Console.WriteLine($"Next Seq : {response.Max(x => x.Resource.Value) + 1}");

When I run the extended code, it generates sequence numbers without duplication. Although requests are thrown at the same time, it can be confirmed that atomic processing is performed on the server side.

Previously, read and update had to be executed separately, which was complicated in Cosmos DB, where transactions are not available like in RDB. However, with partial updates, everything is done on the server side, including conflict resolution, so there is no need to worry about this.

Container for generating sequence numbers can reduce RU consumption slightly by turning off the index policy.

{
    "indexingMode": "none",
    "automatic": false,
    "includedPaths": [],
    "excludedPaths": []
}

If you know that you do not need the indexes completely, you can reduce the cost of Cosmos DB by explicitly turning them off.

How to quickly setup a Let's Encrypt certificate in Azure Container Apps

Tatsuro Shibamura — Sat, 14 May 2022 03:04:52 +0000

Azure Container Apps now supports custom domain assignment in the latest update. Now you can easily publish your own web application with your own domain without using Front Door.

// Detect dark theme var iframe = document.getElementById('tweet-1525264037432684544-637'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1525264037432684544&theme=dark" }

However, it does not currently support free managed certificates, and you must upload your own certificates.

Free certificates are issued by Let's Encrypt, so I developed an application to use them. This is based on code written by @jeffhollan of the Azure Apps team.

shibayan / containerapps-acmebot

Automated ACME SSL/TLS certificates issuer for Azure Container Apps (Custom domain / Custom DNS Suffix)

Container Apps Acmebot

Automated ACME SSL/TLS certificates issuer for Azure Container Apps

Important

This project has been retired as Azure Container Apps now supports Key Vault certificates. Please use Key Vault Acmebot from now on.

https://github.com/shibayan/keyvault-acmebot

Motivation

We have started to address the following requirements:

Support for multiple Container Apps and Container Apps Environment
Easy to deploy and configure
Highly reliable implementation
Ease of Monitoring (Application Insights, Webhook)

You can add multiple certificates to a single Container Apps.

Feature Support

Issuing certificates for Zone Apex / Multi-domain / Wildcard
Automatic binding of custom domains and certificates to Container App
Support for multiple Container Apps in a single application
ACME-compliant Certification Authorities
- Let's Encrypt
- Buypass Go SSL
- ZeroSSL (Requires EAB Credentials)

Deployment

Azure (Public)	Azure China	Azure Government

Learn more at https://github.com/shibayan/containerapps-acmebot/wiki/Getting-Started

Thanks

Based on containerapps-acmebot by @jeffhollan
ACMESharp Core by @ebekker
Durable Functions by @cgillum and contributors
DnsClient.NET by @MichaCo

…

View on GitHub

It has the same functionality as other Acmebot products, but supports Container Apps specific features. Azure DNS is currently required for use.

From here, I will actually use Acmebot to add a custom domain and certificate to the Container App.

Deploy Acmebot

Deploy Acmebot using the "Deploy to Azure" button in the README on GitHub.

After deployment is complete, add Azure AD authentication using App Service Authentication. Detailed instructions are provided in the README.

Setup RBAC (IAM) for Acmebot

Add the Contributor RBAC role to the deployed Acmebot for the resource group where Container Apps and Container Apps Environment are deployed.

Currently there is no RBAC role for Container Apps, so Contributor RBAC role must be assigned.

Since Acmebot requires Azure DNS for certificate issuance, assign the role of DNS Zone Contributor to Acmebot for Azure DNS as well.

Issue certificate

If the setup was successful, accessing the application will show a list of DNS Zones and Container Apps Environment.

The following simple screen allows you to select a DNS zone and issue a certificate for the required domain name.

Container Apps certificates are associated with the Container App Environment, so the Container Apps Environment must be explicitly specified when the certificate is issued.

If the certificate is successfully issued, it can be found in the list of certificates in the Container Apps Environment.

Acmebot is designed to attempt to automatically renew certificates associated with the Container Apps Environment.

Bind to Container App

An additional option is to add custom domain settings to any Container App at the same time the certificate is issued.

A custom domain is added to the Container App, but the actual A or CNAME DNS record is not automatically added and must be added manually. This is by design for safety.

After manually adding the A record, the browser will be able to view the Container App hosted in the HTTPS-protected Zone apex domain, as shown below.

In this way, Acmebot greatly reduces the effort of issuing certificates for Container Apps and automates their management.

Renew certificates

The default setting is to automatically renew certificates 30 days before they expire.

Upon successful renewal of the certificate by Acmebot, Container Apps will automatically use the new certificate.

If you are interested in the App Service and Key Vault version of Acmebot, please refer to the following post.

Tatsuro Shibamura

Sep 14 '20

The fastest way to use Let's Encrypt in Azure

#azure #appservice #keyvault #letsencrypt

Comments 3

2 min read

Enjoy Azure Container Apps and Let's Encrypt!

Collecting Cosmos DB dependency telemetry with Application Insights

Tatsuro Shibamura — Tue, 15 Feb 2022 17:29:45 +0000

In this article, we will use Application Insights to collect the requests made to Azure Cosmos DB so that we can easily understand the performance issues.

Cosmos DB is very fast, but depending on the query to be executed, it can consume a lot of Request Units or worsen the latency in some cases.

In order to understand the problem at the application level, you can create an extension to Cosmos DB SDK v3 and send the request information to Application Insights.

Azure / azure-cosmos-dotnet-v3

.NET SDK for Azure Cosmos DB for the core SQL API

Microsoft Azure Cosmos DB .NET SDK Version 3

This client library enables client applications to connect to Azure Cosmos DB for NoSQL. Azure Cosmos DB is a globally distributed, multi-model database service. For more information, refer to https://azure.microsoft.com/services/cosmos-db/.

CosmosClient client = new CosmosClient("https://mycosmosaccount.documents.azure.com:443/", "mysupersecretkey");
Database database = await client.CreateDatabaseIfNotExistsAsync("MyDatabaseName");
Container container = await database.CreateContainerIfNotExistsAsync(
    "MyContainerName",
    "/partitionKeyPath",
    400);
// Create an item
dynamic testItem = new { id = "MyTestItemId", partitionKeyPath = "MyTestPkValue", details = "it's working", status = "done" };
ItemResponse<dynamic> createResponse = await container.CreateItemAsync(testItem);

// Query for an item
using (FeedIterator<dynamic> feedIterator = container.GetItemQueryIterator<dynamic>(
    "select * from T where T.status = 'done'"))
{
    while (

…

View on GitHub

Cosmos DB SDK v3 provides an extension point called RequestHandler, which can be used to implement the Application Insights dependency collector.

It is very easy to send dependency telemetry to Application Insights. Please refer to the official documentation available here.

Track custom operations with Azure Application Insights .NET SDK - Azure Monitor | Microsoft Docs

The RequestHandler to send dependency telemetry to Application Insights that we implemented is as follows.

Once you have decided what to send to Application Insights, the sending itself can be done with a very simple code. In this example, we are sending the name of the resource in Cosmos DB and the Request Units that were consumed.

public class AppInsightsRequestHandler : RequestHandler
{
    public SimpleAppInsightsRequestHandler(TelemetryClient telemetryClient)
    {
        _telemetryClient = telemetryClient;
    }

    private readonly TelemetryClient _telemetryClient;

    public override async Task<ResponseMessage> SendAsync(RequestMessage request, CancellationToken cancellationToken)
    {
        using var dependency = _telemetryClient.StartOperation<DependencyTelemetry>($"{request.Method} {request.RequestUri.OriginalString}");

        var response = await base.SendAsync(request, cancellationToken);

        var telemetry = dependency.Telemetry;

        // Used to identify Cosmos DB in Application Insights
        telemetry.Type = "Azure DocumentDB";
        telemetry.Data = request.RequestUri.OriginalString;

        telemetry.ResultCode = ((int)response.StatusCode).ToString();
        telemetry.Success = response.IsSuccessStatusCode;

        // Send with Metrics
        telemetry.Metrics["RequestCharge"] = response.Headers.RequestCharge;

        return response;
    }
}

To use the implemented RequestHandler, you just need to write the following code with Dependency Injection. Don't forget to install the Application Insights SDK for your application.

builder.Services.AddSingleton<AppInsightsRequestHandler>();

builder.Services.AddSingleton(provider =>
{
    var requestHandler = provider.GetRequiredService<AppInsightsRequestHandler>();

    var connectionString = builder.Configuration.GetConnectionString("CosmosConnection");

    return new CosmosClient(connectionString, new CosmosClientOptions
    {
        CustomHandlers = { requestHandler }
    });
});

If you run the application with the above code, you will be able to check the Cosmos DB request information from Dependency in Application Insights.

The telemetry details can be viewed from the E2E transaction view to see the Request Units consumed by the request and the resource URIs executed.

Request Units that are sent at the same time as dependency telemetry are treated as metrics and can be displayed graphically from the Metric view of Application Insights. Of course, advanced aggregation using KQL can also be done easily.

The simple implementation so far provides a minimum of information, but we will make the information to be sent more detailed.

The Application Insights SDK implements a dependency collector for Cosmos DB, but it is only available when the connection mode is Gateway. However, the implementation can be reused, so we will refer to it to detail the telemetry.

ApplicationInsights-dotnet/DocumentDbHttpParser.cs at main · microsoft/ApplicationInsights-dotnet · GitHub

The following is an implementation that uses the Application Insights SDK implementation to flesh out the telemetry.

Some methods that are not related to Cosmos DB are omitted, so please copy them from the Application Insights SDK if necessary.

public class AppInsightsRequestHandler : RequestHandler
{
    public AppInsightsRequestHandler(TelemetryClient telemetryClient)
    {
        _telemetryClient = telemetryClient;
    }

    private readonly TelemetryClient _telemetryClient;

    public override async Task<ResponseMessage> SendAsync(RequestMessage request, CancellationToken cancellationToken)
    {
        using var dependency = _telemetryClient.StartOperation<DependencyTelemetry>("Cosmos");

        var response = await base.SendAsync(request, cancellationToken);

        var telemetry = dependency.Telemetry;

        var resourcePath = HttpParsingHelper.ParseResourcePath(request.RequestUri.OriginalString);

        // populate properties
        foreach (var (key, value) in resourcePath)
        {
            if (value is not null)
            {
                var propertyName = GetPropertyNameForResource(key);
                if (propertyName is not null)
                {
                    telemetry.Properties[propertyName] = value;
                }
            }
        }

        var operation = HttpParsingHelper.BuildOperationMoniker(request.Method.ToString(), resourcePath);
        var operationName = GetOperationName(operation);

        telemetry.Type = "Azure DocumentDB";
        telemetry.Name = operationName;
        telemetry.Data = request.RequestUri.OriginalString;

        telemetry.ResultCode = ((int)response.StatusCode).ToString();
        telemetry.Success = response.IsSuccessStatusCode;

        telemetry.Metrics["RequestCharge"] = response.Headers.RequestCharge;

        return response;
    }

    private static readonly Dictionary<string, string> OperationNames = new()
    {
        // Database operations
        ["POST /dbs"] = "Create database",
        ["GET /dbs"] = "List databases",
        ["GET /dbs/*"] = "Get database",
        ["DELETE /dbs/*"] = "Delete database",

        // Collection operations
        ["POST /dbs/*/colls"] = "Create collection",
        ["GET /dbs/*/colls"] = "List collections",
        ["POST /dbs/*/colls/*"] = "Query documents",
        ["GET /dbs/*/colls/*"] = "Get collection",
        ["DELETE /dbs/*/colls/*"] = "Delete collection",
        ["PUT /dbs/*/colls/*"] = "Replace collection",

        // Document operations
        ["POST /dbs/*/colls/*/docs"] = "Create document",
        ["GET /dbs/*/colls/*/docs"] = "List documents",
        ["GET /dbs/*/colls/*/docs/*"] = "Get document",
        ["PUT /dbs/*/colls/*/docs/*"] = "Replace document",
        ["DELETE /dbs/*/colls/*/docs/*"] = "Delete document"
    };

    private static string? GetPropertyNameForResource(string resourceType)
    {
        // ignore high cardinality resources (documents, attachments, etc.)
        return resourceType switch
        {
            "dbs" => "Database",
            "colls" => "Collection",
            _ => null
        };
    }

    private static string GetOperationName(string operation)
    {
        return OperationNames.TryGetValue(operation, out var operationName) ? operationName : operation;
    }
}

When you run the application using this implementation, you can check the dependency telemetry for each operation against Cosmos DB in Application Insights.

In this case, you can see the Request Units consumed for the query in Application Insights.

At the same time, the DB name and container name will be sent as custom properties, so you can easily grasp the RU consumption per container.

If it is simply the Request Units consumed, it can be understood by transferring the Cosmos DB logs to Log Analytics, but it is not possible to understand how many Cosmos DB queries are executed by which operations in the actual application, so it is best combined with Application Insights.

How to build an interactive command-line application in .NET

Tatsuro Shibamura — Mon, 23 Aug 2021 16:27:19 +0000

Development using Node.js often provides highly interactive command line applications such as vue-cli and create-nuxt-app.

As an example, create-nuxt-app has an interactive interface that allows even beginners to start development right away by simply answering questions.

I find this interface to be very beautiful and easy to use.

On the other hand, C# / .NET developers are provided with a powerful integrated development environment called Visual Studio, so they do not need to operate on the command line to start development, but Windows Terminal and WSL 2 increasingly require a command line interface.

Since there were not many ways to implement an interactive command line interface for C# like Node.js, I developed a library to implement it easily.

shibayan / Sharprompt

Interactive command-line based application framework for C#

Sharprompt

Interactive command-line based application framework for C#

Features

Multi-platform support
Supports the popular prompts (Input / Password / Select / etc)
Supports model-based prompts
Validation of input value
Automatic generation of data source using Enum type
Customizable symbols and color schema
Unicode support (Multi-byte characters and Emoji😀🎉)

Installation

Install-Package Sharprompt

dotnet add package Sharprompt

Quick start

// Simple input
var name = Prompt.Input<string>("What's your name?");
Console.WriteLine($"Hello, {name}!");
// Password input
var secret = Prompt.Password("Type new password", validators: new[] { Validators.Required(), Validators.MinLength(8) });
Console.WriteLine("Password OK");

// Confirmation
var answer = Prompt.Confirm("Are you ready?", defaultValue: true);
Console

…

View on GitHub

It can be easily installed in a console application project from NuGet.

Install-Package Sharprompt
or
dotnet add package Sharprompt

First, let's create an application with two very simple input fields.

In Sharprompt, all the APIs are defined in the class Prompt, so your application will use only the methods you need. This time we will use Prompt.Input<T> because I need an arbitrary value entered by the user.

class Program
{
    static void Main(string[] args)
    {
        var name = Prompt.Input<string>("What's your name?");
        var number = Prompt.Input<int>("Enter any number");

        Console.WriteLine($"Hello, {name}!");
        Console.WriteLine($"The number entered is {number}");
    }
}

The type parameter specifies the type of the final value required. Sharprompt automatically performs type conversion and error handling according to the specified type.

You now have a console application that allows you to enter a name and an arbitrary number.

The APIs include password input, selectable from a list, etc., so that complex console applications can be developed.

As a NET / C# developer, you often want to define input values and validation on a class and attribute-based.

For such use cases, Sharprompt provides an API to create forms automatically on a model-based.

class Program
{
    static void Main(string[] args)
    {
        var model = Prompt.AutoForms<PromptModel>();

        Console.WriteLine($"Hello, {model.Name}!");
        Console.WriteLine($"The number entered is {model.Number}");
    }
}

public class PromptModel
{
    [Display(Prompt = "What's your name?")]
    [Required]
    public string Name { get; set; }

    [Display(Prompt = "Enter any number")]
    [Required]
    [Range(0, 100)]
    public int? Number { get; set; }
}

If you have experience developing with ASP.NET Core, you are probably familiar with this class definition.

If you call Prompt.AutoForms<T> with this class definition, it will automatically create an input form with validation.

Since the validation uses standard .NET attributes, it is also possible to easily add custom validations.

Now you can see how easy it is to development an interactive console application in .NET / C#.

Example: create-function-app

Finally, here is a mock of create-function-app, a CLI tool for Azure Functions with an interface like create-nuxt-app.

Being able to interactively create Azure Functions projects will make it easier to start developing.

This mock source code is here!

shibayan / create-function-app-mock

Sharprompt demo application

If you have any feedback, please feel free to visit GitHub.

Enjoy the development!

How to use Netherite Storage Provider in Durable Functions

Tatsuro Shibamura — Tue, 20 Jul 2021 16:23:47 +0000

Netherite Storage Provider is a backend implementation of Durable Functions that delivers high performance.

It's still a preview version, but if you are using Functions Premium (EP1-3), it's worth evaluating it now.

microsoft / durabletask-netherite

A new engine for Durable Functions. https://microsoft.github.io/durabletask-netherite

Netherite

Netherite is a distributed workflow execution engine for Durable Functions (DF) and the Durable Task Framework (DTFx).

It is of potential interest to anyone developing applications on those platforms who has an appetite for performance, scalability, and reliability.

As Netherite is intended to be a drop-in backend replacement, it does not modify the application API. Existing DF and DTFx applications can switch to this backend with little effort However, we do not support migrating existing task hub contents between different backends.

Getting Started

To get started, you can either try out the sample, or take an existing DF app and switch it to the Netherite backend. You can also read our documentation.

The hello sample.

For a comprehensive quick start on using Netherite with Durable Functions, take a look at hello sample walkthrough, and the associated video content We included several scripts that make it easy…

View on GitHub

Durable Functions storage providers - Azure | Microsoft Docs

The use of Netherite requires some additional work, so we will briefly introduce how to use it.

Install Netherite

First, install the Microsoft.Azure.DurableTask.Netherite.AzureFunctions package in your Azure Functions project.

NuGet Gallery | Microsoft.Azure.DurableTask.Netherite.AzureFunctions

Install-Package Microsoft.Azure.DurableTask.Netherite.AzureFunctions -Version 0.4.0-alpha

dotnet add package Microsoft.Azure.DurableTask.Netherite.AzureFunctions --version 0.4.0-alpha

After installing the package, declare that you want to use Netherite in host.json. There are many configurations in the storageProvider, please refer to the official documentation.

{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": false,
        "excludedTypes": "Request"
      }
    },
  },
  "extensions": {
    "durableTask": {
      "hubName": "<YourHubName>",
      "useGracefulShutdown": true,
      "storageProvider": {
        "type": "Netherite",
        "StorageConnectionName": "AzureWebJobsStorage",
        "EventHubsConnectionName": "EventHubsConnection"
      }
    }
  }
}

Set the connection string names for Storage and Event Hubs to the key names in the Azure Functions App Settings or local.settings.json.

Preserve `System.Threading.Channels.dll`

The current version 0.4.0-alpha does not work with an error when deployed to Azure Functions, so you need to add FunctionsPreservedDependencies to the csproj file to avoid this problem.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.DurableTask.Netherite.AzureFunctions" Version="0.4.0-alpha" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="2.5.0" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </ItemGroup>
  <ItemGroup>
    <FunctionsPreservedDependencies Include="System.Threading.Channels.dll" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Add a setting to prevent System.Threading.Channels.dll from being removed on deployment. This fix will allow it to work on Azure Functions.

This problem is expected to be fixed in a future version.

Create Function App and Event Hubs

Create Function App and Event Hubs Namespace by using Azure Portal or ARM Template.

Functions Premium (EP1-3)
- Consumption Plan is not supported.
Event Hubs Namespace (Standard, 1TU)
- Event Hubs are automatically created by Netherite

Since Netherite creates the Event Hub automatically, it is easier to use RootManageSharedAccessKey for the SAS key.

Use 64-bit worker process

FASTER needs to run in a 64-bit process, so change the Platform setting of Azure Functions to 64-bit.

If you run the application with the 32-bit Platform setting, the following exception will be thrown at runtime and it will not work properly.

Part** !!! Encountered exception while working on store in StoreWorker.Process: FASTER.core.FasterException: Overflow in AddressInfo - consider running the program in x64 mode for larger address space support

Note that when you deploy Azure Functions (Windows) from Azure Portal, 32-bit Platform will be selected by default.

Enable Runtime Scale Monitoring

Durable Functions with Netherite installed running on Functions Premium (EP1-3) need to have Runtime Scale Monitoring enabled in order to scale out.

Since Runtime Scale Monitoring requires warmed-up instances, set preWarmedInstanceCount to 1 when creating resources with ARM Template or Terraform.

After these steps, Azure Functions using Netherite is now working perfectly. Now you can verify the performance and have fun.

Writing Static Web Apps configuration with JSON Schema

Tatsuro Shibamura — Thu, 27 May 2021 14:58:10 +0000

Azure Static Web Apps now supports login using external IdPs such as Azure AD and Facebook at the same time as GA.

You do not need to write any additional code for authentication, but you do need to create staticwebapp.config.json.

If you have read the documentation, you must have found it difficult to write the configuration file correctly. I was one of those who felt that way.

Let's use JSON Schema to write a configuration file easily.

Load from Schema Store

JSON Schema for staticwebapp.config.json is already shared by a service called Schema Store.

JSON Schema Store

The URL of the actual JSON Schema is as follows.

https://json.schemastore.org/staticwebapp.config.json

You can load this JSON Schema into any supported editor or IDE for autocompletion and format validation.

My recommendation is Visual Studio Code, but the same feature is available in Visual Studio.

Visual Studio Code

Visual Studio Code has built-in support for JSON Schema, but additional configuration is required to use JSON Schema in certain files.

JSON schemas and settings | JSON editing in Visual Studio Code

Open the settings of Visual Studio Code and search for JSON Schema to find the item.

Add the following definition to json.schemas. As you can see from the fact that it is an array, multiple definitions can be added.

{
  "json.schemas": [
    {
      "fileMatch": [
        "/staticwebapp.config.json"
      ],
      "url": "https://json.schemastore.org/staticwebapp.config.json"
    }
  ]
}

Once you add the JSON Schema definition, the JSON Schema will be automatically loaded when you open staticwebapp.config.json from now on.

As a result, autocomplete using JSON Schema will work in Visual Studio Code.

Since there is no need to manually enter the required properties, the possibility of making a mistake is very low.

Of course, the validation is performed in real time in the editor.

Visual Studio

If you are using Visual Studio, the Schema Store catalog file has already been set up.

If it is not set, manually add the URL of the catalog file.

http://schemastore.org/api/json/catalog.json

According to the file name, the corresponding JSON Schema will be downloaded and used.

Just open staticwebapp.config.json in Visual Studio and you can use IntelliSense for autocompletion.

By using JSON Schema, you can write complex routing and authentication definitions without making any mistakes.

Follow-up on the session at Cosmos DB Conf

Tatsuro Shibamura — Fri, 23 Apr 2021 16:32:49 +0000

This is a follow-up post to the session "Design and implementation of Cosmos DB Change Feed-centric architecture" that @miyake and I spoke at Cosmos DB Conf.

Azure Cosmos DB Conf

It introduces an actual example and implementation of the architecture using Cosmos DB Change Feed.

Live stream and slides

The video and slides of the session are already available. The session itself is conducted in Japanese, but all the slides are prepared in English.

It takes advantage of the high availability and performance of the Cosmos DB Change Feed to make the lambda architecture completely serverless.

Cosmos DB is very reliable, but there are a few caveats that need to be taken into account in order to increase the reliability of the overall architecture.

Here is a related post that picks up on some of the important points.

Batch processing - Change Feed pull model

Use the Pull model to control the pace at which data is read from the Change Feed. This is important when implementing batch processing.

Tatsuro Shibamura

Feb 5 '21

First steps of the Change Feed pull model in Azure Cosmos DB

#azure #cosmosdb #changefeed #serverless

Comments

4 min read

Improving resiliency - Retry policy

The best practice for Change Feed is to use CosmosDBTrigger, but you also need to think about what happens if the funtions fails.

Tatsuro Shibamura

Nov 5 '20

A quick review of the Azure Functions new feature "Retry Policy"

#azure #functions #serverless #eventdriven

Comments 1

2 min read

Avoid inconsistency - Graceful shutdown

We need to be prepared for randomly timed restarts, which is a characteristic of serverless.

Tatsuro Shibamura

Feb 4 '21

Best Practices for Graceful shutdown in Azure Functions

#azure #functions #serverless #dotnet

Comments

3 min read

Coolest tweets

The session was held at the end of the APAC time zone, but it was watched by many people. Thank you!

// Detect dark theme var iframe = document.getElementById('tweet-1384735423021211650-157'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1384735423021211650&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1384737466733645824-411'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1384737466733645824&theme=dark" }

Have fun developing with Cosmos DB Change Feed and Azure Functions!

What I'm doing to implement a modern Azure Functions application

Tatsuro Shibamura — Mon, 15 Mar 2021 17:31:33 +0000

In the past few years, I have been implementing many applications that fully utilize Azure Functions, and at the same time, I have learned how to use Azure Functions without failing.

Recently, I've been doing a lot of hackathons, especially Azure Light-up, and I always try to explain this area whenever I use Azure Functions. In short, we are talking about understanding the advantages and characteristics of Azure Functions and using them wisely.

Always prioritize the use of Bindings / Triggers

One of the best features of Azure Functions is the rich and extensible Bindings and Triggers that I always use.

You don't need to know how to use SDKs such as Azure Storage or Event Hub to use these useful features. Recently, I've been using CosmosDBTrigger a lot.

Azure Functions triggers and bindings concepts | Microsoft Docs

Reading and writing Blobs and Queues is a rather boring part of the code since it is almost the same code, but it requires a fair amount of code, so we use Bindings / Triggers to hide it.

It's also important to focus on the actual business logic.

Keep the Function implementation as small

If the implementation of one function is large, it is often difficult to ensure idempotency and retry, so we basically let one function do only one process.

By using Durable Functions, you can implement applications that work with multiple Functions without being aware of calls between instances, making it easier to keep your Function implementations small.

Azure / azure-functions-durable-extension

Durable Task Framework extension for Azure Functions

By combining single-feature Function with Queue Triger and Cosmos DB Change Feed, we can implement the desired application.

If the responsibilities of the functions are not clearly defined, even deployment will be difficult.

Use the latest patterns in .NET

The latest patterns in .NET does not mean using the latest C# language features, but trying to write code according to the base framework.

Since Azure Functions v3 is based on .NET Core 3.1 / ASP.NET Core 3.1, it is possible to write simple code by following its style. In particular, Dependency Injection has become a must, so I immediately discard static classes and methods that are generated when Visual Studio is created.

Tatsuro Shibamura

Sep 17 '20

A New Era of Azure Functions Development

#azure #functions #dotnet #serverless

Comments

5 min read

However, if you use complex DI, it will have the opposite effect, so I mainly use simple dependency resolution and instance lifetime management as DI without overdoing it.

Design to be retryable

By implementing a function as a single feature, it is easier to deal with retries because there is less to think about. It also makes it easier to ensure idempotency.

The Azure SDK has retries built in from the beginning, so I basically use the built-in retries as is, and use Polly or Azure Function Retry Policy as needed.

Tatsuro Shibamura

Nov 5 '20

A quick review of the Azure Functions new feature "Retry Policy"

#azure #functions #serverless #eventdriven

Comments 1

2 min read

One of the implementations that I try to avoid these days is the case where a single function writes to multiple storage devices. In such a case, use the Event Grid for Blobs to detect event-driven writes to Blobs and perform subsequent writes.

Recently, using Cosmos DB Change Feed, the main function writes to Cosmos DB, while the SQL DB and Blob writes are implemented as separate functions in many cases.

Change feed design patterns in Azure Cosmos DB | Microsoft Docs

This simplifies the processing of each function and makes it easier to retry.

The following is an example of using Cosmos DB Change Feed to write from a single data source to SQL DB and Blob Storage.

public class Function1
{
    [FunctionName("Function1")]
    public async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
        [CosmosDB(
            databaseName: "TestDB",
            collectionName: "Events",
            ConnectionStringSetting = "CosmosConnectionString")] IAsyncCollector<EventData> collector,
        ILogger log)
    {
        // Process using Function input and write to Cosmos DB
        await collector.AddAsync(new EventData
        {
            Id = Guid.NewGuid().ToString()
        });

        return new OkResult();
    }
}

// SQL DB Writer Function
public class Function2
{
    public Function2(AppDbContext appDbContext)
    {
        _appDbContext = appDbContext;
    }

    private readonly AppDbContext _appDbContext;

    [FixedDelayRetry(-1, "00:00:10")]
    [FunctionName(nameof(Function2))]
    public async Task Run(
        [CosmosDBTrigger(
            databaseName: "TestDB",
            collectionName: "Events",
            ConnectionStringSetting = "CosmosConnectionString",
            LeaseCollectionName = "leases",
            LeaseCollectionPrefix = nameof(Function2))]
        JArray input,
        ILogger log)
    {
        var items = input.ToObject<EventData[]>();

        if (items != null && items.Length > 0)
        {
            // Write the data received by the Change Feed to SQL DB
            await _appDbContext.EventData.AddRangeAsync(items);
            await _appDbContext.SaveChangesAsync();
        }
    }
}

// Blob Writer Function
public class Function3
{
    [FixedDelayRetry(-1, "00:00:10")]
    [FunctionName(nameof(Function3))]
    public async Task Run(
        [CosmosDBTrigger(
            databaseName: "TestDB",
            collectionName: "Events",
            ConnectionStringSetting = "CosmosConnectionString",
            LeaseCollectionName = "leases",
            LeaseCollectionPrefix = nameof(Function3))]
        JArray input,
        [Blob("workitems/sample.json", FileAccess.Write)] CloudAppendBlob appendBlob,
        ILogger log)
    {
        var items = input.ToObject<EventData[]>();

        if (items != null && items.Length > 0)
        {
            log.LogInformation("Documents modified " + items.Length);
            log.LogInformation("First document Id " + items[0].Id);

            // Write the data received by the Change Feed to Append Blob
            await appendBlob.AppendTextAsync(JsonConvert.SerializeObject(items));
        }
    }
}

Since each Function does only one thing, the implementation is easy to understand, and you will find that error handling and retry handling are simple.

Lambda architecture - Big data architectures - Azure Architecture Center | Microsoft Docs

Combining Azure Functions with Cosmos DB Change Feed is an easy way to implement a lambda architecture. Both services are highly scalable, making them an excellent choice.

Write code to support Graceful Shutdown

In the past, before deploying to a running Azure Functions, I would check that no processing was taking place in Application Insights, but since Graceful Shutdown started working correctly a while ago, I implemented it to support it, and deployment can be done without being aware of the timing.

Tatsuro Shibamura

Feb 4 '21

Best Practices for Graceful shutdown in Azure Functions

#azure #functions #serverless #dotnet

Comments

3 min read

Some people may think that Graceful Shutdown is not necessary if you use Deployment Slot, but Deployment Slot in App Service / Azure Functions restarts the non-production slot after the warm-up is complete, and replaces the routing.

Therefore, it is important to support Graceful Shutdown even when deploying using Deployment Slot, because there is no guarantee that the process will finish normally before the swap.

Separate the Function App project by feature

To be precise, it is correct to divide the Function App project by the unit of scaling and deployment, but since there are few cases where you can see that area from the beginning, I try to think about separate it by the unit of feature first.

Sometimes I see an application that implements a large number of functions in one Function App, but if the reason for grouping them in one Function App is cost, it is better to reconsider.

Keep in mind that scaling App Service / Azure Functions can only be done per App Service Plan.

Set up a CI / CD pipeline early on

I think it goes without saying that, with the exception of very small applications, we usually create more than one Function App. Since it is not practical to deploy them manually from Visual Studio, we will automate them using GitHub Actions and Azure Pipelines.

If you need a more practical example, please refer to the Azure Functions Boilerplate repository that I created.

shibayan / azure-functions-boilerplate

A boilerplate project for getting started with Azure Functions v4

Deployment itself should not be a problem since it is very easy and Action/Task is provided. In recent years, I've even built a CI/CD pipeline in the middle of a hackathon.

Hope this helps your Azure Serverless life!

DEV Community: Tatsuro Shibamura

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

Generate sequence numbers in Cosmos DB

How to quickly setup a Let's Encrypt certificate in Azure Container Apps

shibayan / containerapps-acmebot

Automated ACME SSL/TLS certificates issuer for Azure Container Apps (Custom domain / Custom DNS Suffix)

Container Apps Acmebot

Motivation

Feature Support

Deployment

Thanks

Deploy Acmebot

Setup RBAC (IAM) for Acmebot

Issue certificate

Bind to Container App

Renew certificates

Related post

Collecting Cosmos DB dependency telemetry with Application Insights

Azure / azure-cosmos-dotnet-v3

.NET SDK for Azure Cosmos DB for the core SQL API

Microsoft Azure Cosmos DB .NET SDK Version 3

How to build an interactive command-line application in .NET

shibayan / Sharprompt

Interactive command-line based application framework for C#

Sharprompt

Features

Installation

Quick start

Example: create-function-app

shibayan / create-function-app-mock

Sharprompt demo application

How to use Netherite Storage Provider in Durable Functions

microsoft / durabletask-netherite

A new engine for Durable Functions. https://microsoft.github.io/durabletask-netherite

Netherite

The `skip_app_build` Option Isn't Enough

The Solution: `shibayan/swa-deploy`

Using `azure/login`

Preserve `System.Threading.Channels.dll`