Исследуем .NET 6. Часть 3. Рассматриваем код WebApplicationBuilder

Это создаёт новый экземпляр WebApplicationOptions, инициализирует аргументы Args из аргументов командной строки и передаёт объект параметров в конструктор WebApplicationBuilder (показанный кратко ниже):

public static WebApplicationBuilder CreateBuilder(string[] args) =>
new(new() { Args = args });

Кстати, новое сокращённое ключевое слово new, когда целевой тип неочевиден, — просто отстой при разборе кода. Невозможно даже предположить, что создаёт второй new() в приведённом выше коде. Во многом претензии те же самые, как и к повсеместному использованию var, но в данном случае это меня особенно раздражает.

Ну, почему прям уж так невозможно ;-): просто открываете в GitHub WebApplicationBuilder.cs и смотрите, какие там параметры у конструктора. Первый параметр имеет тип WebApplicationOptions, его публичная часть крайне проста ;-):

    public class WebApplicationOptions
    {
        public string[]? Args { get; init; }   // The command line arguments.
        public string? EnvironmentName { get; init; }       // The environment name.
        public string? ApplicationName { get; init; }          // The application name.
        public string? ContentRootPath { get; init; }        // The content root path.
        public string? WebRootPath { get; init; }        // The web root path.
       ...
  }

Вот именно этот класс и создает второй new, а сразу после этого его автоматическое свойство Args инициализуется списком параметров коммандой строки.
Правда, там ещё и парочка вложеных классов есть, с видимостью internal, но на них можно не обращать внимание.
И всего-то какие-то лишние пять минут на анализз этого куска надо потратить ;-)
PS Кстати, у конструктора WebApplicationOptions есть и второй параметр, configureDefaults, типа Action, а у статического метода WebApplication.CreateBuilder — перекрытый вариант, принимающий как параметр экземпляр WebApplicationOptions, так что можно создать такой экземпляр со своим configureDefaults, и сделать на его основе WebApplicationBuilder со своими настройками по умолчанию. Круто! ;-)

Тут, вообще-то в статье много не совсем точных заявлений, так что комментариев, подобных моему первому, написать можно ещё много.
Например

В отличие от ConfigureHostBuilder, который немедленно выполнял переданный делегат, BootstrapHostBuilder «сохраняет» переданные делегаты в список для последующего выполнения

На самом деле это не совсем точно. ConfigureHostBuilder немедленно выполняет те делегаты, которые сами занимаются тем, что всего лишь пополняют списки, на основе которых строятся части приложения: конфигурация (CofigureHostConfiguration и ConfigureAppConfiguration) и контейнер сервисов, он же — DI-контейнер (ConfigureServices). А вот, например, методы для инициализации контейнера сервисов (дефолтного или стороннего) UseServiceProviderFactory и ConfigureContainer пополняют список делегатов, который будут вызваны для экземпляра класса HostBuilder перед непосредственным построением размещаемого приложения.
Другой вопрос, интересно ли это кому-нибудь?
Судя по тому, что мои предыдущие публикации по внутренностям инициализации веб-приложения в шаблоне Generic Host особого интереса не вызвали — сильно в этом сомневаюсь, так что больше подобных комментариев по моей инициативе не будет.
Наверное, оставлю все эти сведения для своей следующей статьи, которую когда-нибудь надеюсь написать.
Но если у кого-то есть конкретные вопросы — готов рассмотреть и ответить.