Я потратил большую часть нескольких часов, пытаясь найти способ автоматического увеличения версий в .NETCoreApp 1.1 (Visual Studio 2017).
Я знаю, что AssemblyInfo.cs динамически создается в папке: obj/Debug/netcoreapp1.1/
Он не принимает старый метод:
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.*")]
Если я установлю пакет для проекта, я могу установить там версии, но, похоже, это будет использоваться для создания файла AssemblyInfo.cs.
Мой вопрос: кто-нибудь понял, как управлять версией в проектах .NET Core (или .NETStandard, если на то пошло).
/p:
флагdotnet msbuild
в свой скрипт сборки и установить версию, компанию, авторские права ... все это хорошее.<Deterministic>False</Deterministic>
в csproj. (или используйте любую другую логику MSbuild для вычисления<VersionPrefix>
/<Version>
)Ответы:
Я искал инкремент версии для приложения Net Core в VS2017 с использованием формата конфигурации csproj.
Я нашел проект под названием dotnet bump, который работал с форматом project.json, но изо всех сил пытался найти решение для формата .csproj. Создатель dotnet bump фактически предложил решение для формата .csproj, и оно называется MSBump.
Для этого есть проект на GitHub:
https://github.com/BalassaMarton/MSBump
где вы можете увидеть код, а также его доступность на Nuget. Просто найдите MSBump на Nuget.
источник
Добавить
<Deterministic>False</Deterministic>
в<PropertyGroup>
раздел .csprojОбходной путь, заставляющий AssemblyVersion * работать, описан в «Непонятном сообщении об ошибке для подстановочного знака в [AssemblyVersion] в .Net Core # 22660»
Причины, по которым разработчики .Net Core считают детерминированные сборки полезными, описаны в http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html, а компиляторы должны быть детерминированными: одинаковые входные данные генерируют одинаковые выходные данные # 372
Однако, если вы используете TeamCity, TFS или другой инструмент CI / CD, вероятно, лучше держать номер версии под контролем и увеличивать их и передавать для сборки в качестве параметра (как было предложено в других ответах), например
Номер пакета для пакетов NuGet
источник
Если вы используете Visual Studio Team Services / TFS или какой-либо другой процесс сборки CI для встроенного управления версиями, вы можете использовать атрибут msbuild
Condition
, например:Это укажет компилятору .NET Core использовать все, что находится в
BUILD_BUILDNUMBER
переменной среды, если она есть, или вернуться к ней,0.0.1-local
если вы выполняете сборку на своем локальном компьютере.источник
Я придумал решение, которое работало почти так же, как старый атрибут AssemblyVersion со звездочкой (*) - AssemblyVersion ("1.0. ") *
Значения для AssemblyVersion и AssemblyFileVersion находятся в файле .csproj проекта MSBuild (не в AssemblyInfo.cs ) как свойство FileVersion (генерирует AssemblyFileVersionAttribute ) и AssemblyVersion (генерирует AssemblyVersionAttribute ). В процессе MSBuild мы используем нашу настраиваемую задачу MSBuild для генерации номеров версий, а затем переопределяем значения этих свойств FileVersion и AssemblyVersion новыми значениями из задачи.
Итак, сначала мы создаем нашу настраиваемую задачу MSBuild GetCurrentBuildVersion :
Задача класса унаследованы от Microsoft.Build.Utilities.Task класса из Microsoft.Build.Utilities.Core пакета NuGet. Он принимает свойство BaseVersion (необязательно) на входе и возвращает сгенерированную версию в свойстве вывода Version. Логика получения номеров версий такая же, как и для автоматического управления версиями .NET (номер сборки - это количество дней с 01.01.2000, а версия - полсекунды с полуночи).
Для создания этой задачи MSBuild мы используем тип проекта библиотеки классов .NET Standard 1.3 с этим классом.
Файл .csproj может выглядеть так:
Этот проект задачи также доступен в моем GitHub holajan / DC.Build.Tasks
Теперь мы настраиваем MSBuild для использования этой задачи и устанавливаем свойства FileVersion и AssemblyVersion . В файле .csproj это выглядит так:
Важные вещи здесь:
Преимущество этого решения заключается в том, что оно работает не только из сборок на сервере сборки, но и в ручных сборках из сборки dotnet или Visual Studio.
источник
DateTime.UtcNow
вместоDateTime.Now
методаGetCurrentBuildVersionString()
in, в частности, если код выполняется на машинах автоматической сборки. Они могут работать в 2 или 3 часа ночи, когда ваш компьютер переключается на летнее время и обратно. ВDateTime.Now
этом сценарии вы можете вернуться назад с точки зрения версии. По общему признанию, это угловой случай, и я также признаю, что я придирчив. :-) Кроме того, проблема исчезнет, если вы настроите один и тот же часовой пояс на всех машинах сборки и не будете переходить на летнее время.Вы можете использовать функцию свойства MSBuild, чтобы установить суффикс версии на основе текущей даты:
Будет выведен пакет с таким именем: PackageName.1.0.0-pre20180807-1711.nupkg .
Дополнительные сведения о функциях свойств MSBuild: https://docs.microsoft.com/en-us/visualstudio/msbuild/property-functions
Version
Формируется из комбинацииVersionPrefix
иVersionSuffix
, или еслиVersionSuffix
пусто,VersionPrefix
только.источник
Я принял приведенный выше ответ, потому что @Gigi верен (на данный момент), но я был раздражен и придумал следующие сценарии PowerShell.
Сначала у меня есть сценарий в папке с моим решением (UpdateBuildVersion.ps1):
Я добавил это в файл csproj:
Даже если для него установлено значение PreBuildEvent, на самом деле номера версий не обновляются до ПОСЛЕ загрузки файла в память, поэтому номер версии не будет отображаться до следующей сборки. Фактически, вы можете изменить его на PostBuildEvent, и это даст тот же эффект.
Я также создал следующие два скрипта: (UpdateMinorVersion.ps1)
(UpdateMajorVersion.ps1)
источник
сборка dotnet /p:AssemblyVersion=1.2.3.4
Я отвечал: «Кто-нибудь придумал, как управлять версией в проектах .NET Core (или .NETStandard в этом отношении)». Я обнаружил, что этот вопрос пытается решить эту проблему в контексте сборки CI. Я хотел установить версию сборки на номер сборки CI.
источник
Эти значения теперь установлены в
.csproj
файле:Это те же значения, которые вы увидите, если перейдете на вкладку « Пакет » в настройках проекта. Хотя я не думаю, что вы можете использовать
*
автоинкремент версии, вы можете ввести этап постобработки, который заменяет версии для вас (например, как часть вашей непрерывной интеграции).источник
Я сделал простой инструмент CLI для установки .csproj версии строк .NET Ключевой здесь . Вы можете комбинировать его с такими инструментами, как GitVersion, для автоматического повышения версии во время сборки CI, если вам это нужно.
источник
Чтобы включить управление версиями вашего .Net Core / .Net Независимо от проекта, основанного на вашей настройке GIT, используйте теги / описать функциональность GIT.
Я использовал файл Prebuild.targets.xml, который находится в корневой папке проекта и включен в файл csproj, например:
Используйте тег GenerateAssembyInfo, чтобы отключить автоматическое создание информации о сборке.
Затем Prebuild.targets.xml сгенерирует файл CommonAssemblyInfo.cs, в который вы можете включить теги версии, которые хотите, на основе вашей версии GIT.
ПРИМЕЧАНИЕ: я нашел Prebuilds.targets.xml где-то еще, поэтому не стал его очищать.)
Файл Prebuild.targets.xml:
РЕДАКТИРОВАТЬ: если вы строите с помощью MSBUILD,
Может вызвать проблемы, используйте
вместо
источник
Вы можете сделать следующее в файле csproj. Я не разбирался в математике. Я обнаружил это где-то еще в stackoverflow. Но это работает и даст вам нечто похожее на версию 1.0. *.
источник
Расширение Automatic Versions для Visual Studio теперь поддерживает автоинкремент .Net Core и .Net Standard в простом пользовательском интерфейсе.
https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.AutomaticVersions
источник
Спасибо @joelsand за то, что указали мне правильное направление.
Мне пришлось немного изменить его ответ, так как при запуске DevOps Build у меня возникло следующее исключение
Мне пришлось добавить $ (BUILD_BUILDNUMBER) в конец раздела major.minor.build. Чтобы исключить дубликат фактической версии, я также использую префикс версии:
источник
Мы можем использовать специальный параметр для
dotnet publish -- version-suffix 1.2.3
Для файловой версии:
Для версии:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish?tabs=netcore21
источник
Я думаю, что этот ответ от @joelsand - правильный ответ для установки номера версии для ядра dotnet, работающего на VSTS
Чтобы добавить дополнительную информацию к этому ответу,
BUILD_BUILDNUMBER
на самом деле предопределенная переменная .Оказывается, есть 2 версии предопределенной переменной.
Один - build.xxxx, другой - BUILD_XXXX.
Вы можете использовать только
Environment Variable Name
в cproj.источник
build.xxxx
используется во внешнем интерфейсе для ссылки в конвейере иBUILD_XXXX
имеет то же значение, но с немного измененным синтаксисом, необходимым для ссылки на переменную в PS?В качестве альтернативы приведенному выше вы можете попробовать фиксированный старший номер с суффиксом на основе текущей даты:
источник