feat: Extract minimal DI integration to OpenFeature.Providers.DependencyInjection

[arttonoyan]

Important

Update. 2025-11-10
Following the discussion in #596 (comment). the package name in this proposal is updated from OpenFeature.DependencyInjection to OpenFeature.Providers.DependencyInjection. Rationale. clearer scope for provider authors. thinner provider packages. reduced coupling with the SDK.

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.

[codecov]

Codecov Report

❌ Patch coverage is 94.84536% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.33%. Comparing base (218ed82) to head (05f4da8).

Files with missing lines	Patch %	Lines
...yInjection/OpenFeatureProviderBuilderExtensions.cs	90.24%	0 Missing and 4 partials ⚠️
...eature.Hosting/Internal/FeatureLifecycleManager.cs	93.75%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #596      +/-   ##
==========================================
+ Coverage   93.21%   93.33%   +0.11%     
==========================================
  Files          69       71       +2     
  Lines        2994     2985       -9     
  Branches      359      358       -1     
==========================================
- Hits         2791     2786       -5     
+ Misses        143      136       -7     
- Partials       60       63       +3     

☔ 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.

[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]

@askpt @kylejuliandev I’ve made all the requested changes. I only left out the README.md. If that’s OK, I’ll handle it in a separate ticket. Please review again.

Quick question: Should I apply the same changes to the DI package, or skip it because it’s obsolete? Need Help: I can’t figure out the dotnet format / check-format job error. Could you help with this?

@arttonoyan just execute dotnet format OpenFeature.slnx at the root of the repository to clear the error. You also have a DCO failure.

[arttonoyan]

@askpt @kylejuliandev Could you please do a final review? I’d like to merge this PR.

[askpt]

@arttonoyan Please update this action: https://github.com/open-feature/dotnet-sdk/blob/main/.github/workflows/release.yml. This package needs to be added to generate the security artefacts.

[arttonoyan]

@arttonoyan Please update this action: https://github.com/open-feature/dotnet-sdk/blob/main/.github/workflows/release.yml. This package needs to be added to generate the security artefacts.

done: 579ac49

[arttonoyan]

@askpt @kylejuliandev I ran into a blocking issue. I tried to avoid any major changes, but it looks like I can’t solve it without doing at least some refactoring.
If you can help with a decision, that would be great.

The problem

While working on the OpenFeature.Providers.DependencyInjection package, I hit an issue with this configuration:

builder.Services.AddOpenFeature(of => of
    .AddProvider(_ => new TestProvider())
    .AddHook(_ => new TestHook())
);

This fails because:

• AddProvider is an extension for OpenFeatureProviderBuilder
• AddHook is an extension for OpenFeatureBuilder
• AddProvider returns OpenFeatureProviderBuilder, which does not have AddHook, so the second call is not available and we get a compile-time error.

If I reverse the order, it works:

builder.Services.AddOpenFeature(of => of
    .AddHook(_ => new TestHook())
    .AddProvider(_ => new TestProvider())
);

Here AddHook returns OpenFeatureBuilder, which inherits from OpenFeatureProviderBuilder, so both methods are available and everything compiles.

For me this is a design problem, because the API becomes order-dependent and confusing. I tried to make OpenFeatureProviderBuilder generic, but that didn’t really solve it.

I see two options. I’m open to other ideas as well.

---

Option 1. Move OpenFeatureBuilder into OpenFeature.Providers.DependencyInjection and remove OpenFeatureProviderBuilder

We would keep all extensions targeting OpenFeatureBuilder.

• Pros. Simple. fast to implement.
• Cons. All extensions would depend on the OpenFeature.Providers.DependencyInjection package, even when they are not really about providers or DI (for example, hooks).

---

Option 2. Create OpenFeature.DependencyInjection.Abstractions package

We create a new package. OpenFeature.DependencyInjection.Abstractions, move all general DI-related types there, and remove OpenFeatureProviderBuilder. All extensions would be built on top of OpenFeatureBuilder.

• Pros. Cleaner separation. All DI logic depends on a lightweight abstractions package. In the future, if we want to split hooks or other concerns into separate packages, it will be easier.
• Cons. One more package to maintain. This new package will probably contain most of the logic from the old OpenFeature.DependencyInjection package.

I slightly prefer Option 2, even though it introduces an extra package, because it gives us a cleaner and more future-proof structure.
cc: @beeme1mr @toddbaert @lukas-reining @thomaspoignant @kinyoklion

[askpt]

@askpt @kylejuliandev I ran into a blocking issue. I tried to avoid any major changes, but it looks like I can’t solve it without doing at least some refactoring. If you can help with a decision, that would be great.

The problem

While working on the OpenFeature.Providers.DependencyInjection package, I hit an issue with this configuration:

builder.Services.AddOpenFeature(of => of
    .AddProvider(_ => new TestProvider())
    .AddHook(_ => new TestHook())
);

This fails because:

