Feature flags rarely live in just one place. You may have a vendor service, some environment-based overrides, and a couple of in-memory fallbacks hidden within your app. OpenFeature's MultiProvider lets you compose all of these behind a single, clean client in your .NET applications.​

If you’re interested in standardising and streamlining feature flag management across different tools and platforms, consider exploring the OpenFeature project. OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging. It allows you to integrate with your favourite feature flag management tool or in-house solutions without vendor lock-in. It supports many programming languages and makes switching providers or consolidating multiple solutions behind a single interface easy. To learn more about how OpenFeature can enhance your development workflow, visit the OpenFeature website.

In this post, you'll see how to wire up OpenFeature.Providers.MultiProvider with dependency injection, how strategies decide which provider "wins," and a few practical patterns like primary/fallback, migrations, and tenant-specific routing.​

TL;DR

• OpenFeature.Providers.MultiProvider is a composite FeatureProvider for the OpenFeature .NET SDK.​
• It allows you to register multiple underlying providers and select a strategy for routing and combining evaluations.​
• You configure it with:
  -AddMultiProvider(...) when using dependency injection, or
  -new MultiProvider(IEnumerable<ProviderEntry>, IStrategy) when bootstrapping manually.​
• Your application code continues to use Api.Instance.GetClient(...).GetXxxValueAsync(...) the MultiProvider hides all routing logic.​

What the MultiProvider Actually Is

In OpenFeature, a FeatureProvider abstracts "where flags come from" for a client. A typical provider wraps a single backend, such as a remote flag service, a configuration file, or an in-memory map.​

OpenFeature.Providers.MultiProvider changes that model slightly.​

• It is itself a FeatureProvider.
• Internally, it holds a collection of ProviderEntry instances, each wrapping a concrete FeatureProvider plus an optional name.​
• A strategy (for example, FirstMatchStrategy) decides:
  - Which underlying provider(s) to call for a given flag key.
  - How to combine or short-circuit their results.

Because MultiProvider is still just a FeatureProvider, you can set it as either the default provider or a named "domain" provider in your DI configuration.​

Wiring MultiProvider with Dependency Injection

The recommended way to use MultiProvider in .NET is through the OpenFeature hosting/DI integration. You typically start with something like this:​

using Microsoft.Extensions.DependencyInjection;
using OpenFeature.Hosting;
using OpenFeature.Providers.MultiProvider.DependencyInjection;

// inside Program.cs or equivalent bootstrapping:
var services = new ServiceCollection();
services.AddOpenFeature(featureBuilder =>
{
    featureBuilder
        .AddMultiProvider("multi-provider", multiProviderBuilder =>
        {
            // configure providers + strategy here
        });
});

A few key points about what happens here:​

• AddOpenFeature(...) gives you an OpenFeatureBuilder.
• AddMultiProvider(...) (extension method from FeatureBuilderExtensions):
  - Creates a MultiProviderBuilder.
  - Let's you register multiple inner providers.
  - Registers the constructed MultiProvider as the provider for the given domain (for example, "multi-provider").​

You later consume it like any other OpenFeature client:

// After building the ServiceProvider and starting the host:
var client = sp.GetService<IFeatureClient>();
var value = await client.GetBooleanValueAsync("my-flag", defaultValue: false);

The client is unaware that a MultiProvider backs it; it just sees a standard OpenFeature provider.​

Adding Providers: Factories, Instances, and Types

MultiProviderBuilder gives you several ways to add underlying providers so you can match whatever style your composition root uses.​

Factory-based (DI-friendly) registration

In DI-centric apps (ASP.NET Core, generic host, etc.), a factory-based approach is often the most flexible:

using OpenFeature.Providers.MultiProvider.DependencyInjection;

// Inside AddOpenFeature(...)
featureBuilder.AddMultiProvider("multi-provider", multiProviderBuilder =>
{
    multiProviderBuilder
        // Provider registered with a simple factory
        .AddProvider("primary", sp =>
        {
            // sp is the IServiceProvider
            var flags = new Dictionary<string, bool>
            {
                { "my-flag", true }
            };
            return new InMemoryProvider(flags);
        })
        .AddProvider("fallback", sp =>
        {
            // Example of a fictional provider with DI dependencies
            var httpClient = sp.GetRequiredService<HttpClient>();
            return new MyCompanyFeatureProvider(httpClient);
        });
});

Notes:​

• Each call to .AddProvider(...) registers one underlying FeatureProvider.
• The name ("primary", "fallback") is mainly for strategies and logging; your application code rarely references it directly.​
• The factory receives the IServiceProvider, so that you can resolve any dependencies from the container.​

Registering existing instances

If you already have provider instances created in your composition root, you can add them directly:

var primaryProvider = new InMemoryProvider(primaryFlags);
var fallbackProvider = new InMemoryProvider(fallbackFlags);
featureBuilder.AddMultiProvider("multi-provider", multiProviderBuilder =>
{
    multiProviderBuilder
        .AddProvider("primary", primaryProvider)
        .AddProvider("fallback", fallbackProvider);
});

This behaviour is handy when you want explicit construction logic or to reuse a provider across multiple domains.​

Type-based registration

You can also let DI construct the providers, optionally customising them via a factory:

featureBuilder.AddMultiProvider("multi-provider", multiProviderBuilder =>
{
    multiProviderBuilder
        // Provider resolved from DI
        .AddProvider<MyCompanyFeatureProvider>("primary")
        // Provider resolved from DI but customized by a factory
        .AddProvider<MyCompanyFeatureProvider>("secondary", sp =>
        {
            var config = sp.GetRequiredService<MyProviderConfig>();
            return new MyCompanyFeatureProvider(config);
        });
});

