Replace WebHostBuilder with HostBuilder pattern in MVC folder

[Copilot]

Summary

This PR replaces all usages of WebHostBuilder with the modern HostBuilder and ConfigureWebHost pattern across the MVC folder, updating 24 files to follow current ASP.NET Core hosting best practices.

Part of #20964

Changes Made

Pattern Transformation:

// Before
var host = new WebHostBuilder()
    .UseContentRoot(Directory.GetCurrentDirectory())
    .UseStartup<Startup>()
    .UseKestrel()
    .Build();

// After  
using var host = new HostBuilder()
    .ConfigureWebHost(webHostBuilder =>
    {
        webHostBuilder
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseStartup<Startup>()
            .UseKestrel();
    })
    .Build();

Files Updated (24 total):

• Samples (1): MvcSandbox/Startup.cs
• Performance Benchmarks (3): BasicApi, BasicViews, RazorRendering
• Test Website Program.cs (7): BasicWebSite, CorsWebSite, FormatterWebSite, RazorPagesWebSite, RazorWebSite, RoutingWebSite, SecurityWebSite, VersioningWebSite
• Test Website Startup.cs (13): SimpleWebSite, FilesWebSite, ApiExplorerWebSite, ApplicationModelWebSite, ControllersFromServicesWebSite, ErrorPageMiddlewareWebSite, TagHelpersWebSite, XmlFormattersWebSite, HtmlGenerationWebSite (2 files), RazorBuildWebSite (2 files)

Key Changes Applied

✅ Added using statements: using Microsoft.Extensions.Hosting;
✅ Updated variable declarations: var host → using var host
✅ Renamed methods: CreateWebHostBuilder() → CreateHost()
✅ Changed return types: IWebHostBuilder → IHostBuilder
✅ Wrapped configuration: new WebHostBuilder() → new HostBuilder().ConfigureWebHost(...)
✅ Preserved all configurations: All original .UseKestrel(), .UseStartup<>(), .UseConfiguration(), .UseStaticWebAssets(), etc. methods maintained

Testing

• All transformations follow the exact pattern specified in the requirements
• Original functionality preserved - all configuration calls moved inside ConfigureWebHost lambda
• Special configurations like .UseStaticWebAssets() in TagHelpersWebSite correctly handled
• Complex configurations with local variables (like ConfigurationBuilder) properly maintained

Verification

• ✅ 0 remaining new WebHostBuilder() usages in MVC folder
• ✅ 24 files successfully transformed with new HostBuilder() pattern
• ✅ All files compile with proper using statements and method signatures

This pull request was created as a result of the following prompt from Copilot chat.

Remove all usages of WebHostBuilder in the MVC folder and replace them with HostBuilder and ConfigureWebHost. Specifically, for each occurrence of:

Before:
var host = new WebHostBuilder()
.Configure(app => {
//...
})
.Build();

Change to:
using var host = new HostBuilder()
.ConfigureWebHost(webHostBuilder => {
webHostBuilder
.Configure(app => {
//...
});
})
.Build();

Ensure all usages in the MVC folder follow this new pattern, updating variable declarations and method chains as needed.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[BrennanConroy]

Because the Startup type is the same as the one in the test fixture, we end up running both startups which both register a file provider and ends up messing with the cache-ability of razor views.

So removing this fixes the 2 quarantined tests below, and I'll mark #56553 as test-fixed.

We also might want to consider changing GenericWebHostBuilder to detect the same startup type so it doesn't run it multiple times?

[captainsafia]

Nice find! Handling this in GenericWebHostBuilder sounds like a good idea.

[BrennanConroy]

Fixed in latest commit.

[BrennanConroy]

We can remove this and consider it later if we want, as it introduces a new API.

[captainsafia]

I'm inclined to keep it even though introducing a new API in an obsoletion pass feels funky since we don't expose any other nice ways for users to customize TestServer with a finalized DI container and we've gotten feedback in the past about how hard it is to plugin WAF APIs into different points in the minimal host's lifecycle (mostly before and after IHostBuilder.Build, but still).

[BrennanConroy]

Maybe this should be LastOrDefault?

[BrennanConroy]

Bug introduced by #24144 that allowed multiple startups to run if they spanned different IWebHostBuilder instances. See test MultipleConfigureWebHostCallsWithUseStartupLastWins below for example.

[davidfowl]

Crazy

[captainsafia]

Is there a reason for this change?

[BrennanConroy]

Oh right, forgot about this one.

So the two hosts handle ordering differently.

var host = new WebHostBuilder()
    .UseStartup<Startup>()
    .ConfigureServices(services =>
    {
        services.TryAddSingleton<Bar>(new Bar() { Value = 10 });
    })
    .Build();

var host2 = new HostBuilder()
    .ConfigureWebHost(webhostbuilder =>
        webhostbuilder
            .UseKestrel()
            .UseStartup<Startup>()
    )
    .ConfigureWebHost(webhostbuilder =>
    {
        webhostbuilder.ConfigureServices(services =>
        {
            services.TryAddSingleton<Bar>(new Bar() { Value = 10 });
        });
    }).Build();

Console.WriteLine(host.Services.GetRequiredService<Bar>().Value);
Console.WriteLine(host2.Services.GetRequiredService<Bar>().Value);

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
    }

    public void ConfigureServices(IServiceCollection services)
    {
        services.TryAddSingleton<Bar>(new Bar() { Value = 30 });
    }
}

public class  Bar
{
    public int Value { get; set; }
}

This prints:

10
30

It's too late to change eithers order, but HostBuilder does feel a bit more natural since it does things more in order of how the code is ordered.