feat: Add Dependency Injection and Hosting support for OpenFeature

[arttonoyan]

Note

This initial version of OpenFeature.DependencyInjection and OpenFeature.Hosting introduces basic provider management and lifecycle support for .NET Dependency Injection environments. While I haven't included extensive tests, particularly for the Hosting project, if this approach is approved and the scope is considered sufficient for the first DI and Hosting release, I will expand the test coverage to include both unit and integration tests. Additionally, I'll provide a sample application to demonstrate the usage.

This pull request introduces key features and improvements to the OpenFeature project, focusing on Dependency Injection and Hosting support:

• OpenFeature.DependencyInjection Project:

  • Implemented OpenFeatureBuilder, including OpenFeatureBuilderExtensions for seamless integration.
  • Added IFeatureLifecycleManager interface and its implementation.
  • Introduced AddProvider extension method for easy provider configuration.
  • Created OpenFeatureServiceCollectionExtensions for service registration.

• OpenFeature.Hosting Project:

  • Added HostedFeatureLifecycleService to manage the lifecycle of feature providers in hosted environments.

• Testing Enhancements:

  • Created unit tests for critical methods, including OpenFeatureBuilderExtensionsTests and OpenFeatureServiceCollectionExtensionsTests.
  • Replicated and tested NoOpFeatureProvider implementation for better test coverage.

These changes significantly improve OpenFeature's extensibility and lifecycle management for feature providers within Dependency Injection (DI) and hosted environments.

---

NuGet Packages for installation:

dotnet add package OpenFeature
dotnet add package OpenFeature.DependencyInjection
dotnet add package OpenFeature.Hosting

---

Usage Example:

builder.Services.AddOpenFeature(featureBuilder => {
    featureBuilder
        .AddHostedFeatureLifecycle() // From Hosting package
        .AddContext((context, serviceProvider) => {
            // Context settings are applied here. Each feature flag evaluation will
            // automatically have access to these context parameters.
            // Do something with the service provider.
            context
                .Set("kind", "tenant")
                .Set("key", "<some key>");
        })
        // Example of a feature provider configuration
        // .AddLaunchDarkly(builder.Configuration["LaunchDarkly:SdkKey"], cfg => cfg.StartWaitTime(TimeSpan.FromSeconds(10))); 
});

[askpt]

Hey @arttonoyan! The build is failing because of compliance. Could you please follow these steps? https://github.com/open-feature/dotnet-sdk/pull/310/checks?check_run_id=31479940982

[toddbaert]

@arttonoyan I've approved arttonoyan#1 (review) with some minor comments, but I also want to make sure before we release that we mark everything in the new DI namespace as experimental.

[toddbaert]

@arttonoyan regartding this comment, the main reason I wanted the DI namespace is because I really wanted to make it clear what is subject to change, and what is not, and putting those things in the DI namespace helped with that. However, if we add the Experimental decorator to all these new DI classes, that's good enough for me; I just want to make sure people know those features are experimental and subject to potential change going forward.

[askpt]

I am adding a couple of suggestions about the namespace.

[askpt]

Suggested change

	namespace OpenFeature;
	namespace OpenFeature.DependencyInjection;

[askpt]

Suggested change

	namespace OpenFeature;
	namespace OpenFeature.DependencyInjection;

[askpt]

Suggested change

	namespace OpenFeature;
	namespace OpenFeature.Hosting;

[arttonoyan]

Thanks, @askpt, for the suggestion. Let me explain why I prefer not to change these namespaces:

Grouping OpenFeatureServiceCollectionExtensions and OpenFeatureBuilderExtensions under a single namespace (OpenFeature) across projects makes it easier for consumers to configure the OpenFeature package using just one namespace: OpenFeature. Otherwise, they would need to add multiple using statements in their Program.cs file, such as:

using OpenFeature.Hosting;
using OpenFeature.DependencyInjection;

As the project grows, this list could expand, increasing complexity. Keeping everything under one namespace simplifies configuration and improves the developer experience by reducing clutter and creating a cohesive setup process.

Additionally, this approach supports a clear, consistent API structure, making it easier to manage and recall namespaces.
However, if aligning namespaces with project names is a priority, I’m open to revisiting this.

[askpt]

Thanks, @askpt, for the suggestion. Let me explain why I prefer not to change these namespaces:

