feat: Extract minimal DI integration to OpenFeature.DependencyInjection.Abstractions #596

arttonoyan · 2025-10-04T22:57:05Z

This PR

Extract the minimal, provider-agnostic DI surface into a new package: OpenFeature.DependencyInjection.Abstractions.
This isolates the contracts and lightweight wiring needed to integrate any OpenFeature provider without pulling in a concrete implementation.

Related Issues

Fixes #587

Notes

Options split: Extracted provider-agnostic configuration from OpenFeatureOptions into a new base options type: OpenFeatureProviderOptions.
Inheritance: OpenFeatureOptions now inherits from OpenFeatureProviderOptions.
Internal wiring update: Internal configuration that previously targeted OpenFeatureOptions now targets OpenFeatureProviderOptions.

Before (internal)

services.AddOptions<OpenFeatureOptions>()
    .Configure(options =>
    {
        options.AddProviderName(null);
    });

After (internal)

services.AddOptions<OpenFeatureProviderOptions>()
    .Configure(options =>
    {
        options.AddProviderName(null);
    });

Note: This is an internal refactor. It does not affect consumers unless they were directly modifying OpenFeatureOptions via DI options configuration (which is not a supported/typical usage).

Impact

No new functionality.
Behavior unchanged at runtime (same provider selection, same evaluation outcomes, same logs).
Binary/source compatibility: Consumers using the documented extension methods and standard registration remain unaffected.
Potential touchpoints: Only internal code paths (or unconventional consumer code directly configuring OpenFeatureOptions) require updates to target OpenFeatureProviderOptions.

How to test

This is a regression-only refactor.

Expectations

All existing unit/integration tests pass unchanged.
No DI resolution or startup configuration differences.

Introduced a new project, `OpenFeature.DependencyInjection.Abstractions`, to the solution. This project supports dependency injection abstractions and targets multiple frameworks (`netstandard2.0`, `net8.0`, `net9.0`, `net462`) for broad compatibility. Configured the project with the `Microsoft.NET.Sdk` SDK and set the root namespace to `OpenFeature.DependencyInjection.Abstractions`. Added dependencies on `Microsoft.Extensions.DependencyInjection.Abstractions` and `Microsoft.Extensions.Options` to enable DI and options configuration.

Refactored the OpenFeature framework to introduce `OpenFeatureProviderBuilder`, enhancing support for dependency injection and provider management. - Changed namespaces to align with DI abstractions. - Made `FeatureCodes` public for broader accessibility. - Added `InternalsVisibleTo` for testing and project references. - Introduced `OpenFeatureProviderBuilder` for managing providers and policies. - Added extension methods for provider and policy registration. - Refactored `OpenFeatureBuilder` to inherit from `OpenFeatureProviderBuilder`. - Consolidated shared functionality in `OpenFeatureProviderOptions`. - Updated `FeatureBuilderExtensions` and `InMemoryProviderOptions` to use the new abstraction. - Updated tests to reflect new method signatures and hierarchy. - Removed redundant methods and properties, improving code organization. These changes improve maintainability, extensibility, and alignment with modern DI patterns.

Simplified the `AddProvider` API by removing the `TFeatureProvider` generic type parameter and directly using the `FeatureProvider` type. Updated the `TOptions` parameter to ensure it derives from `OpenFeatureProviderOptions`. Added a `<ProjectReference>` to `OpenFeature.csproj` in `OpenFeature.DependencyInjection.Abstractions.csproj`. Updated `OpenFeatureOptions` to `OpenFeatureProviderOptions` in the default name selector policy. Refactored `AddInMemoryProvider` methods to align with the new API. Updated tests in `OpenFeatureBuilderExtensionsTests` to reflect the changes and validate the updated functionality. Performed general code cleanup, including XML documentation updates, to improve clarity and maintain consistency across the codebase.

Refactored `FeatureLifecycleManager` to modularize provider, hook, and handler initialization with new methods: `InitializeProvidersAsync`, `InitializeHooks`, and `InitializeHandlers`. Updated `EnsureInitializedAsync` to use these methods for improved readability and maintainability. Revised `AddInMemoryProvider` in `FeatureBuilderExtensions` to use a generic `FeatureProvider` abstraction. Adjusted `CreateProvider` methods accordingly. Improved code clarity in `FeatureFlagIntegrationTest` by renaming variables for consistency and removing redundant assignments.

Updated FeatureLifecycleManagerTests to replace OpenFeatureOptions with OpenFeatureProviderOptions for configuring feature providers. Added support for hooks and keyed singletons to enhance modularity. Introduced additional feature flag retrieval in FeatureFlagIntegrationTest. Added dependency on OpenFeature.DependencyInjection.Abstractions.

codecov · 2025-10-04T22:59:43Z

Codecov Report

❌ Patch coverage is 96.85039% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.68%. Comparing base (29e1657) to head (f9a6781).

