Microsoft.FeatureManagement turns flags into a .NET dependency, not a config read

The problem: a flag is more than a boolean

Microsoft.FeatureManagement provides standardized APIs for enabling feature flags within applications, and the library's own framing of the use case is worth quoting because it sets the scope: use it to secure a consistent experience when developing applications that use patterns such as beta access, rollout, dark deployments and more.

Those four patterns are the point. A flag that is simply a boolean in a configuration file handles none of them well. Beta access is a flag plus a rule about who the user is. A rollout is a flag plus a percentage. A dark deployment is a flag that turns on a new code path for staff before anyone else sees it. Each of those is a decision with conditions attached, and each of those conditions has to be evaluated somewhere.

Left to a team, that somewhere is usually a pile of if statements scattered across controllers, services and background jobs, each reading a configuration value and each with its own idea of what a missing value means. The library's contribution is to make the decision a single call and to give the conditions a defined form, so that a flag is evaluated the same way everywhere it is checked.

The description says the library provides a way to define these relationships and also integrates into common .NET code patterns to make exposing these features possible. The second half matters as much as the first. A feature flag library that is not wired into dependency injection, so that every caller has to know how to reach the evaluator, ends up being bypassed within a month. This one is designed to be resolved the same way as any other service in a .NET application.

Two packages are published on NuGet, Microsoft.FeatureManagement for the core library and Microsoft.FeatureManagement.AspNetCore for the web integration, and both carry version badges in the readme.

The examples are the real documentation

The readme links its documentation elsewhere, to Microsoft Learn for the quickstart, the feature reference and the API reference, and to the Azure App Configuration repository for the release notes. What it lists in full is the examples, and there are nine of them, which makes them the most complete map of the library's surface available.

There is a plain .NET Console App, and a ParametersObjectConsoleApp, which is the console example with a parameters object, presumably the pattern for a configuration object rather than a flat settings bag. There is a TargetingConsoleApp, which is the example of the targeting rules that make beta access and percentage rollouts work. The web examples are an ASP.NET Core app with Razor Pages and an ASP.NET Core MVC app, the latter named FeatureFlagDemo, and a Blazor Server app.

The three most recent and most specific examples are the interesting ones, because they are the parts of the library that are hard to guess at. There is a VariantAndTelemetryDemo, an app with variants and telemetry, a VariantServiceDemo with a variant service, and an OpenTelemetryDemo with variants and OpenTelemetry.

Variants are the feature management idea where a flag is not just on or off but selects a value, which is how a flag becomes a way to change a layout, a price or a copy variant without a code deploy. A variant service is a mechanism for resolving those variants, and having a demo dedicated to it tells you that variants are a first class part of the model rather than a sugar coating on booleans.

So the picture the examples give is of a library with three layers: a simple enable or disable check, targeting rules layered on top, and variants with their own resolution mechanism and observability. A team evaluating it should read the targeting and the variant examples before reading anything else, because those are the parts that decide whether the library can express the flags you actually have.

The OpenTelemetry integration and the ordering it demands

The most detailed section in the readme is about OpenTelemetry, and the detail is about registration order, which is unusual to see documented so explicitly.

Microsoft.FeatureManagement.Telemetry.OpenTelemetry provides feature-evaluation event publishing and targeting enrichment for spans and logs. The setup is two calls. You register feature management with services.AddFeatureManagement(), and then you call AddFeatureManagementProcessors() on the builder returned by services.AddOpenTelemetry(). The integration automatically attaches its targeting processors, and applications configure their own providers and exporters.

The ordering rules are then stated with a precision that suggests they were learned the hard way. Register the integration before exporters, including exporters configured separately through logging APIs. An exporter integration with an explicit exporter-last guarantee may be registered in either order. And the library does not reorder existing OpenTelemetry registrations.