In this case, MyCompanyFeatureProvider must itself be registered with the container, for example, with services.AddSingleton<MyCompanyFeatureProvider>();.​

Strategies: How Evaluations Are Combined

Multiple providers alone are not enough; the MultiProvider needs a strategy to decide how to evaluate them and when to stop. Strategies live under OpenFeature.Providers.MultiProvider.Strategies and implement the logic for:​

• Which provider(s) to try for a given flag key?
• Whether to short-circuit or continue "flag not found"?
• How to interpret errors vs. "not found"?​

Configuring a strategy via DI

With DI, you typically chain .UseStrategy<TStrategy>() on the builder:

using OpenFeature.Providers.MultiProvider.Strategies;

featureBuilder.AddMultiProvider("multi-provider", multiProviderBuilder =>
{
    multiProviderBuilder
        .AddProvider("primary", sp => new InMemoryProvider(primaryFlags))
        .AddProvider("secondary", sp => new InMemoryProvider(secondaryFlags))
        .UseStrategy<FirstMatchStrategy>(); // default-style strategy
});

FirstMatchStrategy behaves conceptually like this:​

• Evaluate providers in the registered order.
• Return the first successful result for the requested flag key.
• If a provider reports FLAG_NOT_FOUND, move on to the next.
• If all providers fail or do not have the flag, surface the appropriate error or default.​

This strategy is ideal when you want a "primary provider plus fallback" pattern, where one provider is considered the source of truth, and the others only step in if needed.​

Strategy-driven routing patterns

By swapping or customising strategies, you can implement a few common patterns without changing call sites:​

Override provider

• One provider holds overrides for specific keys or tenants (for example, environment variables or admin overrides).
• If it does not handle a flag, the strategy falls back to a base provider.

Migration provider

• One provider represents the "new" system and another the legacy system.
• The strategy prefers the new provider but falls back when a flag is missing, so you can move flags gradually.​

Key or tenant-based routing

• A custom strategy can be routed based on flag key patterns or evaluation context (for example, tenant ID in the context).
• The logic lives in the Strategies namespace instead of being scattered through business logic.​

The key takeaway is that routing remains within the MultiProvider + strategy, not within your controllers, services, or repositories.​

Manual Setup Without Dependency Injection

If you are not using the hosting/DI integration, you can construct the MultiProvider directly and set it on the Api. The pattern is straightforward:​

using OpenFeature;
using OpenFeature.Providers.InMemory;
using OpenFeature.Providers.MultiProvider;
using OpenFeature.Providers.MultiProvider.Models;
using OpenFeature.Providers.MultiProvider.Strategies;

// Create inner providers
var provider1 = new InMemoryProvider(provider1Flags);
var provider2 = new InMemoryProvider(provider2Flags);

// Wrap them into ProviderEntry instances
var entries = new List<ProviderEntry>
{
    new(provider1, "Provider1"),
    new(provider2, "Provider2")
};

// Build the MultiProvider
var strategy = new FirstMatchStrategy();
var multiProvider = new MultiProvider(entries, strategy);

// Register it as the default provider
await Api.Instance.SetProviderAsync(multiProvider);

// Use normally
var client = Api.Instance.GetClient();
var value = await client.GetBooleanValueAsync("my-flag", defaultValue: false);

Your client code does not change if you later swap InMemoryProvider for MyCompanyFeatureProvider or update the provider list and strategy.​

Concrete Use Cases

Here are a few scenarios where MultiProvider shines in .NET applications:​

Primary + fallback provider

