MVV

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 в ответе. В целом, стратегии тут две. Первая - пытаться захватывать семафор с коротким таймаутом и в случае неудачи - возвращать другой код статуса, кроме ОК, чтобы сказать фронту, что он не прав. Вторая - тормозить лишние запросы таймаутами. Кароче, без знания вашего фронтового плагина тут точно не скажешь, а я его знать не знаю и знать не хочу.

1. Сразу насчет микросервисов: оно, конечно, стильно-модно-модожежно, но для начала ознакомьтесь со свежим переводом недавней статьи на Хабре "Смерть от тысячи микросервисов" и задумайтесь: а у вас там точно требуется такой уровень гибкости, масштабирования и т.п., что без микросервисов никак. Задуматься стоит IMHO - выбор неоднозначный, и за вас его никто не сделает.
2. Если вы знакомы с MVC и кго контроллерами, то вам будет несложно писать контролеры API на ASP.NET Core в старом добром стиле: традиционно они тоже базируются на инфраструктуре MVC. Там почти та же логика привязки параметров: ну, разве что, там стало автоматическим преобразование объектов на JSON из тела запроса в параметр-объект, но, вроде бы, можно использовать и старый стиль с несколькими параметрами с привязкой их одноименным свойствам объекта. Там используется та же самая маршрутизация по атрибутам - она должна быть вам знакома, если только вы не застряли в legacy времен MVC Framework 4, где была только центральная маршрутизация. Ну а возвращаемые объекты ASP.NET Core сам автоматически преобразует в JSON.
Правда, начиная с ASP.NET 6 появился (а начиная с ASP.NET 7 стал нормально документированым) альтернативный вариант создания API - Minimal API, но раз у вас есть опыт работы с MVC, то наверное, вам лучше остаться с этим старым добрым вариантом.
Насчет формата обмена - вызовов и результатов API - у вас полная свобода, но имейте в виду, что при использовании REST вы получите автоматизированню поддержку описания этих форматов через OpenAPI/Swagger: фронтовики с мобильщиками это оценят.
Делать ли генерацию HTML для браузера на веб-сервере через View по шаблонам Razor или же поручить эту работу фронтовикам, снабжая их данными через API - это предмет выбора, это зависит: как там у вас с квалификацией фронтовых разработчиков, как с требованиями к интерактивности страницы в браузере (MVC этому не способствует, костыли для подключения фронтовых фреймворков у MS, вроде как, есть, но я за них ничего не скажу - не пользовался), не придется ли по соображениям производительности переходить к Server Side Rendering (View - они как раз про это, а если изначально HTML генирился на фронте то перенести его в ASP.NET будет сложно) и т.п.
Авторизацация в ASP.NET Core есть из коробки, самых разных видов: часть уже встроена, для части придется подключать сторонние NuGet-пакеты, но подробности я вам тут не опишу.
А в общем совет у меня такой: собирайте информацию и думайте сами, а попытки копировать "как у других" - они могут привести к совершенно неожиданным результатам: каждая задача в чем-то уникальна.

Работа фонового сервиса у вас прекращается потому что у его метод ExecuteAsync дожидается инициализации статической переменной WebView (она содержит ChromiumWebBrowser, открытый на странице https://web.watsapp.com) а потом ничего не ждет, а просто завершается. А что там у вас происходит с браузером, код вашего фонового сервиса не контролирует.
PS Я не вижу ваш остальной код, но могу предположить, что вам для работы программы этот фоновый сервис не нужен, т.к. вся работа с экземпляром CefSharp идет через упомянутую статическую переменную.