rPman

Закрой проект, открой в текстовом редакторе файл проекта *.csproj (формат xml) и замени название в теге <AssemblyName>....</AssemblyName>

после открытия на всякий случая очисти и пересобери проект (build -> clean)

Подумай хорошенько, где ты собираешься кешировать и как инвалидировать кеш (проверять что данные в кеше устарели), получишь ответ на этот вопрос почти сразу

Второй вопрос очень важный, как запускается код бота, в режиме получил запрос (реакция от пользователя) и завершил процесс либо процесс запускается как сервис и работает в единственном экземпляре (тоже важно, так как бывает что то типа кластера, но явно не твой случай)?

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

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

Вот от сюда и думай, что хранить, где хранить надо ли делать запрос в базу или можно из памяти и т.п.

Как бы ты не изворачивался, либо у тебя получится поддержка только подмножества веб приложений (и очень не эффективное) либо очередной браузер, но зачем, когда есть готовые.

Подключаешь к проекту какой-нибудь браузер, открываешь требуемую ссылку там, мониторишь итог на предмет окончания загрузки (отдельная проблема)...
например штатный компонент .net WebBrowser это древний internetexplorer11 на windows, но при запуске проекта на mono - это будет что то основанное на firefox

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

Например
1. отключаешь display manager - lightdm (или что у тебя там для меню авторизации и выбора DE)
2. минимум что необходимо для работы графического режима - это xserver, для его запуска достаточно запустить утилиту X (кстати кажется до сих пор требует root), будет запущен графический сервер без Desktop Environment, но нужно понимать что DE отвечает за управление окнами, а точнее управление их размерами, положением на экране и вообще сокрытие/минимизация. Т.е. без этого, если твое приложение ожидает что пользователь будет перемещать его окна (а это к примеру диалоговое окно открытия/сохранения файлов) то он уже это сделать не сможет, все окна будут без заголовков и бордюра для изменения их размеров.
И кстати, чтобы графическое приложение запустилось и отображалось на X нужно устанавливать переменную окружения DISPLAY, значение смотреть либо в конфиге X либо в логах (скорее всего будет что то типа :0, это имя сервера и номер xserver, запущенного на нем, напоминаю, что linux из коробки умеет multiseat)
3. чтобы появился хоть какой то интерфейс взаимодействия, нужно установить DE, из минималистичных, идеальных для kiosk mode - я бы рекомендовал awesome, в нем к примеру можно настроить чтобы все открываемые окна сразу разворачивались на весь экран.

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

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

Чтобы запустить xserver с DE автоматически можно либо настроить автозагрузку в lightdm (это правильно) либо просто запускать утилиту startx, которая смотрит в пользовательском каталоге .xinitrc и запускает DE от туда.

На самом деле процесс запуска DE стал очень замудреный, его запутали несколько поколений разработчиков и выпутывать не желают, но обычно все это критично для тяжелых DE типа KDE, а что то простое и легкое с приложениями на gtk работает и так

Собственно как запускать приложения автоматически при включении компьютера тоже вопрос очень интересный, способов много, минимум три могу предложить
* правильный - настроить службу и прописать ей зависимости и автозапуск,
* так же до сих пор есть устаревший способ настройки службы без зависимостей sysvinit - /etc/init.d
* ну еще есть /etc/rc.local

если относительное положение стенок паралельно осям координат (т.е. либо препятствие вертикальное либо горизонтальное) то при ударе о горизонтальную стенку, скорость по Y меняется на противоположную (меняется знак) а по X не меняется, ну а при горизонтальной стенке наоборот, по Y не меняется а по X меняется знак на противоположный (умножить на -1)

если препятствия произвольный угол имеют то... формулы можешь посмотреть тут

c# в данном случае не самый лучший выбор (правильно использовать c++ или c или лучше готовый фреймворк и язык - autoit но он в стагнации уже давно), в .net нет необходимого api и все придется импортировать из win32
вот обсуждают простейший пример симуляции движения мышкой, там же смотри как импортировать библиотеку

чтобы получить базовую информацию о графической структуре окон требуемых приложений (а все они так или иначе будут использовать хотя бы одно win32 окно), используй штатную утилиту, идущую в поставке с visual studio - microsoft spy++ (даже если нет ярлыков, утилита spyxx.exe лежит в каталоге visual studio... tools)

2 варианта
правильный сложный - гуглить: stream xml parser c#
первый же результат

второй простой и тупой - если тег organization это один из элементов огромного списка и файл отформатирован (а это можно сделать другими средствами потоково, например консольным редактором регуляркой sed, вставив переводы на новую строку после закрытия тега organisation или же в своей программе) то можно быстрыми средствами поиском подстроки или построчной загрузкой файла грузить каждую organization в свою строку и анализировать уже привычными не потоковыми парсерами

не понятна цель перевода универсального кода на основе потоков к асинхронному коду, чья нормальная работа допускается с кучей оговорок.
может лучше оставить как есть?

По коду видно что в внутри потока реализован свой event loop, это хорошо, значит работа уже разделена на кусочки
таким образом тебе осталось эти кусочки важной работы раскидать на события (т.е. к примеру вызов каждого нового кусочка - новое событие, значит нужно сформулировать условие создание следующего события, например если это просто 'вычисления' то по очереди создаешь события для куска работы от каждого потока, чтобы они по очереди выполнялись)