О классах Program и Startup — инициализация ASP.NET приложения. Часть II: IWebHostBuilder и Startup

2. Конфигурирование веб-приложения выполняется одним из методов расширения для интерфейса построителя IHostBuilder: ConfigureWebHost(базовый) или ConfigureWebHostDefaults(дополнительно устанавливает настройки по умолчанию).

3. Конфигурирование выполняется внутри передаваемого в один из этих методов делегата, принимающего параметр построителя веб-приложения типа IWebHostBuilder - того же самого типа, который используется для конфигурирвания в шаблоне Web Host. Это позволяет использовать для конфигурирования в шаблоне Generic Host те же методы, что и в шаблоне Web Host. Этот делегат выполняется синхронно в рамках выполнения используемого метода расширения.

4. Для завершения конфигурирования веб-приложения и запуска его на выполнение указанные выше методы регистрируют для помещения в контейнер сервисов внутренний класс GenericWebHostedService в качестве реализации сервиса (интерфейса) IHostedService. Благодаря этому, в соответствии с общей логикой работы Generic Host, при запуске приложения будет произведен асинхонный вызов метода StartAsync указанного класса.

5. Для реализации интерфейса IWebHostBuilder создается объект построителя веб-приложения класса GenericWebHostBuilder (внутреннего), который реализует все методы указанного интерфейса, кроме метода Build.

6. Конструктор класса GenericWebHostBuilder инициализует внутреннюю конфигурацию построителя веб-приложения и помещает в очереди построителя три делегата - по одному для этапов создания конфигурации построителя, окончательной конфигурации приложения и конфигурирования списка регистрации серверов. Эти делегаты вополняют следующие функции: добавление внутренней конфигурации построителя веб-приложения в конфигурацию построителя (первый делегат), обеспечение работы механизма конфигурирования на основе стартовых сборок (все три делегата) и добавление в список регистрации сервисов ряда описателей сервисов, необходимых для работы веб-приложения (третий делегат).

7. Класс GenericWebHostBuilder реализует методы интерфейса построителя веб-приложения IWebHostBuilder двумя способами. Методы GetSetting и UseSetting работают с внутренней конфигурацией класса (объектом, реализующим IConfiguration), которая впоследствие добавляется в конфигурацию построителя на этапе ее создания. Методы ConfigureAppConfiguration и ConfigureServices, которые принимают делегаты, производящие конфигурирование, соответственно, конфигурации приложения и списка регистрации сервисов для создания контейнера сервисов, помещают в соответствующие очереди построителя (IHostBuilder) переданные им делегаты, с добавлением кода, который производит необходимое преобразование параметров.

8. В связи с сильным различием в логике создания контейнера сервисов и запуска приложения между старым шаблоном Web Host и новым Generic Host, была изменена реализация ряда методов расширения для интерфейса построителя веб-приложения IWebHostBuilder. Эти методы проверяют, реализует ли класс, реализующий IWebHostBuilder, также дополнительные интерфейсы (в статье они названы интерфейсами перенаправления). Если интерфейс перенаправления реализован (что свидетельствует об использовании шаблона Generic Host), то метод расширения вызывает соответствующий (на практике - одноименный) метод интерфейса перенаправления, а не использует логику, предназначенную для шаблона Web Host. В частности, именно так устроен широко используемый метод указания Startup-класса UseStartup: он вызывает одноименный метод класса GenericWebHostBuilder. Этот метод помещает в очередь этапа конфигурирования списка регистраций сервисов построителя (IHostBuilder) делегат, вызывающий внутренний метод класса GenericWebHostBuilder с тем же именем UseStartup (но с другими параметрами).

9. Внутренний метод UseStartup класса GenericWebHostBuilder создает делегаты для вызова методов Startup-класса с именами, соответствующими соглашению о вызове этих методов. Всего этих методов может быть от одного до трех: с базовыми именами ConfigureServices, ConfigureContainer (необязательные) и Configure (обязательный). Этот метод выполняется на этапе конфигурирования списка регистраций сервисов. Делегат для вызова метода ConfigureServices (если он есть) Startup-класса вызывается напрямую, делегат для вызова ConfigureContainer(если таковой есть) помещается в очередь построителя (IHostBuilder) для вызова на этапе конфигурирования контейнера-построителя, а делегат для вызова метода Configure передается в код, осуществляющий запуск веб-приложения через механизм параметров (Options).

10. Конструктор Startup-класса может использовать внедрение зависимостей только из весьма усеченного суррогатного контейнера сервисов (в этом положение в шаблоне Generic Host отличается от такового в Web Host), но при вызове метода Configure в него в качестве параметров могут передаваться любые сервисы из полноценного контейнера сервисов.

11. Построение конвейера Middleware производится на стадии запуска веб-приложения. Сначала в конвейер добавляются обработчики, которые создаются сервисами типа IStartupFilter, зарегистрированными в контейнере сервисов (в порядке, обратном порядку их добавления в список регистрации сервисов), а в конце, после них всех - обработчики, добавляемые методом Configure Startup-класса

Пока я продирался сквозь код инициализации веб-приложения ASP.NET Core, через его многочисленные вложенные лямбда-функции, мне постоянно лез стишок про дом, который построил Джек, но немного переиначенный, повернутый в будущее, примерно так: "Вот пес без хвоста, который будет гонять и трепать кота, который будет пугать птицу синицу, которая часто будет воровать пшеницу, которая будет в темном чулане храниться, в доме, который построит Джек". Потому что этот код часто выглядит так: поместить в некую очередь, которая будет выполнена на стадии построения, делегат, который что-то сделает и поместит в другую, выполняемую после этой, очередь другой делегат, который тоже сделает что-то другое и поместит в третью, выполняемую этой, очередь ещё один делегат...

Такое решение имеет очевидные достоинства совместимости: оно не только позволяет сравнительно легко переделывать разработанные на ASP.NET Web-приложения со старого шаблона Web Host на новый - Generic Host, но и дает возможность повторного использования в шаблоне Generic Host кода методов конфигурирования, разработанных для шаблона Web Host, и, в частности - поддерживать оба эти шаблона в рамках одного фреймворка. И, как и у всего на свете, у этого решения есть обратная сторона: использование делегата для конфигурирования, что усложняет чтение и понимание кода. Причем, если при конфигурировании IHost использование делегатов часто было необходимостью, обусловленной выбранной архитектурой - эти делегаты планировались для отложенного выполнения - то в данном случае такой прямой необходимости нет: переданный в указанные методы делегат вызывается только внутри них и завершается до их завершения. И особенно мне не нравится выбранное разработчиками ASP.NET решение представить делегат в виде лямбда-функции: это, хоть и выглядит стильно, модно,моложежно но плохо практически для всех вариантов использования. Потому что, если все конфигурирование специфических для веб-приложения компонентов производится внутри Startup-класса, то такая, переусложненная форма указания Startup-класса сильно избыточна: я бы для этого случая предпочел бы, вместо ConfigureWebHostDefaults, метод расширения для IHost с одним дополнительны параметром - типом Startup-класса, так как все равно реальную работу выполняет внутренний метод, получающий управление через цепочку вызовов, именно с такой сигнатурой. А если для конфигурирования специфичных для веб-приложения компонентов вызывается некоторое количество методов IWebHostBuilder, то лямбда-функция быстро становится слишком сложной для восприятия. Я бы для такого случая добавил бы в класс Program отдельный метод с параметром IWebHostBuilder, и перенес бы весь этот код туда, чтобы не загромождать код фигурными скобками и непонятно где кончающимися вложенными друг в друга лямбда-функциями. И в качестве параметра в ConfigureWebHost/ConfigureWebHostDefaults передал бы просто имя этого метода. Однако нужна нам эта совместимость или нет и как написать шаблон - нас не спросили: нам просто дали шаблон приложения ASP.NET Core, где уже сделано именно так. Поэтому используем. Или - не используем.

