У меня есть ASP. NET Базовое приложение, которое я публикую на выделенном сервере через Azure DevOps конвейеры сборки / выпуска.
Я управляю номером версии приложения с помощью Задача GitVersion (gittools.gitversion.gitversion-task.GitVersion@4) в сборке YAML.
Этап сборки выглядит примерно так:
- task: DotNetCoreCLI@2
displayName: 'dotnet build'
inputs:
command: custom
custom: build
workingDirectory: src/MyAppProjectFolder
arguments: '-p:Version=$(GitVersion.FullSemVer)'
И правильно генерирует .exe с заданным FullSemVer (я проверяю Azure рабочая папка агента)
Тогда у меня есть шаг publi sh:
- task: DotNetCoreCLI@2
displayName: 'dotnet publish'
inputs:
command: publish
publishWebProjects: false
arguments: '--output $(build.artifactstagingdirectory) --no-restore --no-build'
workingDirectory: src/MyAppProjectFolder
По какой-то причине тот же .exe, который я нашел в C: \ agent_work \ 1 \ a \ a.zip, созданный издательством sh, НЕ имеет правильного номера версии, но общий c 1.0.0.
Если я "эмулирую" конвейеры вручную на том же сервере (с dotnet build и dotnet publish вручную через powershell, те же параметры) все работает как положено.
Что происходит? Есть ли способ, чтобы приложение сохраняло версию $ (GitVersion.FullSemVer)?
Примечание : мне пришлось добавить
- task: UseDotNet@2
displayName: 'Use .Net Core sdk 2.1.x'
inputs:
packageType: sdk
version: 2.1.x
installationPath: $(Agent.ToolsDirectory)/dotnet
includePreviewVersions: true
перед каждым NET Основная задача, как объяснено здесь , после обновления агентов до. NET Core 3.0 (до того, как эти сборки работали хорошо).