MVV

Дошёл до более менее адекватной ошибки, это указав ObjectName \\Domain\User 555555, получаю

Попробуйте Domain\User, имя пользователя часто указывается так. Domain тут - имя домена AD, в котором существует пользователь - при условии что компьютер включен в этот домен или в домен, который доверяет этому. Если компьютер не в домене или пользователь - локальный, то вместо имени домена указывается имя компьютера.

SomethingFuncCatch().Wait();
В Wait дополнительно можно передать таймаут и/или CancellationToken (см. описание метода Task.Wait ).

Только вот, боюсь, что вы не дождетесь когда закончится цикл

while (i > 0)
{
    Console.WriteLine("NewProcess started");
    i = i--;
}

Ибо вы в нем пытаетесь присвоить i то значение, которое было до уменьшения на 1.

Вынесено из комментариев.
Василий Банников , ну, что вам на это сказать?

Сильно легче код писать таким образом.

Писать - да, читать - it depends, как говорят англичане.

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

А разве в legacy 4-5-летней выдержки, над которым поработало много программистов, хороших и разных, по-другому бывает? А ещё имена могут дать хорошие, понятные - но основанные на системе понятий, которая нетривиальна и не попала при этом в документацию. Чтобы понять, о чем я - попробуйте почитать исходники подсистемы маршрутизации в ASP.NET Core. лучше всего - после работы с чем-нибудь типа MVC или Razor Pages: сомневаюсь, что вы сразу въедете, что Model там и Model тут - это разные Model.

А ещё бывает, что методы называются почти одинаково, но типы значений у них разные. Пример: builder.Services.AddOptions() и builder.Services.AddOptions<TOptions>() из кода конфигурирования контейнера сервисов, методы расширения IServiceCollection для Option Patterns - типы возвращаемых значений у них разные. А их ещё любят цеплять друг к другу к таким же методам через точку - вот и смотри потом, чой-то в ConfigureOptions какие-то лишние параметры вылезли.

с анонимными типами без var работать было бы очень сложно.

Правильный вопрос - зачем вообще заставлять работать с анонимными типами? Подозреваю, что их из-за маршрутизации в MVC завезли - как типы параметров, вместо того, чтобы передавать в методы генерации ссылок вместо IDictionary<String,Object>, как это оно там реально требуется. Но, в Microsoft решили, видимо, тогда не делать инициализаторы для словарей (при том, что потом всё равно сделали, не отвертелись), а притащить вместо них анонимные типы (интересно откуда - неужели прямо из JS?). Но это не точно. (Ага, в комментарии мне напомнили про LINQ)

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

Это потому что сейчас главное - быстрее писать MVP, для веба - особенно. Ну, а потом можно сказать волшебное слово: "Legacy".

Ну и помни ещё, что ты же не в блокноте код пишешь

Но читаешь-то ты его не только в IDE. В частности, MS в своей документации на сайте в примерах очень любит писать var - вот и выбирай потом, что делать: лезть прямо сразу в документацию по API (а ссылки отнюдь не прилагаются) или рисковать упустить что-то важное? А если ещё учесть, что сейчас принято документацию ограничивать примерами (MS любит, да) - оно вообще весело.

Но, с другой стороны, автор вопроса, похоже, с трех- и более этажными дженериками ещё не сталкивался (ну, или забыл, как они выглядят) - там без var тоже грустно.
Как-то так

Отмены задач используются, как ни странно, для отмены задач. А чтобы отменить задачу, это должно быть кому-нидуь нужно. Например, этим "кем-нибудь" часто бывает пользователь, которому результат задачи перестал быть нужным.

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

А ещё отмена полезна для прерывания процессов потенциально бесконечных, типа смотреть, как горит огонь, как течет вода, как люди работают... :-)

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

Вы неправильно используете метод ControllerBase.Forbid. Передаваемая в него строка (она, как понимаю, преобразуется в массив строк из одного элемента) - это не сообщение об ошибке, а название использованного метода аутентификации.

Сделайте фабрику для экземпляра, реализующего кэш, и передавайте через конструктор её, в виде интерфейса. Тогда кэш у вас будет частным, действующим только внутри класса, но конкретная его реализация будет задаватьс снаружи. И все будет по фэн-шуюSOLID
Для теста передайте в конструктор имитатор ("мок") этой фабрики, который создает и возвращаетнужный вам имитатор кэша.

PS Стндартная для .NET имплементация кэша в памяти - это MemoryCache, он реализует интерфейс IMemoryCache. Только вот самому его имитировать нетривиально, поскольку у него есть особенность в поведении: его элемент (ICacheEntry) сохраняется в кэше по факту очистки (вызову Dispose() ). Я про это даже статью на Хабре написал.

Простейший вариант: копируйте (синхронно) в обработчике нажатия кнопки данные, которые вы сохраняете, в другое место, а там пользователь пусть хоть обизменяется: на сохраняемые данные это уже не повлияет. Если данных вдруг много, то тогда уже придется синхронизировать доступ к ним (для асинхронной синхронизации подходит SemaphoreSlim.WaitAsync/Release, а если вы можете позволить себе блокировку потока UI, то и lock сойдет). Есть и более сложные схемы - копировать только те данные, которые пользователь собрался изменить, и сохранять в таком случае именно их, а не данные из ViewModel ("копирование при записи"). Короче, дерзайте: вариантов много.
Ну, а вариант с ползунком сам по себе ненадежен: пользователю доверять нельзя. Но как подспорье, вместе с блокировкой изменения - годится.

Неправильный шлюз по умолчанию прилетает вам по DHCP на следующий интерфейс: Ethernet adapter VMware Network Adapter VMnet8. Его создает VMware WorkStation, а используется он в настройках по умолчанию для выхода наружу через NAT виртуалок подсоединенных к соотвествующей сети.
Т.к. я не знаю, для чего у вас на ПК используется VMWare (и используется ли вообще - у вас там вообще всё интересно: я вижу ещё следы VirtualBox и Hyper-V), то точно сказать, что вам надо сделать, я не могу. Но, как минимум, можно в Virtual Network Editor отключить DHCP на нем - а если у вас в этой виртуальной ести еесть виртуалки - настроить на них адрес IP вручную.