Как уже говорилось в первой части, рисунки-схемы не являются формализованными диаграммами, а служат только для иллюстрации. Поэтому объекты на них изображены с некоторой степнью вольности, без строгой формализации. Особенно - в данной части: обозреваемый в ней код является слишком объемным, и в одну схему не вмещается. Но, тем не менее, специфичческий смысл у разных форм графических элементов присутствует. Прямоугольные элементы со сплошниыми границами обозначают блоки кода - как реализации методов классов, так и делегаты. Прямоугольныики со скругленными границами обозначают объекты. Штриховые прямоугольники со скругленными углами - новое по сравнению с первой частью обозначение - выделяют отдельные интерфейсы у класса, реализующего несколько интерфейсов. Элементы с штриховыми границами (кроме прямоугольников со скругленными углами)- элементы данных: свойства объектов и данные, передаваемые методам. Маленькие кружки на выносных линиях обозначают методы и свойства интерфейсов и классов. Сплошные линии со стрелками - направления, в которых идет выполнение кода. Штриховые линии со стрелками - передача данных в методы/свойства (а передаваемые в методы в качестве данных делегаты обозначены прямоугольниками в штриховых кругах). Штрих-пунктирные линии с пустотелыми стрелками на конце обозначают создание экземпляров объектов.

Установка значений по умолчанию производится статическим методом ConfigureWebDefaults класса Microsoft.AspNetCore.WebHost. Этот метод - универсальный, он используется и для шаблона Generic Host, и для шаблона Web Host. Для установки значений по умолчанию в него передается в качестве аргумента ссылка на построитель веб-приложения IWebHostBuilder. Организация выполнения ConfigureWebDefaults делается способом, дающим понять, что разработчики знают про функциональное программирование: в ConfigureWebHost передается в качестве аргумента делегат, который сначала выполняет ConfigureWebHost, а затем - делегат, переданный в ConfigureWebDefaults. В ФП такое называется, в принципе, композицией, ну а в C#, куда удобные примитивы для операциями над функциями не завезли, приходится это выполнять своими силами. Впрочем, объединяемые делегаты на функции тоже не сильно похожи: они ничего не возвращают, а меняют переданный им по ссылке параметр. Иммутабельность? Не слышали.

В описании выше знатоки теории могли бы углядеть пример применения шаблона проектирования "адаптер", который является общепринятым методом построения костылей. Но вообще-то GenericWebHostBuilder далеко не ограничивается трансляцией вызовов IWebHostBuilder в вызовы IHostBuilder (все это подробно рассмотрено ниже). Так что, в целом, GenericWebHostBuilder и ряд связанных с ним интерфейсов и классов можно смело назвать шедевром костылестроения от разработчиков .NET Core, позволившим впихнуть без существенных жертв старую логику построения веб-приложения на шаблоне Web Host в рамки нового шаблона Generic Host - в том числе и там, где логика работы приложений на этих шаблонах существенно отличается. Я считаю, что работу подобных хорошо реализованных костылей стоит изучать разработчикам - чтобы использовать примененные там приемы при написании своих костылей. Насколько я заметил, теоретики от программирования не очень охотно занимаются анализом того, как надо писать костыли - им больше по душе придумывать и раздавать советы о том, как все делать правильно сразу (ну или переделывать с нуля - это называется умным заграничным словом рефакторинг) - как писать "чистый код", каким принципам следовать при построении архитектуры приложения, какие шаблоны использовать при проектировании... Эти темы и рассматривать проще, и для создания шумихи (AKA hype) и получения известности, позволяющей так или иначе заработать деньги, они лучше подходят. А существующие приложения, которые надо модифицировать, вообще часто рассматриваются (особенно, молодежью, которая выучила эту самую теорию, но пока не знает жизни) как "легаси", на которое не стоит тратить свои ум, силы и время. В то же время реальные программисты костыли в своих приложениях вынуждены делать регулярно, так что хорошее знакомство с удачными методами проектирования и построения костылей, а так же - близко связанными методами модификации архитектуры могло бы существенно облегчить их реальную работу. Однако, насколько мне известно (но я мог что-то упустить, да), книг и статей по описаниям лучших практик костылестроения - паттернам проектирования костылей, методам локальной модификации архитектуры приложения и т.п. - просто нет, и изучать данную тему приходится по таким вот источникам, как исходный код .NET Core Но вернемся к классу GenericWebHostBuilder.

Создание конфигурации делается обычным образом: создается экземпляр класса ConfigurationBuilder (реализующий интерфейс IConfigurationBuilder), в него добавляется источник конфигурации на основе переменных среды с указанным префиксом, а затем вызывается метод Build этого интерфейса.

Делается это способом, аналогичным добавлению конфигурации построителя в число источников для конфигурации приложения, описанным ранее: в список источников конфигурации добавляется источник класса ChainedConfigurationSource, содержащий ссылку на объект конфигурации внутренней конфигурации построителя веб-приложения.

Если лямбда-функции, которые являются первыми двумя делегатами, сложны лишь весьма ограниченно - содержат всего по две строки с вызовами методов и легко помещаются на одном экране - то третий делегат являет собой неплохой образец написания сложного кода современными методами ;-) : он содержит целых 56 строк (правда, среди них - немало комментариев, строк с одиночными фигурными скобками и даже просто пустых строк), в нем используется трехкратно (считая сам делегат) вложенные друг в друга лямбда-функции (и получается загадочная картинка "найди на этом рисунке все лямбда-функции"), он использует отложенный вызов исключений через делегаты... Я думаю, что когда я буду писать планируемую мной статью о современных методах создания сложного кода - то есть использование нового синтаксиса, добавленного в язык, функциональное (по форме) программирование и т.п., причем так, чтобы формально соответствовать модным признакам хорошего кода, а что-то вроде банальных и известных уже десятилетиями операторов goto и циклов do на пяти страницах, которые не стеснялись использовать настоящие программисты ещё в 70-е годы - я обязательно постараюсь использовать этот кусок кода как жизненный пример применения таких методов. К сожалению, к очевидному предпочтительному сроку выхода такой статьи, 1 апреля сего года ;-) , я не успел, так что этот план пока что отложен.

Для иллюстрации реализации интерфейсов классом GenericWebHostBuilder, кроме обозначений, использованных на Рис.1, потребовались дополнительные обозначения. Прежде всего, это - расшифровки содержимого делегатов, создаваемых методами класса GenericWebHostBuilder: они на рисунке изображены в выносках, оформленных линией "штрих-две точки". Кроме того, использование механизма параметра (которое технически является конфигурирование нескольких описателей сервисов для контейнера серевисов) получило свое обозначение - прямоугольник со срезаннным правым верхним углом.

Ну, я понимаю, что слово "обертка" выглядит непрофессионально. Профессиональнее было бы назвать это как-то так, чтобы всем было видно, что я в курсе современных модных трендов Computer Science. Но... Если вспомнить функциональное программирование, то можно было бы назвать это композицией. Однако эти делегаты ни разу не являются функциями, и иммутабльностью от них не и пахнет. Так что от всех красот ФП осталось бы только красивое название. Если вспомнить паттерны проектирования, то можно упомянуть "паттерн Адаптер". Но как быть тогда с вызовом метода GetWebHostBuilderContext - который ни разу не прост, и, вообще говоря, его деятельность не исчерпывается простым преобразованием одного типа параметра в другой (подробности - ниже, в соответствующем разделе)? Короче, по такой причине я решил тут не умничать, а назвать этот тип делегата (он еще не раз нам встретится) по-простому: оберткой.

