Skip to content

[csharp][generichost] Add support for IHostApplicationBuilder - #24952

Merged
wing328 merged 2 commits into
OpenAPITools:masterfrom
devhl-labs:devhl/23595-add-support-for-IHostApplicationBuilder
Sep 16, 2026
Merged

wing328 merged 2 commits into
OpenAPITools:masterfrom
devhl-labs:devhl/23595-add-support-for-IHostApplicationBuilder

Conversation

@devhl-labs

@devhl-labs devhl-labs commented Sep 16, 2026 •

Copy link
Copy Markdown
Contributor

Add IHostApplicationBuilder support to the C# generichost generator

Problem

The generichost library generates DI wiring extension methods only for IHostBuilder (via ConfigureApi on the host builder) and IServiceCollection (via AddApi). Both are built around the legacy generic-host model that starts from Host.CreateDefaultBuilder(args).

Modern .NET has moved on. Since .NET 8, the recommended and template-default way to bootstrap an app is the streamlined Host.CreateApplicationBuilder() / WebApplicationBuilder model, which exposes an IHostApplicationBuilder. Microsoft's own guidance describes the older IHostBuilder approach as a legacy pattern kept for compatibility, while IHostApplicationBuilder is "recommended for new projects and is the default in current .NET templates."

Consumers on that modern hosting model had no first-class way to register the generated client. They were forced to drop down to builder.Services.AddApi(...), or hand-roll their own IHostApplicationBuilder extension method — which defeats the purpose of a generated SDK. This was raised in #23595.

Solution

The generator now emits an IHostApplicationBuilderExtensions class alongside the existing extensions, providing a ConfigureApi overload that hangs directly off IHostApplicationBuilder:

var builder = Host.CreateApplicationBuilder(args);

builder.ConfigureApi(options =>
{
    options.AddTokens(new BearerToken("<your token>"));
});

var host = builder.Build();

The new method mirrors the existing surface exactly: it constructs a HostConfiguration, invokes the caller's configuration delegate, and forwards to the same IServiceCollectionExtensions.AddApi core registration. As a result, every existing extensibility hook (OnHostConfigurationCreated, OnAddApiHttpClientBuilder, OnServicesAdded) fires identically no matter which entry point a consumer uses — there's a single registration path, just three different front doors.

The signature intentionally follows idiomatic .NET DI conventions and stays consistent with the sibling AddApi(this IServiceCollection, Action<HostConfiguration>) overload: a single configuration delegate, with the builder returned for fluent chaining. Anyone needing the raw IServiceCollection still has it directly as builder.Services.

Because Host.CreateApplicationBuilder() and the IHostApplicationBuilder interface only exist on .NET 8+, the generated class is gated behind the net80OrLater flag so older target frameworks (net6/net7) are unaffected. The README usage sample follows the same gate, showing the modern Host.CreateApplicationBuilder() pattern for net8+ projects and the existing IHostBuilder pattern otherwise — one canonical example per generated project, always matching the target framework.

Closes #23595.

PR checklist

  • Read the contribution guidelines.
  • Run the following to build the project and update samples:
    ./mvnw clean package || exit
    ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
    ./bin/utils/export_docs_generators.sh || exit
    
    (For Windows users, please run the script in WSL)
    Commit all changed files.
    This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
    These must match the expectations made by your contribution.
    You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
    IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Summary by cubic

Adds IHostApplicationBuilder support to the C# generichost generator so .NET 8+ apps using Host.CreateApplicationBuilder() can register the generated client via a new ConfigureApi extension instead of falling back to builder.Services.AddApi(...). The extension forwards to the existing IServiceCollectionExtensions.AddApi registration path, keeping extensibility hooks identical regardless of entry point, and is only emitted for net80OrLater targets. Closes #23595.

New Features

  • Emits an IHostApplicationBuilderExtensions class with a ConfigureApi overload, gated behind net80OrLater so older target frameworks are unaffected.
  • README usage samples now show Host.CreateApplicationBuilder() for net8+ targets and keep the IHostBuilder pattern for older ones.

Written for commit 6401e56. Summary will update on new commits.

Review in cubic

@cubic-dev-ai cubic-dev-ai Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 138 files

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

@wing328
wing328 merged commit 12fb7c5 into OpenAPITools:master Sep 16, 2026
58 checks passed
@devhl-labs
devhl-labs deleted the devhl/23595-add-support-for-IHostApplicationBuilder branch September 16, 2026 12:22
@wing328 wing328 added this to the 7.26.0 milestone Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[REQ] csharp generichost generator support for IHostApplicationBuilder

2 participants