fix(208): dotnet dependency injection issue

[tomflenner]

This PR

Fixes the dependency injection issue in the generated .NET code where IFeatureClient could not be resolved from the DI container.

• Updates the code generator to register FeatureClient with its interface type IFeatureClient
• Changes the service registration from .AddSingleton(provider => ...) to .AddSingleton<IFeatureClient, FeatureClient>(provider => ...)
• Ensures proper type resolution when GeneratedClient requests IFeatureClient in its constructor
• Updated test to use the extension method instead of manual register

Related Issues

Fixes #208

Notes

The fix is minimal and only affects the generated DI registration code. The change follows .NET best practices by registering services against their interface types rather than concrete implementations, which allows the DI container to properly resolve IFeatureClient when constructing GeneratedClient.

How to test

1. Generate .NET code using the CLI with a feature flag configuration
2. Verify that the generated AddOpenFeature extension method includes the interface type in the registration:

   .AddSingleton<IFeatureClient, FeatureClient>(provider => provider.GetRequiredService<Api>().GetClient())

3. Add the generated code to a .NET project and register it in the DI container:

   services.AddOpenFeature();

4. Verify that the application starts without throwing System.InvalidOperationException
5. Verify that GeneratedClient can be resolved and injected successfully
6. Alternatively, clone the reproduction repo at https://github.com/tomflenner/openfeature-cli-dotnet-issue-208 and test with the updated generator that no more exception occurs

[gemini-code-assist]

Summary of Changes

Hello @tomflenner, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a dependency injection problem within the generated .NET SDK, specifically addressing the inability to resolve IFeatureClient from the DI container. The changes ensure that the generated AddOpenFeature extension method correctly registers FeatureClient against its IFeatureClient interface, aligning with standard .NET dependency injection patterns and preventing runtime exceptions related to service resolution.

Highlights

• Dependency Injection Fix: Corrects a critical issue in generated .NET code where IFeatureClient could not be resolved from the dependency injection container.
• Service Registration Update: Changes the AddSingleton service registration from a concrete type to an interface-to-implementation mapping (.AddSingleton<IFeatureClient, FeatureClient>(...)).
• Improved Type Resolution: Ensures that GeneratedClient can properly resolve IFeatureClient in its constructor, adhering to .NET best practices.
• Test Refinement: Updates the integration tests to utilize the new AddOpenFeature() extension method for DI setup, simplifying test code.

Changelog

• internal/cmd/testdata/success_csharp.golden
  • Updated the C# test data to reflect the correct IFeatureClient registration.
• internal/generators/csharp/csharp.tmpl
  • Modified the C# code generation template to register IFeatureClient with FeatureClient.
• test/csharp-integration/OpenFeature.g.cs
  • Applied the updated IFeatureClient registration in the generated integration test file.
• test/csharp-integration/Program.cs
  • Simplified the integration test's DI setup by replacing manual service registrations with a call to services.AddOpenFeature().
• test/csharp-integration/expected/OpenFeature.cs
  • Updated the expected output for the AddOpenFeature extension method to include interface-based registration.
• test/csharp-integration/expected/OpenFeature.g.cs
  • Updated the expected generated file for the AddOpenFeature extension method to include interface-based registration.

Activity

• The pull request was created by tomflenner to fix a .NET dependency injection issue (Fixes fix: dotnet generated code dependency injection issue #208).
• The author provided a detailed description outlining the problem, the solution, related issues, notes on the fix, and comprehensive testing instructions, including a reproduction repository.
• No further review comments or activity have been recorded in the provided context.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively resolves the dependency injection issue in the generated .NET code by explicitly registering IFeatureClient with its concrete implementation FeatureClient. The changes in the csharp.tmpl correctly propagate to the generated files, and the integration test Program.cs has been updated to use the new AddOpenFeature() extension method, which is a good practice. The fix aligns with .NET best practices for DI and improves the robustness of the generated code.

[kriscoleman]

lgtm, thanks for finding this and fixing it!

[erka]

Please, don't use fix(208): as PR title... the changelog looks weird with it. Either change it to a proper scope or don’t use it (scope) at all.

A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
https://www.conventionalcommits.org/en/v1.0.0/#specification

OpenFeature CLI reality,

@kriscoleman

[tomflenner]

Thanks for the reminder @erka.

It looks like I can't edit the PR title myself, if someone can change the scope from (issue number) to (generator) please 🙏🏻.