Делегаты-обертки для получения контекста построителя Web-приложения WebHostBuilderContext вызывают частный (но доступный благодаря замыканию) вспомогательный метод GetWebHostBuilderContext (он будет рассмотрен позднее) с аргументом - контекстом построения HostBuilderContext, полученным в качестве первого параметра делегата-обертки, а затем вызывают исходный делегат с аргументами нужного типа: полученным контекстом построителя веб-приложения и вторым параметром делегата-обертки, тип которого, как было написано ранее, зависит от рассматриваемого метода. Созданный во второй форме метода ConfigureServices делегат-обертка принимает два параметра - контекст построителя веб-приложения IWebHostBuilder и список регистраций сервисов IServiceCollection, и вызывает исходный делегат-параметр метода только со вторым из этих параметров, игнорируя первый.

Все эти методы расширения определены в классе WebHostBuilderExtensions пространства имен Microsoft.AspNetCore.Hosting.

Этот метод имеет две перегруженных формы, различающиеся типом второго параметра-делегата: Одна из них принимает делегат, содержащий два параметра - контекст построителя веб-приложения WebHostBuilderContext и параметры (options) контейнера сервисов ServiceProviderOptions. (этот класс описан в первой части, при описании фабрики контейнера сервисов по умолчанию DefaultServiceProviderFactory). Именно эта форма реализует всю логику метода UseDefaultServiceProvider. Вторая форма принимает делегат, содержащий только один параметр - параметры (options) контейнера сервисов ServiceProviderOptions. Она просто вызывает первую форму с аргументом в виде делегата-обертки, имеющего нужную сигнатуру (с двумя параметрами), который вызывает внутри себя делегат-параметр метода UseDefaultServiceProvider со своим вторым параметром ServiceProviderOptions в качестве аргумента.

То есть, она производит проверку построителя веб-приложения IWebHostBuilder на реализацию интерфейса перенаправления ISupportsStartup (иначе говоря, использование шаблона Generic Host) и вызывает его одноименный метод, если интерфейс реализован; в противном случае выполняет код для шаблона Web Host. Но перед проверкой этот метод дополнительно записывает во внутреннюю конфигурацию построителя веб-приложения IWebHostBuilder под ключом "applicationName" имя сборки, содержащей Startup-класс. Это значение, в частности, впоследствии используется в конструкторе класса WebHostOptions, с которым мы ещё встретимся позднее. Ну, и в самом приложении оно может быть использовано, поскольку, в конце концов, становится доступным через сервис конфигурации (IConfiguration). В любом случае и в любой форме метод UseStartup возвращает ссылку на IWebHostBuilder для объединения методов в цепочку.

Для первой формы это делегат очереди конфигурирования Middleware с одним параметром - делегатом, имеющим единственный параметр - ссылку на интерфейс создания конвейера Midleware IApplicationBuilder, для второй формы делегат очереди конфигурирования Middleware принимает два параметра: кроме уже упомянутого делегата (он является вторым параметром), ещё и контекст построителя веб-приложения WebHostBuilderContext. Обе публичные формы вызывают частную форму с аргументами: первым - интерфейсом IWebHostBuilder, вторым - делегатом с сигнатурой, соответствующей второй форме (первая форма для этого создает делегат-обертку, которая вызывает делегат-параметр этой формы с одним только вторым параметром обертки) и третьим - именем приложения. В качестве имени используется название сборки, в которой определен параметр-делегат метода Configure. В любом случае и в любой форме метод Configure также возвращает ссылку на IWebInterfaceBuilder для объединения методов в цепочку.

Делегат сначала получает контекст построителя веб-приложения WebHostBuilderContext с помощью вспомогательного метода GetWebHostBuilderContext, передавая в него в качестве аргумента параметр делегата - контекст построения HostBuilderContext. затем делегат создает новый объект параметров фабрики контейнера сервисов ServiceProviderOptions. После этого созданный делегат вызывает тот делегат, который был передан в метод UseDefaultServiceProvider с аргументом - вновь созданным объектом ServiceProviderOptions для установки свойств этого объекта. И, наконец, делегат создает и возвращает экземпляр фабрики контейнера сервисов по умолчанию DefaultServiceProviderFactory, в конструктор которого был передан сконфигурированный объект параметров контейнера сервисов ServiceProviderOptions.

Как реализовано однократное добавление. Метод UseStartup помимо добавления делегата ещё и запоминает в словаре построителя Properties под ключом "UseStartup.StartupType" тип регистрируемого Startup-класса. При следующей регистрации это значение перезаписывается типом следующего зарегистрированного Startup-класса (на рис.2 это не показано). А делегаты, помещенные методом UseStartup в очередь конфигурирования списка регистраций сервисов, сравнивают это значение из словаря с полученным через замыкание значением типа, для который они должны вызвать внутренний метод UseStartup, и вызывают его, только когда эти значения совпадают.

Далее в рассказе этот делегат, который был передан передается в метод ISupportsStartup.Configure, будет называться исходным или №0. Делается это следующим образом. В очередь конфигурирования списка регистрации сервисов помещается делегат конфигурирования установки значения параметра (option) типа GenericWebHostServiceOptions (№1), который будет выполнен, соответственно, на стадии конфигурирования списка регистрации серверов. В качестве параметров в него, как обычно будут переданы контекст построения HostBuilderContext и ссылка на конфигурируемый список регистраций сервисов IServiceCollection. Этот делегат (№1) конфигурирует в списке регистрации сервисов (одним из вариантов его метода расширения Configure) использование параметра (option) указанного типа с установкой значения (неименованного) этого параметра путем выполнения делегата задания значения (№2). Параметр типа GenericWebHostServiceOptions передается в конструктор класса веб-приложения GenericWebHostedService (через внедрение зависимостей) и используется в методе его запуска StartAsync. Делегат создания значения (№2) выполняется как раз в этот момент - в момент получения значения внутри метода StartAsync через интерфейс параметра (option). При выполнении делегат задания значения (№2) сначала получает контекст построителя веб-приложения WebHostBuilderContext с помощью вспомогательного внутреннего метода GetWebHostBuilderContext класса GenericWebHostBuilder (доступ к этому методу он получает через замыкание), передавая в него в качестве аргумента контекст построителя (полученный также через замыкание как параметр делегата конфигурирования установки значения параметра (№1)). Затем делегат создания значения (№2) записывает в свойство ConfigureApplication (постобработчик стартового кода) конфигурируемого объекта значения (этот объект он получает через свой параметр) делегат вызова исходного делегата (№3), который вызывает исходный делегат (№0) с аргументами - полученным контекстом построителя веб-приложения WebHostBuilderContext (будет получен через замыкание) и интерфейсом создания конвейера Midleware IApplicationBuilder (этот аргумент он получит в качестве своего единственного параметра). Этот делегат (№3) будет вызван в том же методе GenericWebHostedService.StartAsync немного позже, в процессе создания конвейера Midleware . и вызовет исходный делегат (№0). И, кстати, совершенно не факт, что этот делегат будет вызван: если после вызова метода расширения Configure будет идти другой вызов этого метода или метода UseStartup (он точно так же использует делегат для установки того же самого свойства неименованного значения того же самого типа с целью обеспечения вызова метода Configure, см. ниже), то значение этого свойства будет перезаписано другим делегатом, не №3. На рис.2 вся эта сложность не показана: там, чтобы сохранить ясность, показан только приближенный результат - делегат, переданный в Configure, будет записан в свойство ConfigureApplication передаваемого через механизм параметров (Options) экземпляра класса GenericWebHostServiceOptions.

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

Неплохо, да? Всего десять строк тела метода - и такие глубины, даже, не побоюсь этого слова, бездны фреймворка открываются. Причем, надо учесть, что это я сейчас написал, какие делегаты когда выполняются, и с какой целью это делается: в коде никаких комментариев, естественно нет, в документации такое тоже не описывают. А если ещё учесть, что делегат №3 неплохо замаскирован (равными отступами вокруг знака равенства и стрелки, что, убаюкивая глаз, делает его похожим на сравнение)... Короче, этот кусок кода - ещё один из очевидных кандидатов в примеры, как писать сложный код современными методами.

