Implementing Feature Management in .NET: The Lazy Way

Microsoft did the hard work so you don't have to.

The Microsoft.FeatureManagement library integrates directly with .NET's configuration and dependency injection systems, which means you can get feature flags working with minimal code and a solid foundation. For the full documentation, check out the Microsoft Feature Management documentation.

Let's get this thing running.

Installation

Add the NuGet package to your project:

dotnet add package Microsoft.FeatureManagement.AspNetCore

That's it for dependencies. No magic rituals required.

Configuration

Register the feature management services in Program.cs:

builder.Services.AddFeatureManagement();

By default, feature flags are read from the FeatureManagement section of your appsettings.json:

{
  "FeatureManagement": {
    "NewDashboard": true,
    "ExperimentalSearch": false
  }
}

Flag names are strings. Values are booleans. Simple.

Checking a Flag in Code

Inject IFeatureManager wherever you need to check a flag:

public class DashboardController : Controller
{
    private readonly IFeatureManager _featureManager;

    public DashboardController(IFeatureManager featureManager)
    {
        _featureManager = featureManager;
    }

    public async Task<IActionResult> Index()
    {
        if (await _featureManager.IsEnabledAsync("NewDashboard"))
        {
            return View("NewDashboard");
        }

        return View("OldDashboard");
    }
}

That's the whole pattern. Inject. Check. Branch. Repeat.

Using Feature Filters

Boolean flags are useful, but sometimes you need something a little more sophisticated. The library supports feature filters for things like:

• Percentage rollouts
• Time windows
• User targeting

For example, you can enable a feature for a percentage of requests:

{
  "FeatureManagement": {
    "BetaFeature": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 20
          }
        }
      ]
    }
  }
}

This enables BetaFeature for 20% of requests. The library handles the sampling. You handle the business logic. Everybody wins.

Razor Tag Helpers

Building a Razor-based UI? The library includes a tag helper for conditionally rendering markup:

<feature name="NewDashboard">
    <div class="new-dashboard">...</div>
</feature>

Clean, readable, and no C# in your markup. Some people consider this progress.

The Lazy Way Is Often the Right Way

Rolling your own feature flag system is a rite of passage. It's also probably not a good use of your time. Microsoft's library already handles the plumbing:

• Configuration
• Dependency injection
• Feature filters
• Percentage rollouts
• Razor tag helpers

So you can focus on the actual feature instead of spending three days building a flag system that was supposed to take an afternoon.

But there's one problem with the appsettings.json approach:

Someone still has to edit the config file when you want to flip a flag.

And if that means changing configuration, committing it, deploying it, and waiting for the pipeline just to turn off a broken feature...

You've basically recreated the problem feature flags were supposed to solve.

A dedicated feature flag management UI lets you change flags without touching your configuration files or redeploying your application.

That's where FeatureFlags.app comes in.

Why reinvent the wheel when someone already built the wheel factory?

Be lazy. Ship more.