Точка сборки TFS2017 не переопределяет номер версии - PullRequest
Новая
       45

Точка сборки TFS2017 не переопределяет номер версии

0 голосов
/ 18 января 2019

Я работаю с процессом сборки TFS2017 и у меня возникают проблемы с версией сборок. Я использую задачу сборки dotnet, команда установлена ​​на build, Проекты установлены на **/*.sln и аргументы установлены на --configuration $(BuildConfiguration) /p:Version=$(Build.BuildNumber)

При просмотре журнала сборки TFS выполняется правильная команда (см. Ниже) 

"C:\Program Files\dotnet\dotnet.exe" build C:\_agent\_work\13\s\*nameofsolution*.sln --configuration Release /p:Version=1100.1.0.0005

Однако версия сборки (версия файла и версия продукта) отображается как 1.0.0.

В файле csproj нет элемента <Version>.

Когда я запускаю указанную выше команду generate на сервере сборки как пользователь агента сборки, сборка версирована правильно. Есть ли что-то, что мне не хватает в моем csproj или как часть свойств решения?

1 Ответ

0 голосов
/ 01 августа 2019

TL & DR

Убедитесь, что ваши последующие шаги сборки на вашем сервере сборки проходят все необходимые флаги --no-build, чтобы предотвратить перекомпиляцию команды dotnet по умолчанию !!! E.G.:

dotnet test my.csproj --no-build --no-restore
dotnet publish my.csproj --output mydir --no-build --no-restore

OK! Я столкнулся с этой проблемой при использовании TeamCity для моего сервера сборки. Я бы запустил процесс сборки через TeamCity, и мой выходной файл nuget содержал бы DLL с версией по умолчанию 1.0.0.0. Но когда я просматривал журналы сборки, я брал команду dotnet build из файла журнала, запускал ее на сервере, и я получал бы версионные dll в каталогах bin.

Вот то, что я узнал, происходило. В моем конвейере сборки, после команды сборки , я также выполнял другие команды, такие как dotnet test и dotnet publish. Эти команды по умолчанию перекомпилируют решение / проект без аргументов сборки! Кроме того, они будут перекомпилировать все упомянутые зависимости проекты.

...