Для иллюстрации работы делегатов, помещенных конструктором класса построителя веб-приложения GenericWebHostBuilder в очереди для этапов работы построителя HostBuilder, и в частности - процесса конфигурирования на основе стартовых сборок, потребовалгсь ещё дополнительные обозначения. Во-первых - для этих самых сборок: они изображены на рис. прямоугольниками со скругленными углами, нарисованными двойными линиями (и внутри этих прямоугольников условно нарисованы содержащиеся в сборках классы). Во-вторых, производимые в процессе конфигурирования многочисленные вызовы интерфейсов построителя веб-приложения (IWebHostBuilder) и перенаправления из методов расширения этого интерфейса (они были рассмотрены ранее) условно изображены толстыми черными линиями.

Именем приложения по умолчанию для конструктора WebHostOptions указывается имя входной сборки

Это сделано так, чтобы делегаты в очередях конфигурирования были выполнены в нужном порядке: если бы класс-перехватчик просто переадресовывал бы вызовы этих методов вместо накопления списков (или бы его не было, и конфигурирование на основе стартовых сборок работало бы напрямую с GenericWebHostBuilder), то добавленные этими вызовами делегаты были бы помещены в свои очереди после делегатов, добавленных вызовами из класса Program (напомним, что конфигурирование на основе стартовых сборок производится уже в методе Build, после завершения метода Program.CreateHostBuilder). А это неправильно. Поэтому делегаты сначала накапливаются во внутренних списках класса-перехватчика, а потом выполняются в нужный момент - в тот момент, когда подходит очередь делегатов, помещенных туда конструктором класса GenericWebHostBuilder (то есть, если смотреть из класса Program - изнутри методов ConfigureWebHost/ConfigureWebHostDefaults, до выполнения переданного в них делегата) По неизвестной мне причине списки делегатов реализованы не как объекты обобщенного типа List<>, специализированного нужным типом делегата, а с использованием функциональности комбинирования делегатов: когда делегаты добавляются один к другому с помощью оператора + (или +=), а затем выполняются одним вызовом комбинированного делегата. В причинах такой разницы в реализации я не разбирался. Вторая форма метода ConfigureServices принимает в качестве параметра делегат с единственным параметром - списком регистрации сервисов IServiceCollection. Она создает делегат-обертку с сигнатурой, требуемой первой формой этого метода, и вызывает эту форму. Созданный в этой форме делегат-обертка принимает два параметра - контекст построителя веб-приложения IWebHostBuilder и список регистраций сервисов IServiceCollection, и вызывает исходный делегат-параметр метода только со вторым из этих параметров, игнорируя первый.

В этот список изначально добавляется сборка с именем самого приложения (по умолчанию это - его стартовая сборка), а также - сборки перечисленные в параметре конфигурации "hostingStartupAssemblies", а затем из него исключаются все сборки, перечисленные в параметре конфигурации "hostingStartupExcludeAssemblies".

Аргументом GetWebHostBuilderContext является контекст построения HostBuilderContext - первый параметр делегата, ну а ссылка на построитель конфигурации - это его второй параметр Ну и, перед тем, как вызвать метод ConfigureAppConfiguration класса-перехватчика, этот делегат проверяет, создан ли вообще объект этого класса: если конфигурирование на основе стартовых сборок запрещено, то этого объекта не будет. Накопленные делегаты метод ConfigureAppConfiguration класса-перехватчика применяет путем вызова комбинированного делегата, в котором скомбинированы все накопленые делегаты, передавая ему в качестве аргументов полученные параметры: контекст построителя веб-приложения и ссылку на построитель конфигурации IConfigurationBuilder.

А вот списка этих сервисов в дркументации, кажется, нет - пожтому приовожу его здесь. Обязательно регистрируются следующие сервисы: IWebHostEnvironment и AspNetCore.Hosting.IHostingEnvironment - время жизни постоянное (Singleton), реализацией является экземпляр класса HostingEnvironment, создаваемый методом GetWebHostBuilderContext, на него ссылается свойство HostingEnvironment созданного этим методом контекста построителя веб-приложения WebHostBuilderContext (см. описание этого метода). IApplicationLifetime - время жизни постоянное (Singleton), реализация - класс GenericWebHostApplicationLifetime В случаи отсутствия других регистраций регистрируются также следующие сервисы:

• Diagnostic Listener, Diagnostic Source - время жизни постоянное (Singleton), реализация - экземпляр объекта типа DiagnosticListener, конструктор которого вызван с аргументом-строкой "Microsoft.AspNetCore" (примечание: в процесе написания статьи, в конце марта, реализация была заменена на фабрику, создающую экземпляр этого типа - вероятно, чтобы контейнер сервисов мог контролировать время его жизни и вызвать для него Dispose);

• IHttpContextFactory - время жизни постоянное (Singleton), реализуются классом DefaultHttpContextFactory;

• IMiddlewareFactory - время жизни - ограниченная область (Scoped), реализуются классом MiddlewareFactory;

• IApplicationBuilderFactory - время жизни постоянное (Singleton), реализуются классом ApplicationBuilderFactory;

Точнее - пока ещё нет. На момент выполнения конструктора класса GenericWebHostBuilder поле _hostingStartupErrors ещё никакого исключения содержать не может - но делегат может сослаться на это поле. Исключение там может появиться в процессе конфигурирования на основе стартовых сборок, выполняемом позже, на стадии построения конфигурации построителя. Ну, а делегат, когда будет выполняеться, на еще более поздней стадии, скопирует ссылку на это исключение в нужное свойство нужного объекта GenericWebHostServiceOptions.HostingStartupExceptions Не правда ли, ловко получилось все запутать?

Накопленные делегаты метод ConfigureServices класса-перехватчика применяет путем вызова комбинированного делегата, в котором скомбинированы все накопленые делегаты, передавая ему в качестве аргументов полученные параметры: контекст построителя веб-приложения и ссылку на список регистраций сервисов IServiceCollection.

За нахождение нужного класса отвечает метод FindStartupType статического класса StartupLoader (который в целом отвечает за работу со Startup-классом, с ним мы ещё встретимся позднее). Этот метод загружает указанную сборку и ищет через содержащуюся в данных отражения информацию класс с подходящим именем (сначала - с суффиксом окружения, затем - без суффикса). Первоначально он проверяет корневое пространство имен и пространство имен с именем сборки (сначала - для имени суффиксом). Если тип с подходящим именем найден - возвращается именно он (в том числе в этом случае может быть возвращен тип с именем Startup без суффикса, даже в сборке в других пространствах имен есть тип с именем, содержащим суффикс окружения). Иначе метод FindStartupType строит список типов с подходящими именами из всех пространств имен (сначала - имена с суффиксом, затем - без) и возвращает первый найденный в списке тип. Если тип найти не удалось, то выбрасывается исключение InvalidOperationException.

И, похоже, в этом месте в коде ASP.NET содержится (причем - до сих пор) логическая ошибка: в отличие от делегата, помещаемого в очередь стадии конфигурирования списка регистрации сервисов IServiceCollection методом интерфейса перенаправления ISupportsStartup.UseStartup, в этом месте однократность вызова внутреннего метода UseStartup не гарантируется: третий делегат, помещенный конструктором, не проверяет, что в эту же очередь был после него помещен методом ISupportsStartup.UseStartup делегат вызова внутреннего метода UseStartup. Проверить это было бы несложно по содержимому словаря построителя (или, что то же самое - словаря контекста построителя - это один и тот же объект) Properties под ключом "UseStartup.StartupType": если значения под этим ключом есть (а ISupportsStartup.UseStartup именно туда записывает тип Startup-класса для избежания повторного вызова одноименного внутреннего метода), то в очереди уже находится, как минимум, один делегат вызова внутреннего метода UseStartup и вызывать этот метод здесь будет неправильным (его вызов был перекрыт последующим методом UseStartup).