• Primary: a remote provider (for example, your company's feature flag service).
• Fallback: an in-memory provider with safe defaults or local overrides.
• Strategy: FirstMatchStrategy, so you hit the primary first and only fall back when needed.​

This strategy enables you to maintain a single OpenFeature client while still achieving layered resilience and overrides.

Gradual migration between systems

• Providers: LegacyFeatureProvider and NewFeatureProvider.
• Strategy: try the new provider first; if a flag is missing, fall back to the legacy provider.​

You can migrate flags to the new system incrementally, without changing call sites or deploying invasive refactorings.​

Tenant-specific providers with a custom strategy

• Each tenant may get its own provider instance or configuration.
• A custom strategy inspects the evaluation context (for example, tenantId) and routes to the right provider entry.​

This behaviour keeps tenant routing logic out of your business code and inside a testable, composable strategy.

Error Handling, Thread Safety, and Lifecycle

MultiProvider is designed to behave like any other provider from the client's perspective, including error handling and lifecycle.​

Error handling

• MultiProvider aggregates errors from underlying providers according to the chosen strategy.
• The OpenFeature SDK still returns the usual resolution result; the strategy decides how to interpret partial failures or multiple issues.​

Thread safety

• MultiProvider is designed for concurrent use in typical .NET scenarios (for example, ASP.NET Core, background services).

Lifecycle

• As a FeatureProvider, MultiProvider participates in initialisation and shutdown.
• When you shut down the host or dispose of the provider, underlying providers are disposed of as needed.​

These details mostly "just work," which means you can focus on provider composition and strategy choice rather than on mechanics.

One Client, Many Providers

Once MultiProvider is wired in, your application code keeps calling Api.Instance.GetClient(...).GetXxxValueAsync(...) as usual. Behind that single client, you can combine vendors, environment overrides, in-memory defaults, and tenant-specific logic with a pluggable strategy.​

If you are standardising feature flags across multiple .NET services, MultiProvider is a pragmatic way to grow from "one provider per app" to a more flexible, layered model without rewriting call sites.​

For many projects, reality looks different: contributors waste hours wrestling with tricky setups, dependency hell, or platform quirks. Some give up before their first PR. As maintainers of the OpenFeature .NET SDK, this problem hit home for us. But with Dev Containers and GitHub Codespaces, we flipped the script.

The Friction Crisis: Why Setup Kills Contributions

Ask any open source maintainer about the most significant hurdle facing new contributors, and they’ll point to complex setup instructions and inconsistent environments. Developer onboarding friction is a well-known barrier to success. For example:

• Platform mismatches (M1/M2 Macs, Windows WSL, Linux variants)
• The infamous “works on my machine” syndrome
• Hours lost before even running dotnet build

While surveys indicate that motivation to contribute is high, hidden technical barriers often hinder progress. What does this cost maintainers? Fewer contributors, less innovation, and more “support” time untangling setup issues instead of reviewing code.

Dev Containers: The Five-Minute Onboarding Dream

Dev Containers enable us to define everything about a project’s development environment, which means that OS, dependencies, tools and even extensions are specified in code. Pair that with GitHub Codespaces and suddenly, onboarding is instant and reproducible. GitHub Codespaces is a browser-based, one-click workspace that runs these containers.

How We Did It: Applying Dev Containers to OpenFeature .NET SDK

When we introduced devcontainers to our OpenFeature .NET SDK repo:

1. Standardised Setup: .devcontainer/devcontainer.json codified our build tools, base images, and extensions. Every Codespace runs identically.
2. Cloud-Native Ready: We added patterns for orchestrating the E2E tests, making experimentation nearly effortless.
3. Samples project: We have a sample project where new contributors can easily play and test the changes.

Practical Tips for Maintainers

Want to replicate this success? Here’s what worked for us:

• Start simple: Add a basic .devcontainer/devcontainer.json setup with your essential tools.
• Show, don’t tell: Badge your repository and update the documentation to highlight “one-click” setups.
• Iterate: Gather contributor feedback and keep evolving your environment. Dev Containers are flexible and easy to update.
• Measure: Track key metrics such as time-to-first-PR and issue closure rates.
• Leverage Templates: Use (or create) Dev Container templates tailored for your specific tech stack, cloud-native or multi-language projects.

Codespaces: Making Dev Containers Accessible for All

With GitHub Codespaces, the barriers continue to fall and anyone can contribute.

• Educational sandboxes: Want to run docs or tests only? Pre-configure lightweight containers for these tasks.
• Onboard maintainers: Codify advanced setups like CI, local clusters and secrets, so your core team’s environment is as solid as your newcomers’.

The Broader Impact

Lowering the bar for entry created a welcoming, low-friction experience that keeps people coming back and raises the overall quality of our project.

Key Resources

• OpenFeature .NET SDK with Dev Containers
• Dev Containers Specification
• GitHub Codespaces Documentation

C# 14 is here, and it’s packed with updates designed to make your code cleaner, faster, and more enjoyable to write. Whether you’re maintaining legacy systems or building new apps on .NET 10, these new features will modernise your workflows and unlock new power.

Extension Members: Levelling Up Extensions

If you like extension methods, you’re going to love the new extension blocks. In C# 14, you can declare extension methods, properties, and even indexers more naturally.

Old extension method:

public static class IntegerExtensions
{
    public static bool IsDefault(this int value) => value == 0;
}

New extension block:

public static class IntegerExtensions
{
    extension(int value)
    {
        public bool IsDefault() => value == 0;
    }
}

Now, everything you extend gets grouped, with methods, properties, and even private fields for caching.

Extension Properties & Indexers: Cleaner API for Collections

Stop writing helper methods everywhere. Add properties and indexers so your code reads naturally:

public static class CollectionExtensions
{
    extension<T>(IEnumerable<T> source)
    {
        public bool IsEmpty => !source.Any();
        public int Count => source.Count();
    }
}

Use IsEmpty in your collection and your intent shine through. There is no need for more confusing method calls.

Private Fields in Extensions: Cache Like a Pro

Extension blocks give you private fields for expensive computations:

public static class CollectionExtensions
{
    extension<T>(IEnumerable<T> source)
    {
        private int? _count;

        public bool IsEmpty => !source.Any();
        public int Count => _count ??= source.Count();
    }
}

This feature maintains performance while keeping your API clean.

Static Extension Members: Utility Methods for Types

You can add static helpers and factory methods.

public static class UserExtensions
{
    extension(User)
    {
        public static User CreateDefault() => new User {...};
    }
}
var user = User.CreateDefault();

Null-Conditional Assignment: Safer, Shorter Code

Skip manual null checks:

var user = GetUser();
user?.Profile = LoadProfile();

This is cleaner and consistent, making your code safer and easier to read.

The field Keyword: No More Backing Fields

Use the new field keyword to reference auto-generated property backing fields, simplifying lazy initialisation:

public class User
{
    public string FirstName
    {
        get => field ??= "John";
        set => field = value;
    }
}

Less boilerplate, more clarity. If you already have a property called field, you can use @field for example:

public class User
{
    private string field;

    public string FirstName
    {
        get => @field ??= "John";
        set => @field = value;
    }
}

Lambda Parameters With Modifiers: Shorter, Smarter Functions

Modifiers like ref, out, and in work in lambda expressions. No full type needed:

TryParse<int> parse = (text, out result) => int.TryParse(text, out result);

Partial Constructors & Events: More Modular Code

Split the constructor/event logic across files for better organisation and source generation:

public partial class User
{
    public partial User(string name);
}
// ... implementation elsewhere

More Highlights

• Implicit conversions between Span<T>, ReadOnlySpan<T>, and arrays for easier, safer memory handling.
• nameof operator upgrades: supports generic types for better diagnostics and metaprogramming.
• Custom compound assignments: define your own logic for operators like +=.
• Full support in .NET 10 and modern toolchains.

Final Thoughts

C# 14 makes extension members, null handling, and API design more elegant. With features that reduce boilerplate and add expressive power, the language is more intuitive than ever. Start exploring these updates and see all the details here.

The Legacy Approach: Secrets Everywhere

Traditionally, publishing packages meant generating API tokens and storing them in GitHub as repository secrets. This approach comes with apparent drawbacks:

• Security risks: If a token leaks, attackers gain unfettered publish access.
• Rotation headaches: Expiring tokens require manual maintenance.
• Auditing gaps: It's hard to know which token was used and when.
• Blast radius: One compromised token threatens all packages.

OIDC Authentication: No More Secrets

We moved to OpenID Connect (OIDC) for credential-free authentication. Instead of storing secrets, GitHub Actions now generate a short-lived identity token at the time of publication. Our workflow grants only the permissions needed, with id-token: write for OIDC.

Implementation Steps

• Enable trusted publishing in your package registry (such as NuGet in our case).
• Configure GitHub Actions to only run on merges to main.
• Utilise environmental protection to require manual approvals for production.

Key Benefits

• Tokens are meticulously designed for single-use applications, ensuring a clear and transparent association with each publication, which is linked directly to an identifiable workflow run.
• This strategy significantly reduces the potential for security breaches, as each token is restricted to a single workflow. By implementing this method, we not only enhance the integrity of our processes but also strengthen our overarching security strategy, ensuring that every transaction and data flow remains protected and accountable. This approach creates a structured environment where risks are minimised, promoting trust and reliability in our operations.

name: Release
on:
  push:
    branches:
      - main
permissions:
  id-token: write      # For OIDC authentication
jobs:
  release:
    runs-on: ubuntu-latest
    environment:
      name: nuget-production
    steps:
        # Get a short-lived NuGet API key
      - name: NuGet login (OIDC → temp API key)
        uses: NuGet/login@d22cc5f58ff5b88bf9bd452535b4335137e24544 # v1
        id: login
        with:
          user: ${{secrets.NUGET_USER}}

      - name: Publish to Nuget
        run: dotnet nuget push "src/**/*.nupkg" --api-key "${{ steps.login.outputs.NUGET_API_KEY }}" --source https://api.nuget.org/v3/index.json

SBOMs: Transparency by Default

A Software Bill of Materials (SBOM) is like a nutrition label for your package: every dependency and version listed for all to see. It helps with CVE management, regulatory compliance, and trust.

We created a composite GitHub Action using CycloneDX:

• Generates SBOMs for every package before distribution.
• Attests authenticity using GitHub's action for keyless signing.
• Uploads SBOMs as downloadable GitHub artefacts.

Every published package gets:

• A machine-readable SBOM
• A cryptographic attestation
• Provenance consumers can audit (when they choose to)

name: "Generate and Attest SBOM"
description: "Generate SBOM for a .NET project, upload it to a release, and create an attestation"

inputs:
  github-token:
    description: "GitHub token for uploading the SBOM to the release"
    required: true
  project-name:
    description: "Name of the project for SBOM generation"
    required: true
  release-tag:
    description: "Tag name for the release"
    required: true

runs:
  using: "composite"
  steps:
    - name: Install CycloneDX.NET
      shell: bash
      run: dotnet tool install --global CycloneDX --version 5.2.0

    - name: Generate SBOM
      shell: bash
      run: |
        # Create artifacts/sboms directory if it doesn't exist
        mkdir -p ./artifacts/sboms/
        # Generate SBOM using CycloneDX
        dotnet CycloneDX --json --exclude-dev -sv "${{ inputs.release-tag }}" ./src/${{ inputs.project-name }}/${{ inputs.project-name }}.csproj --output ./artifacts/sboms/ -fn ${{ inputs.project-name }}.bom.json

    - name: Upload SBOM to release
      shell: bash
      env:
        GITHUB_TOKEN: ${{ inputs.github-token }}
      run: |
        gh release upload ${{ inputs.release-tag }} ./artifacts/sboms/${{ inputs.project-name }}.bom.json

    - name: Attest package
      uses: actions/attest-sbom@4651f806c01d8637787e274ac3bdf724ef169f34 # v3.0.0
      with:
        subject-path: src/**/${{ inputs.project-name }}.*.nupkg
        sbom-path: ./artifacts/sboms/${{ inputs.project-name }}.bom.json

Renovate: Keeping Dependencies Up To Date

Outdated dependencies are a classic source of vulnerabilities. We use Renovate to keep our packages, build tools, and GitHub Actions up to date automatically.

Renovate creates pull requests whenever:

• A new patch or minor version is released
• Security advisories affect our dependencies
• Key GitHub Actions have upstream updates

We have scheduled upgrades for our production dependencies and enabled auto-merging for development tools. This approach keeps our SBOM up to date, reduces manual effort, and ensures that we can quickly address issues with upstream fixes. Reviewing Renovate pull requests (PRs) has become a regular part of our maintenance process, significantly enhancing our security.

Note: GitHub’s Dependabot can perform similar updates and is also a great option for automating dependency management. We chose Renovate for its advanced customization, broader ecosystem support, and detailed PR metadata.

CodeQL: Automating Static Analysis for Vulnerabilities

Ensuring supply chain security involves identifying vulnerabilities before code is shipped. We utilise CodeQL, GitHub's static analysis tool, to automatically scan all code changes for known patterns of insecure code, injection flaws, and risks from dependencies.

How it works:

• CodeQL runs on every PR, push to main and in a defined schedule
• Scans .NET, YAML, and JavaScript code (where applicable)
• Flags suspect code for review alongside test results

CodeQL has identified risky constructs, code smells, and insecure usages that would be difficult to spot in a review alone. If a vulnerability is found, the CI fails, and we fix it before merging. This process builds confidence in every release.

GitHub Actions Security: SHAs and Permission Scoping

To use GitHub Actions safely, treat them like any other dependency by pinning them to commit SHA (short for "hash") instead of tags.

Tags can be moved or overwritten. A compromised action repository could point v1 to malicious code tomorrow. By pinning to the full SHA, you ensure the exact code version you've reviewed runs every time:

- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332  # v4.1.7

Renovate or Dependabot keeps these SHAs updated, and we can review changes in PRs before merging.

Permission scoping is just as critical. We explicitly declare minimal permissions for GITHUB_TOKEN at the workflow level:

permissions:
  contents: read
  id-token: write
  actions: read

Never grant blanket write-all permissions. Each workflow gets only what it needs. This limits the damage if a workflow or third-party action is compromised.

Why this matters:

• Prevents tag confusion attacks
• Reduces the blast radius of compromised actions
• Creates an audit trail for every action version change
• Forces intentional permission grants

These are small changes that dramatically reduce supply chain risk.

Multi-Platform Testing: Matrix Builds

Our SDK targets Linux, Windows, macOS, x64, ARM64, and multiple .NET versions. Complete coverage isn't practical (macOS and Windows runners are expensive), so we use matrix builds for the most critical combinations. This job catches:

• NativeAOT issues on ARM64
• Platform-specific bugs and API behaviours
• Version/dependency conflicts

Artefacts and test results are kept separate for each configuration and uploaded to Codecov for coverage tracking.

Build Attestations: Trust, Not Just Locks

The build attestations create a record which is cryptographically stored:

• Where artefacts were built
• When (timestamp)
• How (build commands, dependencies)
• Who authorised them

We use GitHub's own action in our workflows to generate these signatures. Anyone can verify using the GitHub CLI tool.

Honest Truth: Very few consumers verify build attestations today. We're laying the groundwork:

• It's easy (about 30 seconds extra per build)
• Prepares us for future compliance
• It's simply the right thing to do

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@977bb373ede98d70efdf65b84cb5f73e068dcc2a # v3.0.0
  with:
    subject-path: "src/**/*.nupkg"

Automation: The Maintainer Experience

Release Please automates nearly everything:

• Analyses commits for semantic versioning
• Generates release notes and change logs
• Opens and merges release PRs
• Publish packages when ready

We enforce quality gates on every PR (commit formatting, DCO checks, scope validation), and use caching to reduce CI times.

Conclusion

As an open-source project, we faced a choice: implement supply chain security. The results:

• No secrets kept or rotated
• Comprehensive CI/CD in GitHub's free tier
• Audit trails and provenance established
• Most work automated

Security doesn't have to be complicated. With today's open source tools, it's mostly about persistence and learning.

You can find these techniques in the following repository: https://github.com/open-feature/dotnet-sdk

If you’re interested in standardizing and streamlining feature flag management across different tools and platforms, consider exploring the OpenFeature project. OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging. It allows you to integrate with your favourite feature flag management tool or in-house solutions without vendor lock-in. It supports many programming languages and makes switching providers or consolidating multiple solutions behind a single interface easy. To learn more about how OpenFeature can enhance your development workflow, visit the OpenFeature website.

Introduction​

This walk-through teaches you the basics of using OpenFeature in .net within an ASP.NET Core Web application written in F#.

You’ll learn how to:

• Integrate the OpenFeature .net SDK
• Install and configure the OpenFeature provider
• Perform basic feature flagging

Requirements​

This walk-through assumes that:

• You have a basic knowledge of F# and .net
• You have installed the .net 8 or later SDK
• You have Docker installed and running on the host system

Walk-through​

Step 1: Create a .net 8 Web application​

To get started, you can use the .net SDK to initialise a web application. Open a terminal (shell, Command Prompt, or bash) and paste the following commands:

dotnet new webapi -o openfeature-fsharp-sample -lang F#
cd openfeature-fsharp-sample
dotnet run

Step 2: Add dependencies​

You can install the latest OpenFeature and OpenFeature.Contrib.Providers.Flagd packages into your .net web application with NuGet.

dotnet add package OpenFeature
dotnet add package OpenFeature.Contrib.Providers.Flagd

Step 3: Add code​

The following will initialise an FlagD provider for use within the web application. Open a code editor and add the F# code below to the Program.fs.

namespace openfeature_fsharp_sample

#nowarn "20"

open System
open Microsoft.AspNetCore.Builder
open Microsoft.Extensions.DependencyInjection
open Microsoft.Extensions.Hosting
// Adding the namespaces here
open OpenFeature
open OpenFeature.Contrib.Providers.Flagd

module Program =
    let exitCode = 0

    [<EntryPoint>]
    let main args =

        let builder = WebApplication.CreateBuilder(args)

        builder.Services.AddControllers()

        let app = builder.Build()
        
        // Register your feature flag provider
        Api.Instance.SetProviderAsync(new FlagdProvider(new Uri("http://localhost:8013"))).Wait()

        app.UseHttpsRedirection()

        app.UseAuthorization()
        app.MapControllers()

        app.Run()

        exitCode

Now let's edit WeatherForecastController.fs to include the feature flag client call.

namespace openfeature_fsharp_sample.Controllers

open System
open Microsoft.AspNetCore.Mvc
open Microsoft.Extensions.Logging
open openfeature_fsharp_sample
// Adding the namespaces here
open OpenFeature

[<ApiController>]
[<Route("[controller]")>]
type WeatherForecastController(logger: ILogger<WeatherForecastController>) =
    inherit ControllerBase()

    let summaries =
        [| "Freezing"
           "Bracing"
           "Chilly"
           "Cool"
           "Mild"
           "Warm"
           "Balmy"
           "Hot"
           "Sweltering"
           "Scorching" |]

    // Changing the get response
    [<HttpGet>]
    member _.Get() =
        async {
            // Geting the current instance of the client
            let client = Api.Instance.GetClient()
            
            // The flag is evaluated here
            let! flag =
                client.GetBooleanValueAsync("weather-forecast-return-5", false)
                |> Async.AwaitTask

            let rng = Random()
            // if flag is true, we should return 5, otherwise 3
            let count = if flag then 5 else 3

            return
                [| for index in 0 .. (count - 1) ->
                       { Date = DateTime.Now.AddDays(float index)
                         TemperatureC = rng.Next(-20, 55)
                         Summary = summaries.[rng.Next(summaries.Length)] } |]
        }

Step 4: Run the initial application​

Let’s compile and run the application.

dotnet build
dotnet run

You should see a line in the logs with the following: Now listening on: http://localhost:5251, although the port number may differ. You can visit the following URL in your browser: http://localhost:5251/weatherforecast (adjust port number as necessary). You should see a list with 3 weather forecasts.

“Why am I seeing that value?”, you may ask. Well, it’s because a provider hasn’t been configured yet. Without a provider to actually evaluate flags, OpenFeature will return the default value. In the next step, you’ll learn how to add a provider.

Step 5: Configure a provider (flagd)​

Providers are an important concept in OpenFeature because they are responsible for the flag evaluation. As we saw in the previous step, OpenFeature without a provider always returns the default value. If we want to actually perform feature flagging, we’ll need to register a provider.

Create a new file named flags.flagd.json and add the following JSON. Notice that there's a flag called weather-forecast-return-5 which matches the flag key referenced earlier. The weather-forecast-return-5 flag has on and off variants that return true and false respectively. The state property controls whether the feature flag is active or not. Finally, the defaultVariant property controls the variant that should be returned. In this case, the defaultVariant is off, the value false would be returned.

{
  "flags": {
    "weather-forecast-return-5": {
      "variants": {
        "on": true,
        "off": false
      },
      "state": "ENABLED",
      "defaultVariant": "off"
    }
  }
}

NOTE: This configuration is specific for flagd and varies across providers.

With the flagd configuration in place, start the flagd service with the following Docker command.

NOTE: On Windows WSL is required both for running docker and to store the file. This is a limitation of Docker (https://github.com/docker/for-win/issues/8479)

docker run -p 8013:8013 -v $(pwd)/:/etc/flagd/ -it ghcr.io/open-feature/flagd:latest start --uri file:/etc/flagd/flags.flagd.json

Step 6: Change the flags (flagd)​

Let’s change the feature flag in our flags.flagd.json, making defaultVariant to on

{
  "flags": {
    "welcome-message": {
      "variants": {
        "on": true,
        "off": false
      },
      "state": "ENABLED",
      "defaultVariant": "on"
    }
  }
}

Revisit the endpoint http://localhost:5251/weatherforecast. You will see a list with 5 weather forecasts.

References

• https://openfeature.dev/docs/tutorials/getting-started/dotnet
• https://openfeature.dev/
• https://flagd.dev/

If you’re interested in standardizing and streamlining feature flag management across different tools and platforms, consider exploring the OpenFeature project. OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging. It allows you to integrate with your favourite feature flag management tool or in-house solutions without vendor lock-in. It supports many programming languages and makes switching providers or consolidating multiple solutions behind a single interface easy. To learn more about how OpenFeature can enhance your development workflow, visit the OpenFeature website.

Managing secrets securely in CI/CD pipelines is a critical challenge, especially for organizations with multiple repositories, complex permission structures, and a need to balance developer productivity with robust security. Here's why we decided to use environments to store our secrets:

Scale: Many Repositories Publishing Libraries

With many repositories, each potentially publishing library, the risk of secret sprawl and accidental exposure increases. Centralizing secrets in environments allows us to:

• Avoid duplicating secrets across repositories, reducing the attack surface and simplifying management
• Enforce consistent security policies and access controls across all projects

Permission Model: Approvers vs. Maintainers

Our workflow distinguishes between approvers and maintainers:

• Both roles have write permissions, but maintainers have higher trust.
• Only maintainers can merge main due to CODEOWNERS and branch protection rules, giving them control over what gets published.

However, approvers can create branches and propose changes, including workflow modifications. This behaviour creates a risk: if secrets are accessible in all branches, an approver could (intentionally or accidentally) exfiltrate secrets or trigger unauthorized publishing by modifying workflows.

Limiting Secret Exposure: Main Branch-Only Access

By configuring secrets to be accessible only in workflows running on the main branch (using environment protection rules), we achieve several security benefits:

• Prevents Exfiltration: Secrets are unavailable to workflows running on a feature or non-main branches. So, even if an approver creates a branch with a malicious workflow, it cannot access the secrets.
• Stops Unauthorized Publishing: Only code that has passed through the required review and merge process (i.e., merged to main by a maintainer) can access the secrets needed for publishing and closing a significant attack vector.
• Implements Least Privilege: Secrets are only available where necessary, following the principle of least privilege and reducing the risk of accidental or malicious misuse.

Real-World Precedents and Risks

Several high-profile breaches have demonstrated the dangers of insufficient secret management in CI/CD:

• The Codecov breach allowed attackers to exfiltrate secrets from environment variables in thousands of build pipelines.
• Overly permissive access controls have led to attackers publishing malicious code or stealing credentials from CI/CD systems.

We directly address these risks by restricting secret access to protected environments and mainline workflows.

Our Approach

We decided to leverage the GitHub environments feature to store our publishing secrets. This way, only the pipeline that was triggered in main is used.

Creating a new environment

To create a new environment on GitHub, navigate to your repository's Settings and select Environments from the sidebar. Click New Environment, provide a name (we used "publish"), and proceed to configure it. Once the environment is created, you can add secrets by selecting it, clicking Add secret, entering a name and value for the secret (for example, NUGET_TOKEN), and saving it. These secrets will only be accessible to workflows that reference this environment.

To restrict deployments to a specific branch, such as main, edit the environment's protection rules. Under the environment settings, find the Deployment branches section and choose Selected branches. Add main (or your desired branch) to ensure only workflows triggered from this branch can access the environment and its secrets.

Configure the GitHub Action

In your GitHub Actions workflow file, you must specify the environment for the relevant job by adding the environment key. For example:

jobs:
 deploy:
 runs-on: ubuntu-latest
 environment: publish
 steps:
 # your deployment steps here

This change ensures that the job only runs with access to
the environment’s secrets if triggered from the allowed branch.
As shown above, you must update your workflow YAML to include the environment field for the deployment job.

References

• https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment
• https://github.com/open-feature/dotnet-sdk/pull/431
• https://openfeature.dev/

The Directory.Build.props and Directory.Packages.props are files allowing the developer to share configurations and variables between different dotnet projects in the same repository. This makes enforcing the projects following the same rules, such as the Language version or even the dotnet target framework, easier. Please note that the file Directory.Build.props must be in the repository’s root folder or the solution to all children’s projects that need to be affected.
Let’s see an example of this Directory.Build.props file.

Directory.Build.props

<Project>
    <!-- Shared Settings -->
    <PropertyGroup>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
        <LangVersion>latest</LangVersion>
        <Nullable>enable</Nullable>
        <ImplicitUsings>enable</ImplicitUsings>
    </PropertyGroup>
    <!-- Versions -->
    <PropertyGroup>
        <AspNetCoreVersion>5.0.0</AspNetCoreVersion>
        <EntityFrameworkVersion>5.0.2</EntityFrameworkVersion>
    </PropertyGroup>
</Project>

Project.csproj

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

    <!-- Specific project properties that override the properties present on Directory.Build.props -->
    <PropertyGroup>
        <TargetFramework>net5.0</TargetFramework>
        <LangVersion>latest</LangVersion>
    </PropertyGroup>

    <!-- Nuget packages using the version from Directory.Build.props -->
    <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Server" Version="$(AspNetCoreVersion)" />
        <PackageReference Include="Microsoft.AspNetCore.Mvc.NewtonsoftJson" Version="$(AspNetCoreVersion)" />
        <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="$(AspNetCoreVersion)" />
        <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="$(AspNetCoreVersion)" />
        <PackageReference Include="Microsoft.AspNetCore.Identity.UI" Version="$(AspNetCoreVersion)" />
        <PackageReference Include="Microsoft.AspNetCore.ApiAuthorization.IdentityServer" Version="$(AspNetCoreVersion)" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="$(EntityFrameworkVersion)" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="$(EntityFrameworkVersion)" />
    </ItemGroup>

    <!-- Other properties here -->

</Project>

Using it as a versioning system for NuGet dependencies

As shown in the top two files, we are creating a variable named AspNetCoreVersion in the Directory.Build.props. Using that, we can ensure that all the packages that use that variable as a version number will use the same version. We can prevent multiple updates and mismatch versions by only controlling one variable.

Integration with dependabot

Integrating this way of versioning the dependencies works well with dependabot. The bot will give us a list of affected packages that will affect the change of the version. For example, in the example above, the bot would create a new pull request for EntityFrameworkVersion stating that it is going to upgrade from 1.0.0 to 1.0.1, affecting the packages Microsoft.EntityFrameworkCore.Sqlite and Microsoft.EntityFrameworkCore.Tools.
View the Pull Request for more information and the screenshot below for details:

References

• https://docs.github.com/en/code-security/dependabot
• https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022
• https://github.com/askpt/blazzing-pizza-workshop

Samples

GitHub - askpt/blazzing-pizza-workshop: Blazor WebAssembly Workshop

This post targets the Async library. The Task library was introduced in the newer versions of F# (dotnet 6.0+). In this article, I’m going to focus only on the Asynclibrary.

Basic usage of Cancellation Tokens in F#

To illustrate how cancellation tokens are used, we can isolate two scenarios: asynchronous functions chained together where cancellation tokens are propagated through the execution chain and asynchronous functions executed independently, without further chained asynchronous calls. Let us focus on the second scenario first.
By specifying the timeout in the constructor of CancellationTokenSource, we request that the task be cancelled after 200 milliseconds. In this example, we make a simple console print to show that the task has been cancelled.
Please note that in this example, the cancellation token is not explicitly passed to the Async.Sleep function, so we don’t need to check if the token has been cancelled in the following examples.

open System.Threading

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        while (true) do
            printfn "Waiting"

            do! Async.Sleep(100)
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 59231349
Starting
Cancellation token: 59231349
Waiting
Waiting
Cancelled

Complex usage of Cancellation Tokens in F#

For this scenario, we want to show how a cancellation token is shared from the parent task to the child tasks using the Async module functions to start new tasks.
This section will describe and explain cancellation tokens in functions such as Async.StartChild or Async.Start.

Code Examples

This section will include a few code examples with selected Async functions that help us execute/start asynchronous expressions.
We are using the Async.OnCancel function to show the user that the task was properly cancelled. As stated in the previous section, we are not checking if we should cancel the tasks since it’s done by the function Async.Sleep. This happens simply because the F# runtime does that job for us and makes all the cancellations it needs, except in cases where we share the cancellation tokens with the child tasks.

do! / let! / return! / use!

This is the easiest way to start a new task in F#. In this example, the do! makes sure the Cancellation Token is shared with all child tasks. This means that when the token is cancelled, the tasks should be cancelled, as proved by the hash code printed in the output.

open System.Threading

let taskChild() : Async<unit> =
    async {
        printfn "Starting Child"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token child: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled Task Child")

        while (true) do
            printfn "Waiting Child"

            do! Async.Sleep(100)
    }

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        do! taskChild()
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 3139257
Starting
Cancellation token: 3139257
Starting Child
Cancellation token child: 3139257
Waiting Child
Waiting Child
Cancelled Task Child
Cancelled

Async.StartChild

This starts a child computation within an asynchronous workflow. This allows multiple asynchronous computations to be executed simultaneously.
In this example, the cancellation token is not shared, but internally, when a task is started as a child, the child cancellation token is linked to the parent cancellation token. That’s why we have different hash codes for the parent and child tasks, but both get cancelled.

open System.Threading

let taskChild() : Async<unit> =
    async {
        printfn "Starting Child"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token child: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled Task Child")

        while (true) do
            printfn "Waiting Child"

            do! Async.Sleep(100)
    }

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        let! completor = taskChild () |> Async.StartChild
        let! result = completor

        return result
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 52169655
Starting
Cancellation token: 52169655
Starting Child
Cancellation token child: 6634750
Waiting Child
Waiting Child
Cancelled Task Child
Cancelled

Async.Start

Starts the asynchronous computation in the thread pool. In this example, the cancellation token is not propagated to the child task since we are using the Start function to trigger the task initialization. This way of kicking off a task might be useful for work where we want a fire-and-forget behaviour since the child’s task is never cancelled.
This function also accepts a cancellation token as an argument. When a token is shared, the child task is cancelled.

open System.Threading

let taskChild() : Async<unit> =
    async {
        printfn "Starting Child"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token child: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled Task Child")

        while (true) do
            printfn "Waiting Child"

            do! Async.Sleep(100)
    }

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        Async.Start(taskChild ())

        do! Async.Sleep(1000)
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 24709875
Starting
Cancellation token: 24709875
Starting Child
Cancellation token child: 40392858
Waiting Child
Waiting Child
Cancelled
Waiting Child
Waiting Child
Waiting Child

Async.StartImmediate

Runs an asynchronous computation, starting immediately on the current operating system thread. This is similar to the Async.Startfunction we saw earlier. The same rules regarding cancellation tokens apply to this function as well.

open System.Threading

let taskChild() : Async<unit> =
    async {
        printfn "Starting Child"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token child: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled Task Child")

        while (true) do
            printfn "Waiting Child"

            do! Async.Sleep(100)
    }

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        Async.StartImmediate(taskChild ())

        do! Async.Sleep(1000)
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 59545942
Starting
Cancellation token: 59545942
Starting Child
Cancellation token child: 40392858
Waiting Child
Waiting Child
Cancelled
Waiting Child
Waiting Child
Waiting Child

Async.RunSynchronously

This function gets a task by argument and runs it synchronously. It also exposes a cancellation token passed as an argument, which will be used as the cancellation token for the child tasks.

open System.Threading

let taskChild() : Async<unit> =
    async {
        printfn "Starting Child"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token child: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled Task Child")

        while (true) do
            printfn "Waiting Child"

            do! Async.Sleep(100)
    }

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        taskChild () |> Async.RunSynchronously

        printfn "Line after RunSynchronously"
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 12025920
Starting
Cancellation token: 12025920
Starting Child
Cancellation token child: 40392858
Waiting Child
Waiting Child
Cancelled
Waiting Child
Waiting Child
Waiting Child

Working with multiple sub-tasks

Interestingly, the tasks respect the order in which they have been called to be cancelled. In this example, the Grand Child task is the first to be cancelled, whereas the first one called was the last one to be cancelled. As expected, the Grand Child 2 task is never called.
Also, please note that task 2 is never called since task 1 never finishes the execution.

open System.Threading

let taskGrandchild(order: int) : Async<unit> =
    async {
        printfn $"Starting Grandchild({order})"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token GrandChild({order}): {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn $"Cancelled Task Grandchild: {order}")

        while (true) do
            printfn $"Waiting Grandchild({order})"

            do! Async.Sleep(100)
    }

let taskChild() : Async<unit> =
    async {
        printfn "Starting Child"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token child: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled Task Child")

        while (true) do
            do! taskGrandchild(1)
            do! taskGrandchild(2)
    }

let task () : Async<unit> =
    async {
        printfn "Starting"

        let! ct = Async.CancellationToken
        printfn $"Cancellation token: {ct.GetHashCode()}"

        use! c = Async.OnCancel(fun () -> printfn "Cancelled")

        do! taskChild()
    }

let cts = new CancellationTokenSource(200)
let ct = cts.Token
printfn $"Cancellation token main: {ct.GetHashCode()}"
Async.Start(task (), cts.Token)
Async.Sleep 500 |> Async.RunSynchronously

Cancellation token main: 26465690
Starting
Cancellation token: 26465690
Starting Child
Cancellation token child: 26465690
Starting Grandchild(1)
Cancellation token GrandChild(1): 26465690
Waiting Grandchild(1)
Waiting Grandchild(1)
Cancelled Task Grandchild: 1
Cancelled Task Child
Cancelled

Comparison Table from the Code Examples

In the table below, we compare the different calls and behaviours.

Examples:
a) Compute a value asynchronously
b) Save transactions in the database
c) Send an event in an Event-Driven system
d) Create a log in the logging system
e) Retrieve or post information into an API that results from what we need later

References

• Asynchronous programming | F# for Fun and Profit
• Converting asynchronous cancellation from C# to F# | Tyson Williams
• Asynchronous Programming in F# | Packt
• Async programming in F# | Microsoft Docs
• control.fs | GitHub
• The F# Asynchronous Programming Model