Grouping OpenFeatureServiceCollectionExtensions and OpenFeatureBuilderExtensions under a single namespace (OpenFeature) across projects makes it easier for consumers to configure the OpenFeature package using just one namespace: OpenFeature. Otherwise, they would need to add multiple using statements in their Program.cs file, such as:

using OpenFeature.Hosting;
using OpenFeature.DependencyInjection;

As the project grows, this list could expand, increasing complexity. Keeping everything under one namespace simplifies configuration and improves the developer experience by reducing clutter and creating a cohesive setup process.

Additionally, this approach supports a clear, consistent API structure, making it easier to manage and recall namespaces. However, if aligning namespaces with project names is a priority, I’m open to revisiting this.

I understand your point, but from a user who is consuming the "packages", it would be weird to be named "OpenFeature". I suggest changing the "package" name or grouping both into "OpenFeature.DependencyInjection" so it won't be confusing.

Imagine you are a new user using the OpenFeature.OpenFeatureServiceCollectionExtensions. If you have an issue, where would you search for information? The OpenFeature package or OpenFeature.Hosting?

Thank you so much for your work and input. If you need any help with the Experimental attribute, let me know and I can try help you with that 👍

[arttonoyan]

Thanks, @askpt, for the suggestion. Let me explain why I prefer not to change these namespaces:
Grouping OpenFeatureServiceCollectionExtensions and OpenFeatureBuilderExtensions under a single namespace (OpenFeature) across projects makes it easier for consumers to configure the OpenFeature package using just one namespace: OpenFeature. Otherwise, they would need to add multiple using statements in their Program.cs file, such as:

using OpenFeature.Hosting;
using OpenFeature.DependencyInjection;

As the project grows, this list could expand, increasing complexity. Keeping everything under one namespace simplifies configuration and improves the developer experience by reducing clutter and creating a cohesive setup process.
Additionally, this approach supports a clear, consistent API structure, making it easier to manage and recall namespaces. However, if aligning namespaces with project names is a priority, I’m open to revisiting this.

I understand your point, but from a user who is consuming the "packages", it would be weird to be named "OpenFeature". I suggest changing the "package" name or grouping both into "OpenFeature.DependencyInjection" so it won't be confusing.

Imagine you are a new user using the OpenFeature.OpenFeatureServiceCollectionExtensions. If you have an issue, where would you search for information? The OpenFeature package or OpenFeature.Hosting?

Thank you so much for your work and input. If you need any help with the Experimental attribute, let me know and I can try help you with that 👍

I understand your perspective, and you’re right that intuitive package naming is important for new users. The approach I’m suggesting is actually similar to how Microsoft organizes core libraries - grouping related APIs in a way that prioritizes logical grouping over a strict alignment with package names. This doesn’t tend to complicate usage, as Visual Studio (or other IDEs) makes it easy to navigate by pressing F12 to go directly to code definitions, where the library and assembly information are clearly visible.

However, I also recognize the importance of clarity for new users. If you feel strongly that renaming or grouping under OpenFeature.DependencyInjection will better align expectations, I’ll change.

And @askpt, if you’re able to lend a hand with this as well, that would be great!

[toddbaert]

