-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the Worker template to use Host.CreateApplicationBuilder
#47720
Conversation
The callback approach that `Host.CreateDefaultBuilder` uses is no longer recommended going forward, and the programming model is no longer used in ASP.NET apps - it uses the `WebApplication.CreateBuilder()` API which is imperative, top-to-bottom programming. The Worker template should follow the same pattern. Fix dotnet#43113
Hi @eerhardt, I've got a burning question that's been on my mind. You know how with |
src/ProjectTemplates/Web.ProjectTemplates/content/Worker-CSharp/Program.Main.cs
Outdated
Show resolved
Hide resolved
src/ProjectTemplates/Web.ProjectTemplates/content/Worker-CSharp/Program.Main.cs
Outdated
Show resolved
Hide resolved
Can you describe more about why you want to get access to the Host property (ConfigureHostBuilder)? What is your scenario? |
I've been thinking about our host plan more an more an I think it's incomplete. One of the primary reasons we have the IHostBuilder interface is so that libraries can target APIs against something that was implemented on any IHostBuilder implementation. This means that things like orlens or serilog could target the IHostBuilder and not have to reference anything web specific, but still have that show up. We need to fix this with the new builder pattern. |
Common base interface on the builders? |
Yep. |
I found 2 more places that only had IHostBuilder extensions instead of IServiceCollection extensions and logged issues for them:
The issue that I have with the existing IHostBuilder interface is that it is all callback based. It makes supporting the imperative model difficult (see dotnet/runtime#61634 and dotnet/runtime#61635. And all the adapter code we have to try to make the 2 programming models work together). I would be OK with adding a new interface IHostApplicationBuilder
{
IConfiguration Configuration { get; } // can't be ConfigurationManager since that is in MS.Ext.Configuration and Hosting.Abstractions references Configuration.Abstractions. So need to pick between IConfiguration and IConfigurationBuilder
IHostEnvironment Environment { get; }
ILoggingBuilder Logging { get; }
IServiceCollection Services { get; }
IHost Build();
void ConfigureContainer<TContainerBuilder>(IServiceProviderFactory<TContainerBuilder>factory, Action<TContainerBuilder>? configure = null) where TContainerBuilder: notnull;
} Note that the existing |
👍🏾 This gels with what I was thinking. |
OK, I'll write up a proposal for that in dotnet/runtime next week. |
I'm going to merge this in order to get this in for preview4. I'll get that api-proposal issue logged next week in dotnet/runtime. |
The callback approach that
Host.CreateDefaultBuilder
uses is no longer recommended going forward, and the programming model is no longer used in ASP.NET apps - it uses theWebApplication.CreateBuilder()
API which is imperative, top-to-bottom programming. The Worker template should follow the same pattern.Fix #43113