• AddProvider is an extension for OpenFeatureProviderBuilder
• AddHook is an extension for OpenFeatureBuilder
• AddProvider returns OpenFeatureProviderBuilder, which does not have AddHook, so the second call is not available and we get a compile-time error.

If I reverse the order, it works:

builder.Services.AddOpenFeature(of => of
    .AddHook(_ => new TestHook())
    .AddProvider(_ => new TestProvider())
);

Here AddHook returns OpenFeatureBuilder, which inherits from OpenFeatureProviderBuilder, so both methods are available and everything compiles.

For me this is a design problem, because the API becomes order-dependent and confusing. I tried to make OpenFeatureProviderBuilder generic, but that didn’t really solve it.

I see two options. I’m open to other ideas as well.

Option 1. Move OpenFeatureBuilder into OpenFeature.Providers.DependencyInjection and remove OpenFeatureProviderBuilder

We would keep all extensions targeting OpenFeatureBuilder.

• Pros. Simple. fast to implement.
• Cons. All extensions would depend on the OpenFeature.Providers.DependencyInjection package, even when they are not really about providers or DI (for example, hooks).

Option 2. Create OpenFeature.DependencyInjection.Abstractions package

We create a new package. OpenFeature.DependencyInjection.Abstractions, move all general DI-related types there, and remove OpenFeatureProviderBuilder. All extensions would be built on top of OpenFeatureBuilder.

• Pros. Cleaner separation. All DI logic depends on a lightweight abstractions package. In the future, if we want to split hooks or other concerns into separate packages, it will be easier.
• Cons. One more package to maintain. This new package will probably contain most of the logic from the old OpenFeature.DependencyInjection package.

I slightly prefer Option 2, even though it introduces an extra package, because it gives us a cleaner and more future-proof structure. cc: @beeme1mr @toddbaert @lukas-reining @thomaspoignant @kinyoklion

Need to have a thought. If this requires another package moving/creation/deprecation we might as well do a v3 like I mentioned in Slack.

I kinda prefer Option B also, but moving the code all the time doesn't bring the necessary stability, even if this is still in Experimental phase.

I would like to know what will be the consequences for the providers and hooks if we go ahead with option B. Which package should it consume? OpenFeature.Providers.Abstractions and OpenFeature.DependencyInjection.Abstractions?

Then the consumers would just install OpenFeature, OpenFeature.Hosting and OpenFeature.Providers.ProviderA?

To finish, I would believe if we go with option B, we would need to do a v3, make the DI not-experimental and this PR will be part of v3.

[arttonoyan]

@askpt @kylejuliandev I ran into a blocking issue. I tried to avoid any major changes, but it looks like I can’t solve it without doing at least some refactoring. If you can help with a decision, that would be great.
The problem
While working on the OpenFeature.Providers.DependencyInjection package, I hit an issue with this configuration:

builder.Services.AddOpenFeature(of => of
    .AddProvider(_ => new TestProvider())
    .AddHook(_ => new TestHook())
);

This fails because:

• AddProvider is an extension for OpenFeatureProviderBuilder
• AddHook is an extension for OpenFeatureBuilder
• AddProvider returns OpenFeatureProviderBuilder, which does not have AddHook, so the second call is not available and we get a compile-time error.

If I reverse the order, it works:

builder.Services.AddOpenFeature(of => of
    .AddHook(_ => new TestHook())
    .AddProvider(_ => new TestProvider())
);

Here AddHook returns OpenFeatureBuilder, which inherits from OpenFeatureProviderBuilder, so both methods are available and everything compiles.
For me this is a design problem, because the API becomes order-dependent and confusing. I tried to make OpenFeatureProviderBuilder generic, but that didn’t really solve it.
I see two options. I’m open to other ideas as well.

Option 1. Move OpenFeatureBuilder into OpenFeature.Providers.DependencyInjection and remove OpenFeatureProviderBuilder

We would keep all extensions targeting OpenFeatureBuilder.

• Pros. Simple. fast to implement.
• Cons. All extensions would depend on the OpenFeature.Providers.DependencyInjection package, even when they are not really about providers or DI (for example, hooks).

Option 2. Create OpenFeature.DependencyInjection.Abstractions package

We create a new package. OpenFeature.DependencyInjection.Abstractions, move all general DI-related types there, and remove OpenFeatureProviderBuilder. All extensions would be built on top of OpenFeatureBuilder.

• Pros. Cleaner separation. All DI logic depends on a lightweight abstractions package. In the future, if we want to split hooks or other concerns into separate packages, it will be easier.
• Cons. One more package to maintain. This new package will probably contain most of the logic from the old OpenFeature.DependencyInjection package.

I slightly prefer Option 2, even though it introduces an extra package, because it gives us a cleaner and more future-proof structure. cc: @beeme1mr @toddbaert @lukas-reining @thomaspoignant @kinyoklion

Need to have a thought. If this requires another package moving/creation/deprecation we might as well do a v3 like I mentioned in Slack.