К сожалению, у меня пока не нашлось времени, чтобы подготовить исправление как полодено: создать код, визуализующий эту ошибку, поправить ее (это элементарно - надо просто добавить проверку наличия значения под ключом UseStartup.StartupType), и, главное - настроить и выполнить сборку библиотеки вместе со всеми тестами, чтобы убедиться, что при исправлении ничего не сломано.

Для этого в списке регистрации сервисов регистрируется (одним из вариантов его метода расширения Configure) сервис установки неименованного значения параметра (option) типа GenericWebHostServiceOptions, записывающий в постобработчик стартового кода - свойство ConfigureApplication делегат, повторно выбрасывающий это исключение. Этот делегат будет вызван в методе вместо в методе StartAsync класса веб-сервиса GenericWebHostedService при запуске веб-приложения вместо делегата, вызывающего метод Configure Startup-класса. Таким образом, исключение будет повторно выброшено в методе запуска веб-приложения для обработки его там (например - для отображения на странице веб-сайта), что как раз и подразумевает семантика флага CaptureStartupErrors

Для начала стоит сделать небольшое примечание для облегчения дальнейшего понимания: словарь Properties контекста построения и одноименное свойство построителя IHostBuilder реализованного классом HostBuilder - это один и тот же объект. Поэтому не надо удивляться встречающимся иногда (например, в рассматриваемом куске кода) случаям, когда объект заносится в словарь контекста построения, а доступ к нему производится через интерфейс построителя IHostBuilder или наоборот. Теперь можно продолжить рассказ о подробностях реализации и использовании метода GetWebHostBuilderContext. Прежде всего, отметим, что метод GetWebHostBuilderContext создает экземпляр объекта WebHostBuilderContext и копирует в его свойство Configuration ссылку на конфигурацию из контекста построения HostBuilderContext - параметра метода только один раз - припервом вызове. А так как первый вызов GetWebHostBuilderContext (он производится из второго делегата конструктора) происходит на стадии создания конфигурации приложения, то в объект WebHostBuilderContext первоначально передается ссылка на конфигурацию построителя: свойство Configuration в этот момент содержит именно ее, однако значение этого свойства будет заменено на конфигурацию приложения позже, после окончания построения этой конфигурации. Затем этот метод создает новый экземпляр типа HostingEnvironment и сохраняет ссылку на созданный экземпляр в свойстве HostingEnvironment созданного ранее объекта WebHostBuilderContext, после чего - вызывает метод расширения Initialize (определен в классе HostingEnvironmentExtensions) для экземпляра типа HostingEnvironment для его инициализации. Метод Initialize вызывается с двумя аргументами: строкой-путем к содержимому приложения (из свойства ContentRootPath окружения размещения (хоста) IHostEnvironment, на которое ссылается поле HostingEnvironment контекста построения HostBuilderContext) и объектом типизированных параметров веб-приложения WebHostOptions, о котором будет рассказано чуть позднее и который на этот момент уже создан. Данный метод копирует свойство ContentRootPath из переданного ему строкового параметра, свойства ApplicationName и EnvironmentName (последнее - если не null, иначе используется значение по умолчанию "Production") - из второго параметра, объекта типизированных параметров WebHostOptions, свойство WebRootPath также берется из того же параметра, но, если этот путь - относительный, преобразуется в абсолютный, считая его путем относительно ContentRootPath. Файловыми провайдерами ContentRootPathProvider и WebRootPathProvider становятся объекты типа PhysicalFileProvider с базовыми путями ContentRootPath и WebRootPath соответственно.

Конструктор WebHostOptions принимает два параметра: конфигурацию (IConfiguration), из которой строится этот объект типизированных параметров? и имя приложения по умолчанию. В качестве аргумента-конфигурации в конструктор WebHostOptions передается ссылка на конфигурацию из контекста построения HostBuilderContext (свойство Configuration). Как уже было сказано выше эта ссылка указывает в момент вызова конструктора WebHostOptions на конфигурацию построителя. Именем приложения по умолчанию для конструктора WebHostOptions указывается имя входной сборки. Свойства объекта WebHostOptions заполняются на основе содержимого конфигурации, переданной первым параметром Если имя приложения в конфигурации не указано, то вместо него используется имя приложения по умолчанию из второго параметра. Список свойств объекта WebHostOptions достаточно велик (их более 10), поэтому я позволю себе не перечислять их и те имена значений конфигурации, из которых они берутся.

Да-да, это - то самое, модное-стильное-молодежное внедрение зависимостей (в данном случае - в метод), которое так любят нынешние теоретики от программирования. А подробности, через какое место эти самые зависимости внедряются на практике, теоретиков обычно не интересуют. Но так как этот текст - не плод труда теоретика, то в нем эти подробности - как внедряются зависимости в метод Configure - рассмотрены будут обязательно.

Но с самыми большими и интересными частями этого класса - основным методом LoadMethods и внутренним вложенным классом ConfigureServicesDelegateBuilder, реализующим основную часть функциональности этого метода - нам, к счастью, иметь дела не придется: это - части кода, предназначенные исключительно для шаблона Web Host. На долю Generic Host остаются только небольшие вспомогательные методы.