@askpt to clarify, the intent was not to release a separate nuget artifact for these changes (we don't even have the publishing mechanisms in this repo to support that); the idea was just to add new functionality marked as experimental using the [Experimental] attribute to the current SDK. I hope that clarifies some of your namespace concerns.

@arttonoyan You should be able to annotate all the new classes or functions (basically anything a user would touch) like this:

#if !NET462
        [System.Diagnostics.CodeAnalysis.Experimental(Constants.NewDiFeatures)]
#endif

Where Constants.NewDiFeatures is a common string we use to identify all our experimental new DI stuff. Users can then disable the associated warning by ignoring this error for that diagnostic ID (meaning they won't get any warnings for using these new features)

Note that this attribute doesn't exist in .NET framework (462) so you need to add the prepreoceessor directive (#if !NET462) to disable it there; those users won't get the warning but .NET 462 users are probably a minority these days. Please also use the fully qualified attribute name (System.Diagnostics.CodeAnalysis.Experimental) as well (IMO that's a good habit for imports that are used conditionally).

[arttonoyan]

@askpt to clarify, the intent was not to release a separate nuget artifact for these changes (we don't even have the publishing mechanisms in this repo to support that); the idea was just to add new functionality marked as experimental using the [Experimental] attribute to the current SDK. I hope that clarifies some of your namespace concerns.

@arttonoyan You should be able to annotate all the new classes or functions (basically anything a user would touch) like this:

#if !NET462
        [System.Diagnostics.CodeAnalysis.Experimental(Constants.NewDiFeatures)]
#endif

Where Constants.NewDiFeatures is a common string we use to identify all our experimental new DI stuff. Users can then disable the associated warning by ignoring this error for that diagnostic ID (meaning they won't get any warnings for using these new features)

Note that this attribute doesn't exist in .NET framework (462) so you need to add the prepreoceessor directive (#if !NET462) to disable it there; those users won't get the warning but .NET 462 users are probably a minority these days. Please also use the fully qualified attribute name (System.Diagnostics.CodeAnalysis.Experimental) as well (IMO that's a good habit for imports that are used conditionally).

Thanks, @toddbaert! I’m working on it, though it’s impacting quite a few classes. Another approach could be to build pre-release packages and mark the package itself as experimental, which aligns with NuGet's recommendations for experimental features: Pre-release Packages.

To make it clear for users, we could set the version <Version>1.0.0-experimental</Version>, marking it as pre-release on NuGet. Additionally, we could update the NuGet metadata to indicate the experimental status, for example:

<PackageReleaseNotes>This is an experimental version. Features may change without notice.</PackageReleaseNotes>
<Description>Experimental package for testing new features. Not recommended for production use.</Description>

This would help users recognize the package as experimental and avoid unintended use in production. What do you think?

[arttonoyan]

@askpt to clarify, the intent was not to release a separate nuget artifact for these changes (we don't even have the publishing mechanisms in this repo to support that); the idea was just to add new functionality marked as experimental using the [Experimental] attribute to the current SDK. I hope that clarifies some of your namespace concerns.
@arttonoyan You should be able to annotate all the new classes or functions (basically anything a user would touch) like this:

#if !NET462
        [System.Diagnostics.CodeAnalysis.Experimental(Constants.NewDiFeatures)]
#endif

Where Constants.NewDiFeatures is a common string we use to identify all our experimental new DI stuff. Users can then disable the associated warning by ignoring this error for that diagnostic ID (meaning they won't get any warnings for using these new features)
Note that this attribute doesn't exist in .NET framework (462) so you need to add the prepreoceessor directive (#if !NET462) to disable it there; those users won't get the warning but .NET 462 users are probably a minority these days. Please also use the fully qualified attribute name (System.Diagnostics.CodeAnalysis.Experimental) as well (IMO that's a good habit for imports that are used conditionally).

Thanks, @toddbaert! I’m working on it, though it’s impacting quite a few classes. Another approach could be to build pre-release packages and mark the package itself as experimental, which aligns with NuGet's recommendations for experimental features: Pre-release Packages.

To make it clear for users, we could set the version <Version>1.0.0-experimental</Version>, marking it as pre-release on NuGet. Additionally, we could update the NuGet metadata to indicate the experimental status, for example:

<PackageReleaseNotes>This is an experimental version. Features may change without notice.</PackageReleaseNotes>
<Description>Experimental package for testing new features. Not recommended for production use.</Description>

This would help users recognize the package as experimental and avoid unintended use in production. What do you think?

@toddbaert I've created a new PR to add the Experimental attribute conditionally for .NET 8 and above, specifically for new DI features.

Key Points:

• The attribute is applied conditionally using #if NET8_0_OR_GREATER, so it only works for .NET 8 and greater.
• For .NET Framework 4.6.2 (or other frameworks that don’t match this condition), the attribute will not be applied. The conditional check #if !NET462 does not function as intended for targeting non-.NET 8 frameworks in this scenario.

I’ve created this change in a separate branch, as I think marking the package as experimental is more convenient, as mentioned above. However, the PR is open, and I'm open to feedback – please feel free to decide if this is the best approach for this package.
arttonoyan#2

[toddbaert]

@arttonoyan The problem is we dont want to mark the entire SDK as experimental, and these features will be included in all subsequent releases, so I don't think an experimental version number can help, unless we want to merge these features to a non-main branch and maintain that along side the main branch (I'm not in favor of this for the maintenance burden it creates).

If you can add PackageReleaseNotes to the new .csproj files, that's fine, but I would say "Features may change without notice" and avoid not recommending for production. I think we want to consider this features "production grade"; just changable. I also think that perhaps we should add the Experimental attibute to any of the DI-related classes just in the OpenFeature namespace, since it might not be clear they are coming from the experimental packages... we can avoid it for classes/artifacts in the new experimentally-marked packages/namespaces... does that make sense?