Что может повлиять на размер билда в Azure
Что проверяют
Знаете ли вы, из чего состоит артефакт публикации дотнета и какие переключатели сборки на него влияют. Вопрос практический: размер пакета определяет время выката, холодный старт функции и то, влезает ли приложение в квоту.
Как отвечать
Разделите факторы на три слоя.
Режим публикации. Зависимое от фреймворка приложение берёт рантайм с хоста и весит мало, автономное тащит рантайм с собой и прибавляет десятки мегабайт. Дальше идут PublishTrimmed, который выбрасывает неиспользуемые сборки, PublishSingleFile, PublishReadyToRun, который наоборот увеличивает файл ради быстрого старта, и Native AOT для сценариев без рефлексии.
Содержимое проекта. Число пакетов и их транзитивные зависимости, сателлитные сборки локализации, файлы отладочных символов, конфигурация Debug вместо Release, статика вместе с картами исходников, случайно попавшие в вывод файлы с включённым копированием.
Упаковка и доставка. Для контейнера решают базовый образ и наличие .dockerignore: без него в образ уезжают исходники, кэш пакетов и каталоги сборки. Для пайплайна важно публиковать результат dotnet publish, а не весь каталог сборки целиком.
Полезно закончить тем, как вы это меряете: сравнить каталог публикации до и после, посмотреть на самые тяжёлые файлы, и только потом решать.
Где спотыкаются
Путают размер репозитория и размер артефакта. Разговор уходит в чистку решения, хотя вес дают рантайм, пакеты и статика, а увидеть это можно за минуту, опубликовав проект локально.
Включают обрезку или AOT ради цифры и ломают прод. Рефлексия, сериализация без генератора кода и регистрация зависимостей сканированием сборок перестают работать, причём сборка выдаёт только предупреждения, а падение случается на первом же запросе.
Называют режим Release минификацией. Минификация это про скрипты и стили в браузере, а Release меняет оптимизацию и отладочную информацию. Сюда же попытка списать всё на сам сервис сборки: инструмент пайплайна размера артефакта не меняет.