Ну и заголовок — язык «сломаешь»… Но как бы там ни было — тема важная и нужная. На платформе dotnet в файле проекта доступны 3 свойства для версионирования:
- VersionPrefix — семантический номер версии в формате
major.minor.patch. По умолчанию 1.0.0. - VersionSuffix — буквенно-числовая метка версии перед выпуском, например alpha, beta, rc1 и т.п.
- Version — всё вышеперечисленное вместе в формате VersionPrefix[-VersionSuffix]. Другими словами: указывать можно либо только VersionPrefix, либо VersionPrefix и VersionSuffix, либо только Version в формате major.minor.patch[-prerelease].
К сожалению я не нашёл отдельной страницы с документацией посвящённой трём вышеописанным свойствам. Но на просторах интернета по этой теме есть ответ Nate McMaster‘а на stackoverflow, или статья Andrew Lock — Version vs VersionSuffix vs PackageVersion: What do they all mean?
Если вышеописанные свойства проекта определены, то они определят значения следующих атрибутов сборки при построении:
- AssemblyVersion — версия сборки в формате
major.minor.patch.build - FileVersion — версия файла сборки отображаемая в свойствах файла проводника. Обычно совпадает с AssemblyVersion.
- InformationalVersion — дополнительные сведения о сборке в произвольном формате.
- PackageVersion — версия пакета NuGet создаваемая при построении пакета при помощи команды
dotnet pack. Обычно совпадает с Version.
Отмечу также, что вышеописанные атрибуты могут быть указаны явно, как свойства проекта. Вообще у проекта очень много свойств, но как было указано выше — я не нашёл полного списка где-то в документации. Однако есть другой способ: открыть файл проекта в VisualStudio и начать добавление нового свойства со знака < — тогда студия выведет список автоподстановки и контекстную подсказку.
При построении с помощью утилиты MSBuild любое свойство проекта может быть переопределено . Для этого используется параметр -property:name=value или короткий вариант -p:name=value. Упоминание об этом сделано потому, что команда dotnet build использует MSBuild для сборки проекта. При этом помимо собственных параметров dotnet build также принимает параметры MSBuild. Это позволяет задавать некоторые свойства проекта во время сборки в командной строке или при использовании подхода непрерывной интеграции. Сюда же относится команда RUN dotnet build внутри Dockerfile’а . Нужно лишь определить переменные времени сборки с помощью инструкции ARG. Например:
FROM build AS publish ARG Version RUN dotnet publish ...
Обращаю ваше внимание, что последние версии Dockerfile’а созданные в VS через контекстное меню используют многоэтапную сборку из четырех раздельных именованных этапов. Переменные, объявленные с помощью инструкции ARG, имеют область видимости только внутри того этапа, в котором объявлены. Если необходимо использовать значение одной и той же переменной в нескольких этапах, то каждый этап должен объявлять переменную заново.
Теперь касательно команды RUN dotnet: в Dockerfile’е эта команда используется трижды для разделения этапов восстановления пакетов, сборки и публикации, несмотря на то, что можно было бы обойтись всего лишь одной командой. В «интернетах» бытует мнение, что это сделано для кеширования результатов и последующего переиспользования. Ладно — пусть будет. Важно лишь понимать, что вместе с дублированием объявления переменной с номером версии придётся также дублировать использование этого параметра в командах dotnet build и dotnet publish. Ниже пример объявления и использования переменной Version:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build WORKDIR /src COPY ["Имя-проекта.csproj", "Каталог"] RUN dotnet restore "Имя-проекта.csproj" COPY . . WORKDIR "/src/Каталог" ARG Version RUN dotnet build "Имя-проекта.csproj" -p:Version=$Version -c Release -o /app/build FROM build AS publish ARG Version RUN dotnet publish "Имя-проекта.csproj" -p:Version=$Version -c Release -o /app/publish
Вот в общем-то и всё — осталось лишь запустить сборку с помощью команды docker build передать нужное значение с помощью опции —build-arg:
docker build -f Path-to-Dockerfile --build-arg Version=0.1.0 -t ...