That last sentence is the important one. The library refuses to rearrange your container registrations, which is the right behaviour for a library that does not own your service provider, but it means a mis-ordered registration fails quietly. If the feature management processors are registered after an exporter that has already claimed the pipeline, the targeting enrichment is not attached, and the symptom is missing fields in traces rather than an error. In a system where the whole point of the integration is to see which flag was active for a given request, that is a failure you would rather discover in a test than in production.

The readme points at the OpenTelemetry sample for a complete setup, and the sample is in the examples directory of the repository, so the ordering can be copied rather than reasoned about.

Building the solution and the contribution rules

The repository is a full .NET solution with the usual Microsoft layout, and the scripts show how it is worked on.

The root holds Microsoft.FeatureManagement.sln along with a companion .sln.licenseheader file, a Directory.Build.props for shared build properties, a NuGet.Config for package sources, an .editorconfig, a SECURITY.md, and three PowerShell scripts: build.ps1, pack.ps1 and test.ps1. There are src/ and tests/ directories, a build/ directory, a scripts/ directory, and a schemas/ directory, which in a project like this is where the configuration schema for a feature flag lives, the document that describes the fields a flag definition can carry.

The examples are in the examples/ directory, with the nine applications the readme lists, and the test project directory is separate from them, so the examples are not part of the test run but are maintained as part of the repository.

The contribution rules are explicit. Most contributions require you to agree to a Contributor License Agreement declaring that you have the right to, and actually do, grant the rights to use your contribution, at cla.microsoft.com. When you submit a pull request, a bot determines whether you need to provide a CLA and decorates the pull request accordingly, and the readme notes that you only need to do this once across all the repositories using that CLA.

The project has also adopted the Microsoft Open Source Code of Conduct, with links to the frequently asked questions page and a contact address for questions about it.

For a library published by a large vendor, this is the part of the repository an adopter usually never looks at, and it is worth looking at: the CLA means the contribution terms are not the same as the MIT licence that consumers get, which is normal and not a problem, but it is a different arrangement and the readme is upfront about it.

Where the version history and the documentation actually live

The readme is a signpost, and following the links is necessary to use this properly.

The quickstart is on Microsoft Learn and is specifically about integrating feature flags from Azure App Configuration into.NET applications, which tells you the intended source of flag data. The feature reference is the document that provides a full feature rundown, and that is where the semantics of a condition, a targeting rule, a percentage rollout and a variant are defined. The API reference details the API surface of the libraries in the repository, which is the reference for the calls themselves.

The release notes are somewhere else entirely. The readme points at the release notes for all versions of the feature management libraries in the Azure/AppConfiguration repository, on GitHub, at a file named for Microsoft.Featuremanagement. The version history is kept with the Azure App Configuration repository rather than here. The practical consequence is that the tag list in this repository is not the whole picture, and the changelog you want is in the other repository.

The maintenance picture from what is here is healthy. The licence is MIT, with the LICENSE file in the repository root, and the recent releases are 4.6.0 on 2026-07-01, 4.7.0 on 2026-09-01 and 4.8.0 on 2026-09-24, so a minor release roughly every one to two months. The last push was on 2026-10-14 and the repository is not archived.

One thing the readme does not say, and that an adopter should establish, is what happens when the flag provider is unavailable. A feature flag library that fails closed when its configuration source cannot be reached will take down the application that depends on it, and the readme does not state a default. The feature reference and the API reference are the place to look for that, along with the caching and refresh behaviour of the provider.

Editorial conclusion

The library suits a .NET team that has outgrown scattered boolean checks and wants a single way to express a flag with its targeting rules, and it suits an application that already runs OpenTelemetry and wants feature decisions to appear in traces. It is the wrong choice for a single service with two or three flags, since the configuration and the evaluation model cost more to adopt than a conditional saves, and a poor match if your flags come from somewhere the library does not read. Before adopting, read the feature reference for the evaluation semantics you need, register the OpenTelemetry integration before your exporters as the documentation requires, and check the release notes in the Azure App Configuration repository, which is where the version history lives.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/FeatureManagement-Dotnet on GitHub
4. README
5. Releases