Add Dependency Injection Support for openfeature-dotnet-server

[arttonoyan]

Is your feature request related to a problem? Please describe.
Currently, the openfeature-dotnet-server SDK does not provide a built-in package for Dependency Injection (DI) to simplify integration with .NET Core applications. While the core OpenFeature .NET SDK supports DI, LaunchDarkly-specific extensions do not yet expose a similar developer experience.
In my company, we use LaunchDarkly extensively (it’s a fantastic product), and I’ve developed an internal integration package to bridge this gap and help teams onboard quickly.

Describe the solution you'd like
I’d like to see official support for a DI-friendly package for openfeature-dotnet-server, similar to how OpenFeature itself exposes a clean, idiomatic .NET integration.
My current usage looks like this:

builder.Services.AddOpenFeature(featureBuilder =>
{
    featureBuilder
        .AddHostedFeatureLifecycle()
        .AddContext(/* context config */)
        .AddLaunchDarkly(builder.Configuration["LaunchDarkly:SdkKey"]);
});

This approach allows seamless integration of OpenFeature with LaunchDarkly in ASP.NET Core apps, following best practices around IServiceCollection.

Describe alternatives you've considered
I’ve created an internal NuGet package to add DI support for LaunchDarkly with OpenFeature, but I believe this would be more valuable as an officially supported extension. Alternatively, developers have to manually configure ILaunchDarklyClient and bind it into OpenFeature manually, which adds friction.

Additional context
I’d be happy to contribute my internal implementation as a starting point if the maintainers are open to the idea. I believe this would significantly lower the entry barrier for adopting OpenFeature with LaunchDarkly in .NET environments and could be improved step-by-step with community feedback.

[jsonbailey]

@arttonoyan, Thanks for bringing this up and for the positive feedback on the product. It sounds like you are suggesting a separate package for dependency injection support, similar to how open feature also provides a separate package. If we follow that approach to ensure we are not adding extra dependencies for those who are not using it then it should be okay. I cannot guarantee how quickly we can get it approved but we welcome you contributing your work and we can go from there.

[arttonoyan]

@jsonbailey Thank you for following up on this. Yes - I’m proposing we publish a separate package, like how the core OpenFeature approach is structured. This ensures that consumers who don’t require the LaunchDarkly provider aren’t forced to pull in unnecessary dependencies.

Also, I wanted to ask: is there any specific contribution process or template I should follow when creating this package? If you have guidelines or examples, sharing those would be extremely helpful as I progress.

I’d be happy to contribute directly and provide a draft PR to get things started.

[arttonoyan]

@jsonbailey I’ve found the CONTRIBUTING.md file in the repository - appreciate that it’s already well-documented.

I’ll go ahead and prepare a PR for the proposed package. Please feel free to close this issue if you consider it resolved or prefer to continue the discussion in the PR directly

[jsonbailey]

I will leave it open in case we are not able to resolve it with the PR you submitted. I have not had time to look at it yet but have it on my list of upcoming tasks.