feat: Deprecate AddHostedFeatureLifecycle method

[kylejuliandev]

This PR

• Copy all Dependency Injection files over to the Hosting package
• Add [Obsolete()] attribute to AddHostedFeatureLifecycle()
• Ensure that the Hosted Service is injected when you make a call to AddOpenFeature
• Add new test project with the same unit tests from the Dependency Injection tests

This is technically a breaking change because anyone using both packages in their project, which everyone will be, they will run into issues around resolving the correct extension methods.

Related Issues

Fixes #472

Notes

Follow-up Tasks

How to test

[askpt]

@toddbaert This PR is to move the deprecated method into the Hosting library. Since these DIs are still experimental, do you consider this as breaking change?
I am happy just to do a minor version bump instead of major.

[arttonoyan]

@kylejuliandev I suggest moving all files currently in the Hosting package (under the Hosting namespace) into the DependencyInjection package (also under Hosting namespace).

Why this makes sense

1. Better organization: These files are all about hosting-related setup and services. Since dependency injection is how hosting is configured in .NET, keeping them together makes it easier to understand.

2. Easier to use: When users set up OpenFeature with ASP.NET Core, they'll usually work in the DependencyInjection package. Moving everything into that package means they don't have to reference a second package - and everything shows up in one place when using IntelliSense or documentation

---

Also, in the Hosting package, we currently have FeatureLifecycleStateOptions, which were configured using AddHostedFeatureLifecycle. Since we're deprecating that, we should remember to update the docs to show that the hosted service can now be configured using the standard Microsoft configuration pattern.

For example:

services.ConfigureOptions<FeatureLifecycleStateOptions>(options =>
{
    // Optional: configure StartState, StopState, etc.
});

All of these options are optional, but this makes it easier and more consistent with typical .NET configuration.

[askpt]

@kylejuliandev I suggest moving all files currently in the Hosting package (under the Hosting namespace) into the DependencyInjection package (also under Hosting namespace).

I am more inclined to move all DI into the Hosting namespace. We have Hosting specific stuff and DI in the same package. We rarely reference the DI package, and it usually comes included in the Hosting one.

The dependency tree generally looks like:

YourApp
 └─ OpenFeature.Hosting
      └─ OpenFeature.DependencyInjection

We should keep only the DI unless we provide only DI extensions. Since we also offer application configuration, I vote to keep the Hosting and merge the DI into that one.

We might need to make changes to the configuration file since I would like to keep the same namespaces we are using now.

---

Also, in the Hosting package, we currently have FeatureLifecycleStateOptions, which were configured using AddHostedFeatureLifecycle. Since we're deprecating that, we should remember to update the docs to show that the hosted service can now be configured using the standard Microsoft configuration pattern.

For example:

services.ConfigureOptions<FeatureLifecycleStateOptions>(options =>
{
    // Optional: configure StartState, StopState, etc.
});

All of these options are optional, but this makes it easier and more consistent with typical .NET configuration.

Agreed!

[codecov]

Codecov Report

❌ Patch coverage is 95.81994% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.04%. Comparing base (76bd94b) to head (805f5f5).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...g/MultiTarget/CallerArgumentExpressionAttribute.cs	0.00%	5 Missing ⚠️
...sting/Providers/Memory/FeatureBuilderExtensions.cs	88.63%	4 Missing and 1 partial ⚠️
...penFeature.Hosting/OpenFeatureBuilderExtensions.cs	97.98%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #531      +/-   ##
==========================================
+ Coverage   89.73%   90.04%   +0.31%     
==========================================
  Files          64       77      +13     
  Lines        2523     2873     +350     
  Branches      295      323      +28     
==========================================
+ Hits         2264     2587     +323     
- Misses        199      226      +27     
  Partials       60       60              

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

@kylejuliandev the code coverage went quite down. You did a copy-paste of the current code without changes?

[kylejuliandev]

@kylejuliandev the code coverage went quite down. You did a copy-paste of the current code without changes?

Yep, pretty much a copy and paste and update of namespaces and usings. Looking at the code coverage from main: We never produced a report for OpenFeature.Hosting and the OpenFeature.DependencyInjection coverage was only about 60% - https://app.codecov.io/gh/open-feature/dotnet-sdk/tree/main/src

I was planning on adding some additional unit tests to improve the coverage - if that's ok?

[askpt]

@kylejuliandev the code coverage went quite down. You did a copy-paste of the current code without changes?

Yep, pretty much a copy and paste and update of namespaces and usings. Looking at the code coverage from main: We never produced a report for OpenFeature.Hosting and the OpenFeature.DependencyInjection coverage was only about 60% - https://app.codecov.io/gh/open-feature/dotnet-sdk/tree/main/src

I was planning on adding some additional unit tests to improve the coverage - if that's ok?

Go for it! 👍