Все упомянутые методы основаны на внутреннем методе FindMethod класса StartupLoader, который ищет метод с подходящим именем. Этот метод возвращает MethodInfo для найденного метода Startup-класса или null, если метод не найден и при этом он не является требуемым (см. ниже). Если найдено более одного метода с одинаковым именем или не найден требуемый метод, то выбрасывается исключение InvalidOperationException. Параметры метода FindMethod - следующие. Первый - тип Startup-класса, второй - строка-шаблон имени (для подстановки имени окружения с помощью метода String.Format, т.е. содержащая строку "{0}" в месте подстановки), третий - имя окружения, четвертый - тип результата (null - не проверяется), пятый - является ли метод требуемым. Реализованы методы поиска методов Startup-класса следующим образом. Все они в качестве двух аргументов передают в FindMethod свои параметры (у всех этих методов параметры одинаковые): в качестве первого аргумента (тип Startup-класса) - первый параметр, третьего аргумента (имя окружения) - второй параметр. Метод FindConfigureServicesDelegate класса StartupLoader вызывает FindMethod один или два раза, оба раза - со следующими аргументами: шаблон имени (второй аргумент) - "Configure{0}Services", флаг требуемого метода (пятый аргумент) - false. Первый раз FindMethod вызывается с типом возврата (четвертый аргумент) IServiceProvider (т.е., ищется метод ConfigureServices Startup-класса, который создает и возвращает контейнер сервисов). Если первый вызов FindMethod возвращает null (нет такого метода в Startup-классе), то производится второй вызов FindMethod, без проверки типа возврата (четвертый аргумент равен null). И, наконец, FindConfigureServicesDelegate создает и возвращает объект вспомогательного класса ConfigureServicesBuilder, в конструктор которого передается результат последнего вызова FindMethod. Метод FindConfigureContainerDelegate класса StartupLoader вызывает FindMethod со следующими аргументами: шаблон имени (второй аргумент) - "Configure{0}Container", четвертый аргумент - null(без проверки типа возврата), флаг требуемого метода (пятый аргумент) - false. Затем FindConfigureContainerDelegate создает и возвращает объект вспомогательного класса ConfigureContainerBuilder, в конструктор которого передается результат последнего вызова FindMethod. Метод FindConfigureDelegate класса StartupLoader вызывает FindMethod со следующими аргументами: шаблон имени (второй аргумент) - "Configure{0}", четвертый аргумент - null(без проверки типа возврата), флаг требуемого метода (пятый аргумент) - true (метод Configure обязан существовать в Startup-классе. Затем FindConfigureDelegate создает и возвращает объект вспомогательного класса ConfigureBuilder, в конструктор которого передается результат последнего вызова FindMethod. В методе HasConfigureServicesIServiceProviderDelegate класса StartupLoader делается вызов FindMethod с теми же параметрами, что и первый вызов в FindConfigureServicesDelegate. Возвращаемое значение - неравенство результата FindMethod значению null.

Метод Build в ConfigureServicesBuilder формально возвращает делегат типа Func<IServiceCollection, IServiceProvider> - так как этот вспомогательный класс используется и в шаблоне Web Host, то он возвращает делегат, формально совместимый с требованиями для этого шаблона. В коде шаблона Generic Host (внутренний метод) возвращаемое этим делегатом значение всегда будет null (т.к. метод сам метод ConfigureServices требуемый для шаблона Generic Host, не должен возвращать значение), и данный делегат фактически используется как Action. Метод Build в ConfigureContainerBuilder возвращает делегат типа Action&lt;object>: ConfigureContainerBuilder является необобщенным классом, у него нет параметра-типа для типа контейнера-построителя, поэтому он работает с контейнером-построителем как с универсальным типом Object. Вся необходимая работа с конкретным типом выполняется кодом внутреннего метода UseStartup (забегая вперед: там используется весьма интересный прием для вызова специализации типом контейнера-построителя, неизвестным во время компиляции, обобщенного метода ConfigureContainer построителя IHostBuilder.) Метод Build в ConfigureBuilder возвращает делегат типа Action&lt;IApplicationBuilder>, с одним параметром, хотя сам метод Configure Startup-класса может иметь дополнительные параметры (их значения в таком случае будут получены(внедрены) из контейнера сервисов).

Делегаты, которые возвращают все перечисленные вспомогательные классы, также устроены единообразно: они вызывают внутренний метод Invoke соответствующего класса, принимающий два параметра - ссылку на Startup-класс и специфический для вспомогательного класса параметр, - с фиксированным первым аргументом - переданной как параметр в метод Build ссылкой на Startup-класс (она хранится в замыкании этого делегата). Второй передаваемый в Invoke аргумент - это параметр (единственный) возвращаемого делегата: его тип - IServiceCollection для класса ConfigureServicesBuilder, Object - для ConfigureContainerBuilder и IApplicationBuilder - для ConfigureBuilder.

Методы Invoke классов ConfigureServicesBuilder и ConfigureContainerBuilder устроены похожим образом, поэтому они будут рассмотрены вместе. Прежде всего, для полноты имеет смысл упомянуть об ранее не упомянутых свойствах этих классов, которые не используются в шаблоне Generic Host, но используются в Web Host. Это - общедоступные для чтения и записи свойства-фильтры, их имена - StartupServiceFilters в ConfigureServicesBuilder и ConfigureContainerFilters в ConfigureContainerBuilder соответственно. Вообще-то все, что касается этих свойств, как неиспользуемых, можно при чтении пропустить. Но для полноты картины я их тут все же опишу - потому что они устроены весьма небезынтересно. Эти свойства содержат делегаты-фильтры - функции с одним параметром, причем типом и параметра, и результата делегата-фильтра является тот же тип делегата, что и тип делегата, возвращаемого методом Build соответствующего класса. Эти делегаты-фильтры предназначены для преобразования переданного им в качестве параметра входного делегата в выходной делегат с той же сигнатурой: они возвращают в виде результата выходной делегат, который (обычно вызывает (но может и не вызывать) переданный им в качестве параметра входной делегат, но при этом он может как изменять аргумент входного делегата перед его вызовом, так и результат, возвращаемый входным делегатом после его вызова. С помощью этих свойств-фильтров в шаблоне Web Host реализуется функциональность фильтров конфигурирования процесса создания контейнера сервисов с интерфейсами IStartupConfigureServicesFilter и IStartupConfigureContainerFilter<>. Но, как уже упоминалось, в шаблоне Generic Host эти свойства-фильтры не используются: их значения по умолчанию - делегаты-фильтры, которые не делают ничего, а просто возвращают переданный им параметр-делегат - так и остаются неизменными. Однако код методов Invoke этих классов, поскольку он - общий для обоих шаблонов - Web Host и Generic Host, вызов делегатов-фильтров, содержащихся в этих свойствах, содержит, поэтому они и были упомянуты. Конкретно, метод Invoke этих классов возвращает значение, получаемое от результата применения делегата-фильтра из свойства (которое в Generic Host, как уже говорилось, содержит делегат, который просто возвращает то, что ему передали на вход) к внутренней функции, определенной внутри метода Invoke (ее имя - Startup в классе ConfigureServicesBuilder или StartupConfigureContainer в классе ConfigureContainerBuilder). А проще говоря, в шаблоне Generic Host просто вызывается эта самая определенная в методе Invoke внутренняя функция. Эта внутренняя функция имеет ту же сигнатуру, что и делегат, возвращаемый методом Build. Она принимает один специфический для вспомогательного класса параметр (IServiceCollection в классе ConfigureServicesBuilder или Object в классе ConfigureContainerBuilder), после чего вызывает внутренний метод InvokeCore своего класса, передавая в него в качестве аргументов ссылку на экземпляр Startup-класса (переданный как параметр в метод Invoke) и свой единственный параметр. Внутренняя функция класса в ConfigureServicesBuilder, в соответствии со своей сигнатурой, также возвращает полученное из InvokeCore значение IServiceProvider (в шаблоне Generic Host оно всегда null и не используется). Метод InvokeCore принимает два параметра - ссылку на Startup-класс и специфический для вспомогательного класса параметр, упомянутый выше. Он подготавливает список аргументов для вызова: массив из одного элемента - своего второго параметра. А затем он вызывает соответствующий метод Startup-класса с помощью MetodInfo.Invoke для экземпляра Startup-класса, полученного как первый параметр, с этим списком аргументов, причем при вызове указывается флаг BindingFlags.DoNotWrapExceptions, предотвращающий оборачивание исключения при вызове, если оно будет выброшено, в исключение TargetInvocationException. Метод InvokeCore класса ConfigureServicesBuilder возвращает значение, полученное из MetodInfo.Invoke, если вызываемый таким образом метод не возвращает значения - что требуется в шаблоне Generic Host - то возвращаемое значение будет null.

Метод Invoke класса ConfigureBuilder устроен по-другому. Во-первых, в этом классе нет свойства-фильтра, а потому вызов метода Configure Startup-класса производится непосредственно из метода Invoke. Во-вторых, метод Invoke получает из информации отражения список параметров метода Configure (он, напомним, может иметь дополнительные параметры), и для всех параметров, кроме имеющего тип IApplicationBuilder, извлекает в качестве значений аргументов для них сервисы того же типа из контейнера сервисов (доступного через свойство ApplicationServices интерфейса IApplicationBuilder). Эти значения затем подставляются в качестве значений соответствующих аргументов для вызова Configure. Тем самым метод Invoke производит то, что у теоретиков называется "внедрением зависимостей". Для аргумента типа IApplicationBuilder подставляется то значение, которое передается в метод Invoke в качестве второго параметра. И затем метод Configure вызывается с помощью MetodInfo.Invoke для экземпляра Startup-класса, полученного как первый параметр, с этим списком аргументов, причем при вызове так же, как и в двух остальных вспомогательных классах, указывается флаг BindingFlags.DoNotWrapExceptions. Если говорить более точно, то в качестве источника аргументов используется не сам этот контейнер сервисов (корневой), а контейнер сервисов ограниченной области, созданный его на основе: эта ограниченная область охватывает получение аргументов и вызов метода Configure Startup-класса и затем удаляется перед завершением делегата. Применение ограниченной области позволяет использовать для вызова метода Configure сервисы со временем жизни ограниченной области (Scoped).

Поскольку работа метода UseStartup активно связана с метаданными и отражеением, потребовалось новое обозначение - для метаданных. Сами метаданные обозначены прямоугольниками с пунктирными границами: обычными прямоугольниками - метаданные методов, прямоугольником со скургленными углами - метаданные класса. А использование метаданных изображено пунктирными соединительными линиями.

Делает он это точно так же, как и третий делегат конструктора: вызывает вспомогательный метод GetWebHostBuilderContext с аргументом - контекстом построения HostBuilderContext, полученным в качестве второго параметра внутреннего метода UseStartup. Вызванный метод возвращает WebHostBuilderContext. Затем внутренний метод UseStartup извлекает объект WebHostOptions из словаря Properties контекста построения HostBuilderContext, который был помещен туда тем же самым методом GetWebHostBuilderContext при его самом первом вызове.

При этом производятся две проверки: что Startup-класс не реализует интерфейс IStartup (в котором сигнатура метода ConfigureServices указывает на то, что он возвращает IServiceProvider) и, если не реализует (т.е. используется запуск, основанный на соглашениях) - что не возвращает значение IServiceProvider (созданный методом ConfigureServices . Если это условие нарушается, то выбрасывается исключение NotSupportedException. Проверка на то, что метод ConfigureServices не возвращает IServiceProvider при использовании запуска, основанного на соглашениях, производится с помощью метода StartupLoader.HasConfigureServicesIServiceProviderDelegate.

Упомянутые два устаревших интерфейса, доступных в суррогатном котейнере - это Microsoft.Extensions.Hosting.IHostingEnvironment и Microsoft.AspNetCore.Hosting.IHostingEnvironment. Реализацией суррогатного контейнера сервисов IServiceProvider является вложенный класс HostServiceProvider, определенный внутри GenericWebHostBuilder. Эта реализация основана на объекте контекста построителя веб-приложения WebHostBuilderContext, который передается в конструктор этого класса: сервис IConfiguration реализуется объектом, на которое ссылается поле Configuration контекста построителя веб-приложения (а на данной стадии оно ссылается уже на полную конфигурацию приложения), остальные реализованные сервисы - объектом, на который ссылается поле HostingEnvironment контекста построителя веб-приложения. Создание экземпляра Startup-класса производится методом ActivatorUtilities.CreateInstance. В этот метод в качестве аргумента - контейнера сервисов передается ссылка на вновь создаваемый экземпляр класса суррогатного контейнера HostServiceProvider, конструктору которого в качестве аргумента передается полученный ранее контекст построителя веб-приложения WebHostBuilderContext. Созданный экземпляр Startup-класса сохраняется в локальной переменной instance, а в словаре контекста построения HostBuilderContext он запоминается под ключом, равным значению поля _startupKey (это поле инициализуется новым объектом Object при инициализации экземпляра GenericWebHostBuilder).

Почему вместо ключа _startupKey в поле (изменив его тип) объекта GenericWebHostBuilder нельзя было поместить сам экземпляр Startup-класса - для меня остается загадкой: все равно ведь для доступа к этому экземпляру требуется значение какого-то поля того же самого экземпляра GenericWebHostBuilder. Единственное разумное предположение - чтобы развязать времена жизни классов GenericWebHostBuilder и Startup-класса: т.к. ссылка на последний хранится в контексте построения HostBuilderContext, существующий до конца времени жизни приложения (точнее, контейнера сервисов, как сервис с постоянным (Singleton) временем жизни, то GenericWebHostBuilder можно безбоязненно после инициализации собрать как мусор. Правда, зачем нужно сохранять Startup-класс и почему, если нужно, это нельзя было сделать ссылкой из другого места - это мне так и осталось непонятным.

Делегат вызывается с аргументом - ссылкой на список регистрации сервисов IServiceCollection, являющейся третьим параметром внутреннего метода UseStartup. Для создания делегата для вызова метода ConfigureServices внутренний метод UseStartup сначала получает с помощью метода StartupLoader.FindConfigureServicesDelegate (передавая в него в качестве аргументов тип Startup-класса и название текущего окружения - Development, Production и т.д.) экземпляр вспомогательного класса получения делегата ConfigureServicesBuilder. Этот и последущие создаваемые экземпляры вспомогательных классов (все они являются локальными переменными метода) изображены на рис.4 внутри штриховых рамок, подписанных именами локальных переменных во внутреннем методе UseStartup. Затем требуемый делегат создается методом Build вспомогательного класса, в который в качестве аргумента передается созданный ранее экземпляр Startup-класса.

Экземпляр вспомогательного класса получения делегата создается с помощью метода StartupLoader.FindConfigureContainerDelegate. Проверка, что метод ConfigureContainer реализован в Startup-классе, производится путем сравнения свойства MethodInfo вспомогательного класса с null.

Процесс помещения делегата обратного вызова в очередь конфигурирования контейнера-построителя в деталях выглядит следующим образом. Сначала методом GetContainerType полученного ранее экземпляра вспомогательного класса ConfigureContainerBuilder определяется тип контейнера-построителя.

Затем ссылка на этот экземпляр вспомогательного класса запоминается в словаре Properties построителя под ключом - типом класса ConfigureContainerBuilder для последующего использования в делегате обратного вызова, который будет передан в метод ConfigureContainer<> построителя IHostBuilder.

Базой для создания упомянутого делегата обратного вызова, который будет выполняться на этапе конфигурирования контейнера-построителя, служит обобщенный метод-заготовка GenericWebHostBuilder.ConfigureContainer<> (на рис.4 он изображен в упрощенном виде над внутренним методом UseStartup) Этот обобщенный метод-заготовка имеет два параметра: контекст построения HostBuilderContext и ссылку на контейнер-построитель (ее тип - это параметр-тип обобщенного метода). Делает этот метод-заготовка следующее. Сначала из словаря Properties контекста построения - первого параметра метода (напомним, что этот словарь - общий для построителя и для контекста построителя) извлекаются ссылки: на экземпляр вспомогательного класса получения делегата ConfigureContainerBuilder (она была сохранена под ключом - типом класса ConfigureContainerBuilder) и на ранее созданный экземпляр Startup-класса (под ключом, хранящемся во внутреннем поле _startupKey). Затем вызовом метода Build, в который в качестве аргумента передается извлеченный экземпляр Startup-класса, для извлеченного экземпляра вспомогательного класса ConfigureContainerBuilder создается делегат вызова метода ConfigureContainer для извлеченного экземпляра StartUp-класса . И, наконец, созданный делегат вызова метода ConfigureContainer вызывается внутри метода-заготовки делегата обратного вызова.

После сохранения ссылки на экземпляр вспомогательного класса создается делегат обратного вызова и реализуется тот самый "хитрый способ" (с использованием отражения) вызова обобщенного метода IHostBuilder.ConfigureContainer<> построителя с установкой параметров-типов делегата и обобщенного типа равными типу контейнера-построителя во время выполнения. Делегат обратного вызова создается путем специализации обобщенного метода-заготовки GenericWebHostBuilder.ConfigureContainer<> типом контейнера-построителя. Для этого сначала создается (и сохраняется в переменной actionType) тип параметра для вызываемой специализации вызываемого обобщенного метода построителя IHostBuilder.ConfigureContainer<>, он же - тип для делегата обратного вызова (который и будет параметром). Это делается путем специализации обобщенного типа Action<,> при помощи вызова его метода MakeGenericType двумя параметрами-типами: контекстом построения HostBuilderContext и конкретным типом контейнера-построителя, полученным ранее из вспомогательного класса ConfigureContainerBuilder. Затем вызовом метода GetType() находится тип класса (т.е. GenericWebHostBuilder), содержащего выполняющийся в данный момент метод, в этом типе с помощью отражения (вызовом GetMethods() с фильтрацией возвращенных результатов по имени метода) находится ссылка на описатель его обобщенного метода ConfigureContainer<>, потом создается (вызовом MakeGenericType для найденного описателя) специализация этого метода типом контейнера-построителя и, наконец, создается (вызовом CreateDelegate) делегат с ранее созданным типом actionType для этой специализации и текущего (this) экземпляра. Это и будет тот самый делегат обратного вызова. Теперь, при наличии нужного в качестве аргумента делегата, можно вызывать обобщенный метод построителя IHostBuilder.ConfigureContainer<>, специализированный типом контейнера-построителя. Чтобы произвести этот вызов, для типа построителя (IHostBuilder) через отражение (вызовом GetMethods() с фильтрацией возвращенных результатов по имени метода) находится ссылка на описатель вызываемого обобщенного метода ConfigureContainer<> построителя, потом создается (вызовом MakeGenericType для найденного описателя) специализация этого метода типом контейнера-построителя, и, наконец, производится вызов этой специализации ее методом Invoke с указанием делегата обратного вызова как единственного аргумента и с флагом BindingFlags.DoNotWrapExceptions, предотвращающим оборачивание исключения при вызове, если оно будет выброшено, в исключение TargetInvocationException.

Этот прием получения специализации обобщенных методов и классов во время выполнения я раньше не знал. Теперь буду знать - вдруг пригодится.

Получение экземпляра вспомогательного класса ConfigureBuilder производится методом StartupLoader.FindConfigureDelegate. Полученный экземпляр сохраняется в локальной переменной configureBuilder.

Эта переменная имеет тип ExceptionDispatchInfo - чтобы это исключение можно было выбросить позднее, возможно - в другом потоке (это произойдет уже в методе StartAsync класса веб-приложения GenericWebHostedService, подробности см. ниже).

Тип делегата-постобработчика - Action<IApplicationBuilder>. Делегат-постобработчик, прежде всего, проверяет, есть ли сохраненная информация об исключении в доступной через замыкание локальной переменной startupError (т.е., что эта переменная - не null). Если информация об исключении есть, то это исключение выбрасывается повторно методом startupError.Throw, но уже в новом контексте. В противном случае делегат-постобработчик создает делегат для вызова метода Configure Startup-класса и вызывает его. Делегат для вызова метода Configure Startup-класса создается с помощью метода Build экземпляра вспомогательного класса ConfigureBuilder, хранящегося в доступной через замыкание локальной переменной configureBuilder. В качестве аргумента в метод Build передается ранее созданный экземпляр Startup-класса, находящийся в доступной через замыкание локальной переменной instance. Делегат-постобработчик, как уже описывалось выше, передается в метод GenericWebHostedService.StartAsync через механизм параметров(Option) как значение (неименованное) типа GenericWebHostServiceOptions: с помощью метода расширения Configure<GenericWebHostServiceOptions>, вызываемого для параметра метода UseStartup, который имеет тип ICollectionServices, делегат-постобработчик записывается (делегатом, выполняющим конфигурирование значения) в свойство постобработчика стартового кода ConfigureApplication этого значения. На рис.4 упомянутый элемент конфигурирования параметра типа GenericWebHostServiceOptions (вместе с делегатом в свойстве ConfigureApplication) обозначен прямоугольником с одним срезанным углом. Содержимое делегата изображено в выноске "Delegate in a ConfigureApplication propery" справа. Т.к. элемент конфигурирования параметра в реальности действует путем регистрирации спецального сервиса для помещения в контейнер сервисов (подробности см. ниже при описании передачи значения параметра типа GenericWebHostedService), то на рис.4 отображено, что он помещает запись в список регистрации сервисов, т.е. выполняет действие, похожее на действие метода ConfigureServices Startup-класса.

К сожалению, не знаю, как слово Middleware перевести правильно на русский в используемом в ASP.NET контексте - прямой перевод "промежуточное программное обеспечение" категорически не подходит. Поэтому, подобно Пушкину, оставляю его, как есть - без перевода и транслитерации.

Интерфейс доступа к этому значению - IOption<GenericWebHostServiceOptions> - является одним из параметров конструктора класса веб-сервиса GenericWebHostedService. Значение этот параметр получает через механизм внедрения зависимостей при получении из контейнера сервисов реализации интерфейса IHost, который как раз реализуется классом GenericWebHostedService. Значение свойства Value этого интерфейса копируется в конструкторе этого класса в свойство Options. Значение параметра создается в момент первого к нему обращения путем вызова всех делегатов, устанавливающих это значение, в том порядке, в котором они были зарегистрированы. Эти делегаты (их может быть несколько) были ранее переданы для регистрации в метод расширения Configure интерфейса списка регистрации сервисов IServiceCollection. Делегат, устанавливающий свойства WebHostOptions и HostingStartupExceptions значения регистрируется только один раз, третьим делегатом из конструктора класса GenericWebHostBuilder, который конструктор помещает в очередь конфигурирования списка регистрации сервисов. А вот делегаты, устанавливающие свойство ConfigureApplication (делегат-постобработчик) могут регистрироваться несколько раз: это может сделать либо внутренний метод UseStartup построителя веб-приложения GenericWebHostBuilder, либо делегат, созданный методом Configure построителя веб-приложения (описание, как это происходит, ищите выше по тексту этой статьи). Но в результате выполнения всех делегатов установки значения параметра, свойство будет содержать только один, последний зарегистрированный, делегат-постобработчик - который и будет использован далее. Таким образом, разрешается возможный конфликт между методом Configure Startup-класса и делегатом, выполняющим ту же функцию, переданным через метод расширения Configure интерфейса IWebHostBuilder.

Конструктор этого класса имеет в качестве параметра последовательность фильтров запуска IEnumerable<IStartupFilter>, поэтому при создании экземпляра этого класса как реализации IHostedService, контейнер сервисов создает все зарегистрированные реализации интерфейса IStartupFilter и передает их в качестве аргумента для соответствующего параметра, а конструктор копирует их в свойство StartupFilters. Еще два параметра конструктора, которые получаются из контейнера сервисов через механизм внедрения зависимостей, и которые используются в описываемом процессе создания конвейера Middleware, - это ссылка на интерфейс фабрики построителя веб-приложения IApplicationBuilderFactory (копируется в свойство ApplicationBuilderFactory) и на интерфейс веб-сервера IServer (копируется в Server) Server

В качестве исходного элемента цепочки используется (локальная переменная configure) тот самый делегат-постобработчик из свойства ConfigureApplication значения параметра типа GenericWebHostServiceOptions (оно, напоминаем, было скопировано в свойство Options текущего класса). После этого вызывается, как описано выше, метод Configure каждого из членов последовательности объектов, реализующих IStartupFilter (из свойства StartupFilters), взятых в обратном порядке. В этот метод в качестве аргумента передается ссылка на предыдущий головной элемент цепочки из переменной configure, а результат вызова записывается обратно в эту же переменную. Таким образом, после выполнения этого процесса переменная configure содержит ссылку на цепочку делегатов конфигурирования конвейера, выстроенных в нужном порядке.

Объект построителя веб-приложения получается вызовом метода CreateBuilder свойства ApplicationBuilderFactory текущего класса, впоследствии он сохраняется в локальной переменной builder. Напоминаем, что свойство ApplicationBuilderFactory содержит ссылку на фабрику построителей веб-приложения IApplicationBuilderFactory, получающую указанным выше методом экземпляр типа, реализующего интерфейс построителя веб-приложения IApplicationBuilder. В качестве аргумента в этот метод передается значение свойства Features свойства Server текущего класса. Свойство Server, напоминаем, содержит ссылку на интерфейс IServer используемого веб-сервера (Kestrel и т.д., в зависимости от конфигурации), т.е. в качестве аргумента передается коллекция (типа IServerFeatureCollection) возможностей (features) используемого веб-сервера. Рассмотрение, что именно представляет собой эта коллекция, находится за рамками данной статьи. По факту в реализации фабрики построителей веб-приложения по умолчанию (класс ApplicationBuilderFactory в пространстве имен Microsoft.AspNetCore.Hosting.Builder) метод CreateBuilder просто создает и возвращает новый экземпляр объекта ApplicationBuilder, в конструктор которого передаются два аргумента: контейнер сервисов приложения (фабрика построителей получает к нему доступ через внедрение зависимостей в конструкторе) и полученная в качестве параметра коллекция возможностей (features) веб-сервера.