I kinda prefer Option B also, but moving the code all the time doesn't bring the necessary stability, even if this is still in Experimental phase.

I would like to know what will be the consequences for the providers and hooks if we go ahead with option B. Which package should it consume? OpenFeature.Providers.Abstractions and OpenFeature.DependencyInjection.Abstractions?

Then the consumers would just install OpenFeature, OpenFeature.Hosting and OpenFeature.Providers.ProviderA?

To finish, I would believe if we go with option B, we would need to do a v3, make the DI not-experimental and this PR will be part of v3.

Here is an updated version you can paste into the PR with the extra Cons included.

---

@askpt there is also an Option C that lets us continue without any breaking changes.
I tried it locally and it is working.

Option C. Make OpenFeatureProviderBuilder generic internally while keeping the public API stable

We introduce an internal generic version of the builder OpenFeatureProviderBuilder<TBuilder> but keep the existing public OpenFeatureProviderBuilder class as is.
The public API does not change. so this is not a breaking change.

Public type (unchanged).

public class OpenFeatureProviderBuilder
    : OpenFeatureProviderBuilder<OpenFeatureProviderBuilder>
{
    public OpenFeatureProviderBuilder(IServiceCollection services)
        : base(services) { }
}

Internal generic base.

internal abstract class OpenFeatureProviderBuilder<TBuilder>
    where TBuilder : OpenFeatureProviderBuilder<TBuilder>
{
    protected IServiceCollection Services { get; }

    protected OpenFeatureProviderBuilder(IServiceCollection services)
    {
        Services = services;
    }

    protected TBuilder This => (TBuilder)this;
}

OpenFeatureBuilder uses the same base.

public sealed class OpenFeatureBuilder
    : OpenFeatureProviderBuilder<OpenFeatureBuilder>
{
    public OpenFeatureBuilder(IServiceCollection services)
        : base(services) { }
}

Extensions target the generic base and return TBuilder.

public static class OpenFeatureBuilderExtensions
{
    public static TBuilder AddProvider<TBuilder>(
        this OpenFeatureProviderBuilder<TBuilder> builder,
        Func<IServiceProvider, IFeatureProvider> factory)
        where TBuilder : OpenFeatureProviderBuilder<TBuilder>
    {
        // registration logic
        return (TBuilder)builder;
    }
}

Outcome

• Fluent API is order independent. both AddProvider and AddHook can be called in any order.
• No breaking changes for consumers. they still see the same OpenFeatureProviderBuilder and OpenFeatureBuilder types.
• From the caller side the API is the same. the type system just preserves the correct builder type under the hood.

Pros

• Fixes the chaining issue without changing the external API.
• Works for both OpenFeatureProviderBuilder and OpenFeatureBuilder uniformly.
• Gives us a cleaner foundation if we add more builders in the future.

Cons

• Slightly more complex generic constraints for contributors to understand. especially around TBuilder and where TBuilder : OpenFeatureProviderBuilder<TBuilder>.
• Providers and other extension authors now work with a more complex builder type.
• We must clearly highlight in the docs that extension methods must return TBuilder to avoid breaking the fluent API. if an extension accidentally returns the base type instead of TBuilder, chaining can degrade.

[askpt]

@arttonoyan This PR has several compilation errors. I will have a look when they get fixed. Which option will you think you will implement for the extraction? If there are any necessary breaking changes please rename the title to feat!: Extract...

[arttonoyan]

@arttonoyan This PR has several compilation errors. I will have a look when they get fixed. Which option will you think you will implement for the extraction? If there are any necessary breaking changes please rename the title to feat!: Extract...

@askpt As we discussed earlier, there is a breaking change related to OpenFeatureBuilder, so I decided not to fix and merge this PR as is.

Instead, I’ve started working on the next step. extracting OpenFeature.DependencyInjection.Abstractions. I created a new branch from this one, and once it’s ready, I’ll open a new PR based on it.

This should properly address the breaking change and also make future work easier. It will let us extract things like handlers and hooks into separate projects without causing more breaking changes.

I’ll open the PR soon.

[arttonoyan]

I have a follow-up PR arttonoyan#4 that builds on top of this one.

Because PR arttonoyan#4 is based on the branch in my fork (arttonoyan:feature/di-abstractions-builder-api-587), I can’t open it directly against open-feature/dotnet-sdk until this PR is merged (GitHub requires the PR base branch to exist in the target repo).

What it adds (high level):

• Introduces OpenFeature.DependencyInjection.Abstractions and moves the builder/component primitives there
• Updates Hosting + provider DI wiring to use the new split and build-time aggregation

At this stage I’m mainly looking for architecture feedback (layering, component approach, package boundaries), not a full nit-level review yet.
If the community agrees the direction is good, I’ll merge PR arttonoyan#4 into the base branch in my fork, polish it (tests + README/docs), and then open the upstream PR once this PR lands so the code review can continue normally on the SDK side.
@beeme1mr @askpt @kylejuliandev