Skip to content

feat: scaffold OpenFeature (+ Microsoft.FeatureManagement provider) feature-flag support #262

Description

@devantler

🤖 Generated by the Daily AI Assistant

Part of devantler-tech/monorepo#2059 (feature-flag-first delivery portfolio-wide).

Problem

The .NET template ships no feature-flag scaffolding, so projects generated from it start without a way to land new features behind a flag.

Proposed direction

Scaffold the portable OpenFeature .NET SDK as the call-site API (matching the Go stack across the portfolio), with Microsoft.FeatureManagement as the provider via the official bridge — so generated apps keep MS FeatureManagement's IConfiguration/filter/variant machinery while call sites stay OpenFeature-portable:

  • OpenFeature (v2.14.0, GA) as the app-facing API (IFeatureClient).
  • Microsoft.FeatureManagement (4.5.0; v4 → IVariantFeatureManager) behind it via OpenFeature.Contrib.Provider.FeatureManagement (0.6.1), reading a FeatureManagement config section.
  • One example flag (default-off) gating a sample code path + tests asserting both states; a short README/AGENTS.md ## Maintenance note on the convention + flag lifecycle (remove release flags after rollout).

Rough size

M — add the packages + a minimal wired example + both-state tests to the template.

References

OpenFeature .NET https://openfeature.dev/docs/reference/sdks/server/dotnet/ · bridge https://www.nuget.org/packages/openfeature.contrib.provider.featuremanagement · MS FeatureManagement https://learn.microsoft.com/en-us/azure/azure-app-configuration/feature-management-dotnet-reference

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions