MVV

Зависит от того, чего вы хотите.
Если вас устраивает, что задача, выполняющая HandleClientAsync для подключившегося клиента будет брошена на произвол судьбы, можно использовать оба варианта (но первый мне нравится больше). Если вы хотите узнать, чем она закончилась - надо делать по-друому.
PS См. также комментарии к вопросу.

Есть несколько соображений.
Сображение первое, глубоко теоретическое. Логическая структура конкретного приложения - это вопрос специфичный именно для приложения. Думать о ней в терминах соответствия некой теоретической "архитектуре" (тем более - "чистой архитектуре") - это самоограничение, достойное только зеленых новичков. Настоящие программисты не используют чистую архитектуру. Кароче, как вы приложение напишете, такая у него архитектура и будет. Возможно, если ваше приложение будет в чем-то замечательным, то эта архитектура войдет в учебники по этой самой архитектуре, в качестве примера (может - положительного, но, скорее, отрицательного ;-) ). Но пока что вам нужно решать практические вопросы, и шаблоны т.н. "архитектуры" могут служить только в качестве подсказки, а решать придется вам, из чисто практических соображений.

Соображение второе, практическое. Раз, как вы пишете "Domain содержит только сущности, Enum'ы", то выбросьте из головы слово Domain, оно вас только запутывает. Потому что намекает на DDD, а то, что у вас есть, в DDD обзывают "анемичной моделью", и сильно не любят. Т.е. сейчас, с нынешней структурой приложения, DDD - оно не про вас.

Так что, по факту, у вас есть два слоя абстракций, описывающих функции классов и методов: UI и Application. И я подозреваю, что логика приложения - классы и методы, отнесенные к Application - использует в качестве средства доступа к БД EF напрямую. То есть - что там прямо в коде используются сущности под названием DbContext и DbSet.

А это означает, если по жизни, что от EF вы в таком раскладе никуда впоследствии не денетесь. Хорошо это или плохо - решать вам. Однако о намерении прибить гвоздями свое приложение к EF вы не упоминали и, предполагаю, не думали. Если это так, то задумайтесь именно об этом. Не о замене БД - EF может работать поверх разных БД, так что к MS SQL вы, по факту, с EF привязаны не будете (ну, разве что, сами того очень захотите).

А задуматься надо: EF - штука неоднозначная. Она, подобно любому средству ORM, полна абстракций, которые, так скажем, не совсем хорошо ложатся на логическую структуру реляционных БД, а потому в них есть заметные дыры, через которые эта структура будет проглядывать. В частности, это нередко касается вопросов производительности.

Но если вы выберети жизнь EF и ни с чем другим, то о Repository и UoW можете больше не думать: EF будет для вас и тем, и другим.

Кароче, выбирайте.

Добавьте в начало файла строку using System.Linq;
чтобы указать компилятору искать методы расшерения в этом пространстве имен.
ToList() - это метод расширения для интерфейса IEnumerable<Matches>, который реализуется объектом, который возвращает метод Regex.Matches. Этот метод определен (как обобщеный, для IEnumerable<T>) в классе Enumerable из пространства имен System.Linq.
PS Подозреваю, что у автора примера ссылка на это пространство имен живет в Global Usings, а потому у него все работает, а у вас - нет.

Task (задача) - это не Thread. Это спрецифичный для исполняющей системы (CLR) .NET объект, который позволяет отследить завершение выполнения операции, выполняющейся независимо от вашего основного потока управления и получить результат выполнения, если он есть (в вышем случае результата нет). Для запуска задачи, которую возвращает асинхронный метод (в отличие от вновь созданного объекта задачи - new Task(...)) ничего делать не нужно - она уже запущена исполняющей системой. Поток (Thread) для ее выполнения, если он нужен (а нужен он не всегда, иногда задача завершается внутри асинхронного метода синхронно) обычно берется из пула потоков (но могут быть нюансы, если они вам интересны - читайте про SynchronizationContext).
Если вам нужно дождаться выполнения задачи в синхроннном коде (у вас сейчас такой), то следует использовать метод задачи Wait(), но он заблокирует основной поток. Альтернатива для современного .NET (7.3 для этого достаточно современный) - использовать асинхронный метод Main: просто указать static async Task Main() вместо static void Main. Тогда можно дожидаться выполнения Install асинхронно, с помощью операции await: await update.Install(); При этом основной поток блокироваться не будет, но если ему все равно делать нечего (это зависит от типа приложения), то выигрыша от этого не будет (в консольном приложении, например).
PS Зачем вы применили атрибут [STAThread] к метод Install? Ведь, согласно документации

Примените этот атрибут к методу точки входа (Main()метод в C# и Visual Basic). Это не влияет на другие методы

То есть, он тут бессмысленнен. И вообще, это - тяжкое наследие технологии OLE2/COM.

Судя по вашему сегодняшнему вопросу, в котором вы пытаетесь решать эту задачу дальне вам нужно сделать эту работу на уровне БД.
Если так, то для этого многие (хоть и не все, но, к примеру, в MS SQL Server и в PostgreSQL она AFAIK есть) СУБД имеют функциональность reursive CTE.
Попробуйте поискать решение в этом направлении.

Полагаю, вы хотели подставить между знаками процента значение из поля ввода (txtSearch.Text), которое передается в string.Format? В таком случае надо между фигурным скобками подставить порядковый номер параметра (он начинается с 0): string.Format("%{0}%", txtSearch.Text)

PS Из соображений безопасности (чтобы избежать SQL-инъекции) крайне не рекомендуется напрямую копировать в строку запроса сырые, непроверенные, данные из ввода пользователя - а вы сделали именно так. В учебной задаче это допустимо, но лучше сразу привыкать делать по уму: например, использовать в строке запроса параметры и передавать ввод через них.

Имя_файла.cs ищется относительно вашего текущего каталога - того, в котором вы находились, когда ввели команду с csc.exe. Его имя пишется в приглашении командной строки. Вот и посмотрите, из какого каталога вы запускаете команду, и есть ли там нужный файл.

CityzenUNDEAD, сообщение об ошибке означает, что у вас таки действительно кривые данные, а именно - есть минимум одна запись в RiskLevels со значением поля OrganizationControlId = 0, для которой в таблице OrganizationControl нет записи с таким же значением первичного ключа (как я понял - поля Id).
Вывести все такие записи из RiskLevels, которые ссылаются на отутствующие записи в OrganizationControl, можно SQL-запросом

SELECT * FROM RiskLevels WHERE OrganizationControlId!=ALL(SELECT Id FROM OrganizationControl)

И пока такие записи есть, наложить ограничение внешнего ключа не поле RiskLevels.OrganizationControlId у вас не получится. Ищите и разбирайтесь, что с этими записями делать.

PS Entity Framework - он шибко умный, он сам находит связанные друг с другом поля, сам добавляет поля для чего-нибудь типа первичного ключа и т.д. Так что не удивляйтесь, что EF умничает, а если не хотите этого - жестко его контролируйте.

Не то, чтобы ответ, но идея ответа. И если чо непонятно - могу в каментах поуточнять.
Со стороны тыла (на C#) можно ограничить число параллельных запросов в целом к сервису безо всяких там плагинов, а саморучно сделанным велосипедом: семафором (например, SemaphoreSlim, как самым модным в этом сезоне). Либо сделать его статическим, либо (чтобы веру в IoC свято блюсти и модульные тесты делать) - запихнув в Singleton-сервис с теми же свойствами/методами, что и у семафора используются, и получать этот сервис через конструктор (передавать через DI - в бою, напрямую - в тесте).
Для семафора(сервиса) устанавливаете максимальное число параллельно выполняемых запросов в качестве начального значения. При входе в обработчик захватываете семафор (Wait/WaitAsync, таймаут - по вкусу), при выходе (лучше - в блоке finally того try, который начинается после захвата семафора) - освобождаете (Release).
Таймаут выставляете в зависимости от поведения фронта: какие у него у самого таймауты на запрос (в том числе - на повторение) и как он реагирует на задержку ответа и на всякие разные коды статуса HTTP в ответе. В целом, стратегии тут две. Первая - пытаться захватывать семафор с коротким таймаутом и в случае неудачи - возвращать другой код статуса, кроме ОК, чтобы сказать фронту, что он не прав. Вторая - тормозить лишние запросы таймаутами. Кароче, без знания вашего фронтового плагина тут точно не скажешь, а я его знать не знаю и знать не хочу.