[FEATURE] Minimal OpenFeature.Providers.DependencyInjection with Builder API (Hosting retains DI registrations)

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

Requirements

Context
OpenFeature.DependencyInjection was deprecated in favor of OpenFeature.Hosting, which now includes DI-related functionality. This simplifies app integration, but provider packages (e.g., LaunchDarkly) often need only a very small surface to integrate—without pulling in broader hosting concepts (hosted lifecycles, health checks, config binding, etc.).
This idea came to me after integrating launchdarkly/openfeature-dotnet-server DI, specifically after this question (launchdarkly/openfeature-dotnet-server#49 (comment)). In that integration I used only an OpenFeatureBuilder and AddProvider methods with their overloads.

Problem
Provider libraries that just need to plug a provider into OpenFeature end up depending on OpenFeature.Hosting, which can feel heavy and increase the transitive dependency surface for scenarios that don’t use hosting features.

Proposal
Introduce a thin DI-friendly package, OpenFeature.DependencyInjection.Abstractions, that exposes a small builder abstraction (e.g., OpenFeatureBuilder) for provider composition—methods like AddProvider(...), AddHook(...), and minimal configuration hooks.
Crucially, all DI registrations remain in OpenFeature.Hosting, which creates/owns the builder and applies configuration, lifecycle, health checks, and other hosting features. Providers would reference the abstractions package only, extending the builder without taking a hard dependency on hosting.

Benefits

• Separation of concerns: App authors get the full Hosting experience; provider authors get a tiny, stable surface to integrate.
• Smaller dependency footprint: Provider packages avoid bringing in hosting infrastructure they don’t use.
• Broader compatibility: Clean support for libraries, tests, console tools, and worker services where hosting may be unnecessary.
• Future-proofing: Hosting features (Aspire/telemetry/lifecycle) can evolve independently, while the builder surface remains small and stable.

Trade-offs / Considerations

• Another package to version and document.
• Clear guidance needed to avoid confusion about when to use Hosting vs. the abstractions.
• Keep the abstractions narrowly scoped to avoid duplicating Hosting responsibilities.

Back-compat / Migration

• Keep OpenFeature.DependencyInjection deprecated; optionally publish a final patch that forwards types where feasible and points to the new package.

• Provide a short migration guide:

  • App developers: use OpenFeature.Hosting.
  • Provider authors: target OpenFeature.DependencyInjection.Abstractions and extend the builder.

• Observability, lifecycle, and config binding remain in Hosting.

Questions for the community

1. Is there agreement that a DI-only builder abstraction (with Hosting retaining DI registrations) would help provider authors?
2. Any concerns about maintenance or user confusion that outweigh the benefits?
3. Naming preference: OpenFeature.DependencyInjection.Abstractions (my preferred option), or an alternative?
4. Which minimal builder methods are essential, and which should remain strictly in Hosting?
5. If there’s consensus, I can help draft an RFC and a small PoC to validate the split.

Related context
This proposal arose while updating a provider PR where the Hosting dependency felt heavier than necessary for provider-level integration. The builder-only approach allowed the provider to integrate cleanly without consuming Hosting features.

[beeme1mr]

I agree with this approach. As mentioned in Slack, we should also consider exposing other abstractions for providers and hooks but that can likely be handled separately.

[arttonoyan]

@beeme1mr @askpt Thanks for the quick reply and the support - I’ll take ownership and implement this shortly. I agree with the proposed approach.