Files with missing lines	Patch %	Lines
...stractions/OpenFeatureProviderBuilderExtensions.cs	90.24%	0 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #596      +/-   ##
==========================================
- Coverage   89.76%   89.68%   -0.09%     
==========================================
  Files          77       80       +3     
  Lines        3166     3179      +13     
  Branches      364      369       +5     
==========================================
+ Hits         2842     2851       +9     
  Misses        253      253              
- Partials       71       75       +4

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

kylejuliandev · 2025-10-24T19:52:38Z

OpenFeature.slnx

    <Project Path="samples/AspNetCore/Samples.AspNetCore.csproj" />
  </Folder>
  <Folder Name="/src/">
+    <Project Path="src/OpenFeature.DependencyInjection.Abstractions/OpenFeature.DependencyInjection.Abstractions.csproj" Id="607a23fa-2c2f-4d2e-9079-adae18326512" />


suggestion: I'm not sure the ID property is needed here

Removed: 3d680f3

src/OpenFeature.DependencyInjection.Abstractions/OpenFeatureProviderOptions.cs

kylejuliandev · 2025-10-24T19:56:03Z

src/OpenFeature.DependencyInjection.Abstractions/Diagnostics/FeatureCodes.cs

 /// </code>
 /// </example>
-internal static class FeatureCodes
+public static class FeatureCodes


question: Do we need these FeatureCodes anymore?

@kylejuliandev Answer: Yes - within the scope of this PR, FeatureCodes are still required; the current changes reference them.
Follow-up proposal: It’s a good time to graduate them from Experimental. Not in this PR - I suggest a separate task.
@askpt @beeme1mr what do you think about me opening a follow-up issue to:

remove the Experimental attribute,

update docs/usages,

add a changelog entry and brief migration note?

I think with @kylejuliandev efforts to deprecate the OpenFeature.DependencyInjection library and this would be great candidate for 2.10. Feel free to create a new issue and add it to 2.10 milestone 👍

kylejuliandev · 2025-10-24T19:56:54Z

...Feature.DependencyInjection.Abstractions/OpenFeature.DependencyInjection.Abstractions.csproj

+
+  <PropertyGroup>
+    <TargetFrameworks>netstandard2.0;net8.0;net9.0;net462</TargetFrameworks>
+    <RootNamespace>OpenFeature.DependencyInjection.Abstractions</RootNamespace>


suggestion: Should we have these abstractions in their own namespace? Would it be more accessible to have them in say just the OpenFeature namespace?

@kylejuliandev Great question - thanks for calling it out.
I’d keep these in their own namespace for now. OpenFeature.DependencyInjection.Abstractions targets provider authors (integrating new providers), not typical app consumers. Keeping it separate avoids cluttering the root OpenFeature namespace and lets us evolve DI-specific types independently.
Of course, I’m open to discussion about this.

I prefer the @arttonoyan. This is a very specific Abstraction layer.

I am wondering if we should keep in a OpenFeature.Abstractions instead. This would be a "library" of just OpenFeature related abstractions like "hooks", "provider"... I am happy to keep OpenFeature.DependencyInjection.Abstractions if the rest of the team agrees.

src/OpenFeature.DependencyInjection.Abstractions/OpenFeatureProviderBuilder.cs

kylejuliandev · 2025-10-24T19:59:20Z

src/OpenFeature.Hosting/Internal/FeatureLifecycleManager.cs

        }
+    }

+    /// <inheritdoc />


suggestion: Not sure we need the inheritdoc section here

Suggested change

/// <inheritdoc />

kylejuliandev · 2025-10-24T20:02:45Z

test/OpenFeature.Hosting.Tests/Internal/FeatureLifecycleManagerTests.cs

        var services = new ServiceCollection();
        var provider = new NoOpFeatureProvider();
