Василий Банников

Был один вариант, который выдавал мне в итоге ::1 (httpContextAccessor.HttpContext.Connection.RemoteIpAddress) , верно ли это?

Да, если ты запрашивал с локалхоста на локалхост.

Я в этом сомневаюсь, ибо через класс Dns я получал более развёрнутую информацию об IP адресах (Dns.GetHostEntry(Dns.GetHostName()).AddressList())

А при чём тут DNS?

Использовать битовые маски не хотелось бы.

А вот только их и остаётся использовать.

2. Не избыточна ли тут ConcurrentQueue?

Вместо неё лучше использовать System.Threading.Channels (https://www.stevejgordon.co.uk/an-introduction-to-...)

3. Как сообщить основному потоку из Task.run() что все готово к обновлению карт? Я понимаю что есть Task.Result, но если Task выполняется постоянно (while true), смогу ли я это использовать?

При помощи канала.
А Task.Result испольщовать не следует

В остальном всё звучит правдоподобно

Нет, такое не происходит, тк размер объектов просто не может меняться в процессе работы.
Объект либо сразу большой, либо сразу не большой

Single File Application - фича современных дотнетов со времён .net Core 3
Буквально при помощи одной опции в файле проекта или одной строкой в консоли собирает ваш проект в единый екзешник, в который ещё может быть опционально встроен рантайм.
Вот пример csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <PropertyGroup>
    <!-- Вот это самое главное -->
    <PublishSingleFile>true</PublishSingleFile>
    <!-- Это чтобы тащить за собой рантайм До .NET 6 будут рядом лежать нативные библиотеки jit-а и сборщика мусора-->
    <SelfContained>true</SelfContained>
    <!-- Это необходимо, чтобы сборщик понимал, для какой ОС нужен экзешник -->
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <!-- Это чтобы ускорить запуск -->
    <PublishReadyToRun>true</PublishReadyToRun>
    <!-- Эти две строки, чтобы уменьшить размер бинарника -->
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>link</TrimMode>
  </PropertyGroup>
</Project>

В результате получается единственный exe, который реально можно запустить где угодно, вне зависимости от установленной версии .NET

Для старых версий дотнета есть ILMerge и Costura.Fody, но в .net 5+ они не нужны, и я крайне советую использовать именно .NET 8, тк он сейчас самый актуальный

Ну во-первых точно не получится использовать стандартный Bitmap.
Хранить в куче такой большой объект тоже не следует, тк он 100% попадёт в LOH
+ в .NET есть ограничение в 2гб на объекты в управляемой куче.
Описанное вами изображение как раз в этот лимит и не влезет.

Остаётся два с половиной варианта:
1. Делить огромное изображение на чанки по меньше (либо по пикселям, либо по каналам, либо и так и так)
2. Хранить изображение в неуправляемой памяти, выделять и освобождать память вручную.
В .net 6 как раз добавили Native alloc API для этого.
3. Возможно есть какая-нибудь нативная библиотека для работы с большими изображениями.
Возможно даже уже есть обёртка для работы с ней.

Во всех случаях придётся отказаться от Bitmap и использовать другие подходы

без доп. библиотек и массива битмапов

Не получится

То этот самый хост, запустится в отдельном фоновом-процессе? То есть, процесс консольного приложения отдельно, а процесс-хоста - отдельно?

Нет. Он будет запущен в этом же процессе.

PS: не забывайте писать await возле вызовов асинхронных методов

Xamarin.Native не заменит
Xamarin.Forms заменит (тк это но и есть)
WPF не заменит (но это не точно)

Ну и не надо смотреть только на майков - есть и другие кроссплатформенные UI - например Avalonia или Uno

1. Небольшая экономия, за счёт того что не нужно длинный запрос по сети передавать, а только короткий вызов процедуры (относительно)
2. В плане защищённости разницы нет, если злоумышленник имеет доступ к исполняемому файлу/исходнику.
3. Из потенциальных удобств - можно менять запрос, не затрагивая приложение.

Так что выбирай тот способ, который в твоём случае более оправдан.

tl;dr; Чтобы дать интерфейс для явного освобождение какого-нибудь ресурса, как правило - неуправляемого.
Цитата из документации

В основном этот интерфейс используется для высвобождения неуправляемых ресурсов. Сборщик мусора автоматически освобождает память, выделенную управляемому объекту, если этот объект больше не используется. Однако невозможно предсказать, когда произойдет сборка мусора. Более того, сборщик мусора не имеет сведений о неуправляемых ресурсах, таких как дескрипторы окон, или открытых файлах и потоках.
Используйте Dispose метод этого интерфейса для явного освобождения неуправляемых ресурсов в сочетании с сборщиком мусора. Потребитель объекта может вызвать этот метод, если объект больше не нужен.