MVV

Условный оператор в возвращаемом выражении в лямбде в GroupBy формально имеет тип результата int?, и у ситаксического анализатора при выводе типа возвращаемого значения не хватило то ли мозгов догадаться, что результат не может быть null, то ли полномочий изменить тип возвращаемого выражения на int.
Упростите ему задачу: используйте операцию объединения с null (?? - null-coalescing), тип ее результата гарантированно не-nullable:

asd.Value?.GroupBy(x => x.ParentId??0 ).ToDictionary(gg => gg.Key, gg => gg.ToList());

CancellationToken, передаваемый коструктору Task, не имеет никакого отношения к делегату, составляющему тело задачи (у вас им является ваша лямбда-функция). Он служит для отмены самой задачи, пока она ещё не запущена на выполнение. А делегат тела задачи даже не может просто взять и обратиться к этому CancellationToken. И, чтобы делегат мог с ним работать, этот CancellationToken надо передать делегату каким-то другим образом.
Вы передаете этот CancellationToken через замыкание лямбда-функции (это умное слово означает, что вы просто сослались в ней на эту переменную). Причем, вы его передаете в тело и той, и другой задачи, через одну и ту же переменную token. Именно поэтому при вызове Cancel() для источника этого CancellationToken (cancelTokenSource) обе задачи обнаруживают этот факт и прекращают свое выполнение.
PS Если интересует, где про это прочитать побольше, то - в книге Дж.Рихтера "Программирование на платформе Microsoft .NET Framework 4.5 на языке Csharp, CLR via Csharp" в гл.27 (в более новом издании, если такое есть, номер главы может измениться).

Если вы, как у вас написано, передаете название страны и города через путь в URL, то параметры метода Action для URL второго формата должен привязываться к переменной маршрутизации, примерно так:

[HttpGet("{country}/{city}")]
public IActionResult ActionMethod([FromRoute] String country, [FromRoute] String city) 
{
  //... method code
}

[FromRoute] можно и не писать, если параметров запроса (то, что после '?' в URL) нет: привязка по умолчанию выберет следующим источником переменные маршрутизации.
PS Можно обойтись одним методом действия (Action), если указать что city - параметр необязательный

[HttpGet("{country}/{city?}")]
public IActionResult ActionMethod([FromRoute] String country, [FromRoute] String? city) 
{
 if(city==null) {
  //... method 1 code 
 }
 else {
  //... method 2 code 
 }
}

Поток повторно запустить нельзя. После th1.join() (этот вызов дожидается завершения потока) cоздайте новый поток, присвойте его нужной переменой - да хоть той же th1 - и запустите его: будет функциональный аналог Task.ContinueWith(). Или же запустите th2, который у вас уже создан, но не запущен.
Если вы хотите сделать два вызова Print в одном потоке - сделайте. Если между первым и вторым вызовом надо выполнить какой-нибудь код в основном потоке, то придется использовать объекты синхронизации, в данном случае - события, и ждать на них. Про это курите тему ManualResetEvent/AutoResetEvent, в двух словах в ответе всю эту тему не объяснить

//...declarations and initializations omitted
           do
           {
               //...some code omitted
               if (j != i)
               {
                   swap(i, j);
                   i = j; 
               }
           } while (j != i);

Не работает, потому что вы сначала присваете j значение i, если они не равны, а потом, в условии продолжения цикла, сравниваете их значения. Естественно, они будут равны и выход их цикла получится на первой же итерации. Проверять i==j как условие выхода из цикла надо чуть раньше, например, так:

//...declarations and initializations omitted
           do
           {
               //...some code omitted
               if (j != i)
               {
                   swap(i, j);
                   i = j; 
               }
               else break;
           } while (true);

Ну, а что до второго вопроса, то в .NET, начиная с 6.0 есть класс System.Collections.Generic.PriorityQueue<TElement,...

Естественно не можете, потому что ServiceResult у вас IEnumerable не реализует (про это написано в сообщении об ошибке). А IEnumerable, по которому можно пройтись - это параметр-тип для ServiceResult, и до значения этого типа еще надо добраться.
Разберитесь, что это у вас за обобщенный тип - ServiceResult (похоже, это из какой-то сторонней библиотеки), найдите в нем свойство типа T (или метод, возвращающий T) - который тип T в вашем случае - это IEnumerable - и пройдитесь циклом foreach по значению этого свойства (или результату, возвращенному методом).
PS Если не найдете - дайте больше информации по используемым библиотекам (пакетам NuGet и т.п.), иначе придется вам ждать телепатов или ясновидящих, чтобы они эту информацию нам передали.

