Comments 4
Почему не использовать публикацию в NativeAot? Тогда зависимость от рантайма не понадобиться.
Верно. Тогда не будет одной зависимости. Хорошее замечание.
Но, при установке, она подтянется сама, если ее нет. Вопрос только дискового пространства.
В реальной разработке в командах Aot использовался только в рамках эксперимента. Полноценного перехода нет и не планируется. Потому в статье в эту сторону не думал.
Но, при установке, она подтянется сама, если ее нет. Вопрос только дискового пространства.
Кто подтянется сам? При публикации NativeAot Вы получите собранный платформо-специфичный бинарь внутри которого будет затримленный рантайм. Для запуска такого приложения не требуется ничего подтягивать, для него будут нужны только системные зависимости но рантайм уже не потребуется.
Кто подтянется сам?
Если в ОС не будет dotnet-8.0, то он подтянется при установке пакета.
Стоит ли в реальной разработке собирать приложение под NativeAot? Вопрос, не имеющий для меня однозначного ответа:
Будет ли работать быстрее? Да будет. Но не каждое приложение необходимо оптимизировать. То, под которое проводилось исследование - точно нет. Это время команды и деньги бизнеса.
Будут ли непредвиденные проблемы, которые могут сдвинуть сроки, или потратить ресурсы? Не уверен, но возможно.
В реальной жизни внедрение NativeAot при разработке решения упрется в сроки, риски и косты, без наличия решающих преимуществ.
Но, повторюсь. Ваш комментарий хорош. Так тоже можно. Для туториала интереснее вариант с зависимостью - предлагаю так и оставить.
Формирование RPM пакета для OC Linux с использованием GitLab CI/CD (часть 2)