-        services.AddOptions<OpenFeatureOptions>().Configure(options =>
+        services.AddOptions<OpenFeatureProviderOptions>().Configure(options =>


suggestion: it should be fine for this to remain OpenFeatureOptions right? OpenFeatureOptions extends OpenFeatureProviderOptions

kylejuliandev · 2025-10-24T20:03:09Z

src/OpenFeature.Hosting/OpenFeatureServiceCollectionExtensions.cs

                options.DefaultNameSelector = provider =>
                {
-                    var options = provider.GetRequiredService<IOptions<OpenFeatureOptions>>().Value;
+                    var options = provider.GetRequiredService<IOptions<OpenFeatureProviderOptions>>().Value;


suggestion: it should be fine for this to remain OpenFeatureOptions right? OpenFeatureOptions extends OpenFeatureProviderOptions

kylejuliandev · 2025-10-24T20:07:46Z

src/OpenFeature.Hosting/OpenFeatureOptions.cs

-        }
-    }
-
    private readonly HashSet<string> _hookNames = [];


thought: I wonder if we can simplify the Hook registration. If instead of relying on HookNames we just inject Hooks like services.AddTransient<Hook>(myHook). And when we retrieve these hooks out to register them in the provider we just read it back out like var hooks = _serviceProvider.GetServices<Hook>();

Would eliminate the need to track hook names in this options file

This seems a great suggestion. My concern is if we register two different instance Hooks of the same type. What should happen? Should we allow this behaviour?

I went ahead over the weekend and gave it a stab in #609. Seems simple enough. I think if we register two hooks of the same type, then we should still handle them both. Maybe let's take this conversation over there. Happy to close this here as it's not really relevant to the changes

…hub.com/arttonoyan/dotnet-sdk into feature/di-abstractions-builder-api-587

askpt

Great work! I only added a couple of minor comments.

Please have a chat with @kylejuliandev to try understand the impact on his deprecations efforts. I remember he mentioned a couple of fixes he was working on for the DI and I don't want that effort to get lost during this PR.

askpt · 2025-10-27T14:55:36Z

...Feature.DependencyInjection.Abstractions/OpenFeature.DependencyInjection.Abstractions.csproj

This file misses the README file necessary for the package documentation.

src/OpenFeature.DependencyInjection.Abstractions/OpenFeatureProviderBuilderExtensions.cs

askpt · 2025-10-27T14:57:28Z

src/OpenFeature.Hosting/Internal/FeatureLifecycleManager.cs

+        InitializeHandlers();
+    }
+
+    /// <inheritdoc />


It is private method, so this is not needed.

Suggested change

/// <inheritdoc />

askpt · 2025-10-27T14:57:39Z

src/OpenFeature.Hosting/Internal/FeatureLifecycleManager.cs

        }
+    }

+    /// <inheritdoc />


Suggested change

/// <inheritdoc />

askpt · 2025-10-27T14:57:59Z

src/OpenFeature.Hosting/Internal/FeatureLifecycleManager.cs

+    }
+
+    /// <inheritdoc />
+    private async Task InitializeProvidersAsync(CancellationToken cancellationToken)


cancellationToken seems to not be used here.

askpt · 2025-10-27T14:59:25Z

src/OpenFeature.Hosting/Providers/Memory/FeatureBuilderExtensions.cs

+using OpenFeature.DependencyInjection.Abstractions;
 using OpenFeature.Providers.Memory;

 namespace OpenFeature.Hosting.Providers.Memory;


I wonder if we should move to OpenFeature.Providers.Memory

askpt · 2025-10-27T15:02:25Z

src/OpenFeature.Hosting/OpenFeatureOptions.cs

-        }
-    }
-
    private readonly HashSet<string> _hookNames = [];


This seems a great suggestion. My concern is if we register two different instance Hooks of the same type. What should happen? Should we allow this behaviour?

arttonoyan added 5 commits September 29, 2025 21:41

Merge branch 'main' into feature/di-abstractions-builder-api-587

dbdb9b5

arttonoyan self-assigned this Oct 5, 2025

arttonoyan marked this pull request as ready for review October 7, 2025 07:47

arttonoyan requested a review from a team as a code owner October 7, 2025 07:47

arttonoyan mentioned this pull request Oct 7, 2025

feat: Add initial dependency injection support for LaunchDarkly provider launchdarkly/openfeature-dotnet-server#49

Open

4 tasks

arttonoyan added 2 commits October 9, 2025 21:13

Merge branch 'main' into feature/di-abstractions-builder-api-587

acade51

Merge branch 'main' into feature/di-abstractions-builder-api-587

10203f3

arttonoyan requested review from askpt and kylejuliandev October 23, 2025 20:03

kylejuliandev reviewed Oct 24, 2025

View reviewed changes

src/OpenFeature.DependencyInjection.Abstractions/OpenFeatureProviderOptions.cs Show resolved Hide resolved

kylejuliandev reviewed Oct 24, 2025

View reviewed changes

src/OpenFeature.DependencyInjection.Abstractions/OpenFeatureProviderBuilder.cs Show resolved Hide resolved

kylejuliandev reviewed Oct 24, 2025

View reviewed changes

arttonoyan added 2 commits October 27, 2025 09:08

Removev ID property

3d680f3

Merge branch 'feature/di-abstractions-builder-api-587' of https://git…

f9a6781

…hub.com/arttonoyan/dotnet-sdk into feature/di-abstractions-builder-api-587

askpt reviewed Oct 27, 2025

View reviewed changes

Uh oh!

feat: Extract minimal DI integration to OpenFeature.DependencyInjection.Abstractions #596

Are you sure you want to change the base?

feat: Extract minimal DI integration to OpenFeature.DependencyInjection.Abstractions #596

Conversation

arttonoyan commented Oct 4, 2025

This PR

Related Issues

Notes

Before (internal)

After (internal)

Impact

How to test

Uh oh!

codecov bot commented Oct 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

askpt Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

askpt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov bot commented Oct 4, 2025 •

edited

Loading

askpt Oct 27, 2025 •

edited

Loading