Во-первых, ваш заголовок вводит в заплуждение: в нем - про завершение процесса, а справшиваете вы про завешение задачи.
Во-вторых, задача может завершаться переходом в разные конечные состояния (они фиксируются в поле Task.Status). По оператору Return задача переходит в состояние RanToCompletion, по ThrowIfCancelationRequested - Canceled. Это - два логически разных состояния завершения (есть еще и третье - завершение по необработанному исключению, Faulted). Если коду, создаывшему задачу, совсем без разницы, как именно завершилась задача и вообще, завершилась ли она, то можете делать как угодно.
Но, очень часто код, связанной с задачей,к примеру, операция await для задачи, ведет себя по-разному, в зависимости от состояния завершения задачи, получение результата задачи - тоже. А для задачи продолжения можно задать условия, при каком состоянии завершения предыдущей задачи эта задача продолжения будет запущена. То есть, состояние завершения задачи обычно имеет значение.

В .NET есть стандартный класс System.Uri
Посмотрите, может вам хватит его возможностей?

Вынесите описания переменных наверх, над swicth.

int PlayerDamage ;
int PlayerHealth;
int PlayerResist ;

 switch(characterChoose)
 {
     case 0:
         PlayerDamage = 50;
         PlayerHealth = 150;
         PlayerResist = 25;
         break;
     case 1:
         PlayerDamage = 75;
         PlayerHealth = 125;
         PlayerResist = 15;
         break;

 }

PS Согласен с предыдущим комментатором - инциализация через оператор switch выглядит тяжеловесно. В нынешнем C# можно записать то же самое сильно короче, через деконструкцию, например.
PPS Держите пример с вашеми данными, как это должно выгдядеть стильно-модно-молодежно:

int characterChoose = Convert.ToInt32(Console.ReadLine());
(int PlayerDamage, int PlayerHealth , int PlayerResist)=characterChoose switch
{
    0 => (50, 150, 25),
    1 => (75, 125, 15),
   //... дописать все остальные варианты
} ;

Браузеру надо сообщить, что настройки изменились парой вызовов процедуры InternetSetOption из WinInet.dll. Вызывать надо через P/Invoke На stackoverflow нашел пример, как это делать в Powershell.

function Refresh-System
{
  $signature = @'
[DllImport("wininet.dll", SetLastError = true, CharSet=CharSet.Auto)]
public static extern bool InternetSetOption(IntPtr hInternet, int dwOption, IntPtr lpBuffer, int dwBufferLength);
'@

$INTERNET_OPTION_SETTINGS_CHANGED   = 39
$INTERNET_OPTION_REFRESH            = 37
$type = Add-Type -MemberDefinition $signature -Name wininet -Namespace pinvoke -PassThru
$a = $type::InternetSetOption(0, $INTERNET_OPTION_SETTINGS_CHANGED, 0, 0)
$b = $type::InternetSetOption(0, $INTERNET_OPTION_REFRESH, 0, 0)
return $a -and $b
}

Адаптируйте этот код к C# (пояснение: Add-Type в PS служит для загрузки сборки или неуправляемой DLL ). Или поищите по имени этой процедуры код на C#.

