Delakey Blackhole, нет, не логичнее.
1. даже если программа на линуксе потребляет 200мб, а на винде 11 (что не правда), то с учётом памяти, которая требуется для работы ядра, на линуксе ты сможешь запустить порядка 10 экземпляров за ту же память, которая требуется для работы пустой винды.
2. Покажи подробнее вывод потребляемой памяти на линуксе. Что означает число 134820?
3. Попробуй ещё снять метрики по размеру кучи и сколько в ней занято. Может на Linux сразу было выделено много памяти на будущее?
4. Попробуй запустить приложение в виндовом контейнере
inessa_isakovsky, ну у виртуалки есть вполне очевидные плюсы: легко можно бэкапить и восстанавливать из образа. Не нужно будет по 10 раз переустанавливать для отработки траблшутинга.
Из минусов - только то что там не будет полноценной видеокарты и будет чуть сложнее траблшутить такие кейсы.
А какие альтернативы? Не готовиться совсем? Готовься не в virtual box?
Мак лучше полноценный приобрести, тк у версии на виртуалке и хакинтоше будут свои нюансы
Popou, асинхронность - это не обязательно таски)
И таски/async-await не обязательно на нескольких потоках)
Корутины через IEnumerable - это такой вот вариант реализации асинхронности.
При этом их сравнительно легко можно преобразовать в async-await синтаксис, благодаря тому что async-await работает не только с Task: https://github.com/Cysharp/UniTask
Сергей, в случае консольного - обычное консольное dotnet new console
В случае веба, когда ты хочешь отвечать на http-запросы - бери шаблон с aspnet: dotnet new web или dotnet new webapi
Kentavr16, ну варианта два:
1. Упаковать в deb/rpm/что там у тебя пакет и указать в зависимостях dotnet runtime - он скачается при установке.
2. То же самое, но уже с flatpak
3. Собирать с опцией --self-contained + Добавить assembly trimming и aot, чтобы консольное приложение на 2кб не превратилось в 20мб
pfg21, вариант 3 - это и есть EDI. Всякие накладные, заказы на поставку, приёмка товара, и прочее - через него, а юридически значимые документы - через обычный ЭДО (и там тоже есть машиночитаемые форматы)
Искренне не считаю докер за сложное решение.
Если у автора будет что-то более сложное, чем 1 сервис + nginx на одной машине, то и кубер и докер окажутся вполне себе оправданными.
А корректный WebUI вполне себе может быть удобным, если правильно сделал.
Например в одной компании, где я раньше работал, как раз был свой сервис для удобного деплоя с web-интерфейсом.
Нужно было просто упаковать в nuget-пакет своё приложение, а далее drag-n-drop в браузер и ввод некоторых настроек, всё остальное - это уже магия, которая очень сложно работает внутри (там и балансеры настраиваются, и реплики поднимаются, и записи в DNS-создаются, и прочее и прочее.