Используйте LINQ:
Если поле code в типе, получаемом после десериализации имеет тип int (по уму должно быть так, но я с NewtonSoft JSON не работал, поэтому не уверен в таких подробностях), просто допишите к выражению для десериализации
.Select(x=>x.code).ToArray();
Если тип, паче чаяния, другой - преобразуйте результат, возвращаемый лямбда-функцией в Select к int (для строки это будет Int32.Parse(x.code)

Думаю, что надо раскрыть подробнее тему предыдущих ответов и комментариев.
Проблемы со сложностью у вас, потому что вы не используете современые средства .NET и C#.
В .NET исторически сложилось несколько слоев API для обеспечения параллельной работы, и использование функций обратного выдова - самый старый и самый громздкий из них. А самый удобный и современный - это Task Parallel Library (TPL): он, плюс конструкции языка C# async/await, позволяет писать такой асинхронно выполняющийся код так, будто он выполняется синхронно.
Скорее всего (я просто не уточнял, потому пишу так) для SQLite есть асинхронный API и для использования с TPL, и API для синхронного использования, что ещё удобнее - и он должен быть не менее быстрым чем синхронная работа с файлами, потому что это встроенная БД.
Но если вы по каким-то причинам будете работать с асинхронным API на функциях обратного вызова, то тут тоже есть способ упростить код: транслировать вызовы такого API для использования его со средствами TPL. Для этого используйте объект типа TaskCompletionSource (в вашем случае - обобщенный, специалиированный вашим типом результата: TaskCompletionSource<int>
У этого объекта есть свойство Task, возвращающее задачу, состоянием котрой можно управлять с помощью методов этого объекта - SetResult и других, вызывая эти методы в функциях обратного вызова (AKA callback). Как это делать - см. пример по ссылке.
А с Task, каким бы способом вы его не получили, вам будет работать значительно удобнее: если пометить метод, в котором вам надо работать с БД как async (в современном C# так можно пометить даже Program.Main), то в этом методе можно будет использовать для получения значения операцию await

TaskCompletionSource<int> tcs1=new TaskCompletionSource();
//... операции по по настройке tcs1 и запуску первого чтения из БД
int numberFromBase1 = await tcs1.Task.ConfigureAwait(false);
TaskCompletionSource<int> tcs2=new TaskCompletionSource();
//... операции по по настройке tcs2 и запуску второго чтения из БД
int numberFromBase2 = await tcs2.Task.ConfigureAwait(false);
int summ =  numberFromBase1 + numberFromBase2;
return summ;

Вызов ConfigureAwait(false) здесь нужен для избежания блокировок в некоторых контекстах синхронизации (приложения Windows Forms, WPF и др.). Если же у вас программа выполняется вне специфического контекста синхронизации - консольное приложение, приложение ASP.NET Core и др., - то этот вызов не обязателен.
Компилятор, увидев операцию await, преобразует метод нужным образом, так, чтобы он выполнялся асинхронно, передавая управление другим задачам во время ожидания (т.е. до выполнения функции обратного вызова) и возобнавлял выполнение по его завершении -и вам думать об этом и писать нужный для этого код будет не нужно.
Такой метод вернет Task (возможно - ещё до завершения всех операций) и с его результатом можно что-то сделать: либо получить его опять чере await асинхронно, либо дождаться завершения асинхронных операций с получением результата через вызов метода Task<int&gt.GetAwaiter().GetResult() (есть другие варианты, но этот IMHO лучше всего в плане обработки исключений).

Мое мнение: есть некоторая неопределенность для ответа. С одной стороны, при решении типовых задач с помощью базирующихся на ASP.NET Core фреймворках высокого уровня - MVC, Razor, Minimal API, Blazor (за последний не совсем уверен, правда), с асинхронностью и многопоточностью вы сталкиваться будете не сильно и не часто, потому что в них приложены усилия, чтобы изолировать разработчика от связанных с этим трудностей - короче, потребуется разве что, умение использовать async/await. Но в целом ASP.NET Core - это фреймворк асинхронный и многопоточный, поэтому для более плотной работы с ним понимание асинхронность и многопоточность и связанные с ней знания (например, про примитивы синхронизации, состояние гонок и т.п.) может быть полезно, иногда - например, если вы захотите использовать объекты, к которым возможен доступ из нескольких веб-запросов параллельно - просто необходимо.
Короче, мое мнение: начинать изучать перечисленные фреймворки высокого уровня можно и без особых знаний про асинхронность, достаточно научиться использовать await в async-методах (это просто). Но в дальнейшем тему асинхронности и многопоточности надо вкурить, чтобы можно было работать смелее и свободнее, выходя за рамки фрейворка, и не допускать при этом труднообнаружимых ошибок.

если я не хочу создавать переменную

А вы её и так, и так не создаете: экземпляр исключения создается при возбуждении исключения (помните синтаксис - throw new Exception() )? А вот чтобы обратиться к полям/свойствам/методам этого экземпляра, надо дать ему имя в конструкции catch и обращаться к нему по этому имени. А при указании в качестве имени экземпляра имени класса, вы, как выше вам написал Василий Банников , как и в любом другом месте, обращаетесь к статическому полю (или свойству) этого класса. Такой вот синтаксис у языка C#: обработчик исключения у него - это обычный блок, никаких специальных соглашений там нет( пока что, по крайне мере ;-) ).

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

Если надо один раз: правой кнопкой мыши на нужный проект -> Debug -> Start New Instance
Если надо изменить на постоянку: правой кнопкой мыши на нужный проект -> Configure Startup Project...
или Меню->Project->Startup Project...
Предполагается, что все эти проекты входят в одно Решение (Solution)