Установка номера версии для проектов .NET Core - CSPROJ - не JSON-проекты
Этот вопрос очень похож на Установка номера версии для проектов .NET Core, но не то же самое. Используя последнюю стабильную версию .NET Core на момент написания (1.1) и VS2017,.NET Core переключился с файлов проектов на основе JSON на файлы CSPROJ.
Итак - то, что я пытаюсь сделать, это настроить среду CI, где я хотел бы иметь возможность модифицировать что-то до сборки, чтобы штамповать мои сборки с правильным номером версии.
Если я использую такие атрибуты, как старый (SharedAssemblyInfo.cs трюк):
[assembly: AssemblyFileVersion("3.3.3.3")]
[assembly: AssemblyVersion("4.4.4.4")]
где-то в проекте, я получаю
CS0579 - Duplicate 'System.Reflection.AssemblyFileVersionAttribute'
и
CS0579 - Duplicate 'System.Reflection.AssemblyVersionAttribute'
ошибки при создании.
Когда вы немного разбираетесь в этом, я обнаружил, что есть файл, который выглядит так, как это было создано во время процесса сборки (он не существует до того, как я построил) в \obj\Debug\netcoreapp1.1
:
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.42000
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
using System;
using System.Reflection;
[assembly: System.Reflection.AssemblyCompanyAttribute("TestApplication")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyDescriptionAttribute("Package Description")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.1.99.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.1.99")]
[assembly: System.Reflection.AssemblyProductAttribute("TestApplication")]
[assembly: System.Reflection.AssemblyTitleAttribute("TestApplication")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.1.99.0")]
// Generated by the MSBuild WriteCodeFragment class.
Вопрос - как это сделать?
Поэтому я вижу, что это должно каким-то образом генерироваться из значений, введенных на странице пакета свойств проекта, но я не знаю, каким правильным способом было бы изменить эти значения на моей машине CI.
В идеале я хотел бы указать всю эту информацию в моем (Jenkins) CI script, но я бы согласился просто установить номер версии.
EDIT - дополнительная информация
Прочитав первый ответ, я хотел дать понять, что я создаю как службы, так и пакеты NuGET - и я предпочел бы иметь один способ управления версиями, что было бы похоже на старый проект JSON, где я мог бы просто обновить один файл,
UPDATE
Я собираюсь с помощью скрипта изменить файл CSPROJ, который, на мой взгляд, довольно хакерский, так как раздел, который мне нужно изменить, выглядит так...
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
<Version>1.0.7777.0</Version>
<AssemblyVersion>1.0.8888.0</AssemblyVersion>
<FileVersion>1.0.9999.0</FileVersion>
<Company>MyCompany</Company>
<Authors>AuthorName</Authors>
<Product>ProductName</Product>
<Description />
<Copyright>Copyright © 2017</Copyright>
</PropertyGroup>
Итак, проблема заключается в том, что существует несколько элементов PropertyGroup; другие, похоже, помечены, но, не зная, как CSPROJ объединяется, я не могу сказать, что это всегда будет так.
Я работаю над тем, что детали пакета всегда будут заполняться, в противном случае теги значений (выше) не отображаются в XML файле, поэтому я могу использовать script для обновления значений. Если тегов значений не было, я бы не имел четкого представления о том, какой элемент PropertyGroup вставляет значения в (а также какой порядок, поскольку это кажется важным, изменение порядка остановило меня от загрузки проекта в VS2017).
Я все еще держусь за лучшее решение, чем это!
Обновление: после того, как кто-то отметит этот вопрос как возможный дубликат (Автоматическое ведение версий в Visual Studio 2017 (.NET Core)) - Я не видел этого вопроса раньше и теперь чтение кажется почти таким же, за исключением того, что я просто не хочу устанавливать номер версии. Кроме того, ответы на этот вопрос не решают мою проблему - только спрашивают, что я спросил по моему вопросу. Принятый ответ на мой вопрос - это именно тот ответ, который мне нужен, чтобы решить мою проблему - так что, когда другой вопрос пришел первым и появляется то же самое - мне это совсем не помогает. Может быть, мод может помочь?
Ответы
Ответ 1
Вы можете переопределить любое свойство из командной строки, передав /p:PropertyName=Value
в качестве аргументов dotnet restore
, dotnet build
и dotnet pack
.
В настоящее время состав версии работает следующим образом:
Если Version
не задано, используйте VersionPrefix
(по умолчанию - 1.0.0, если не установлено) и - если присутствует - добавьте VersionSuffix
.
Затем вся другая версия по умолчанию имеет значение Version
.
Так, например, вы можете установить <VersionPrefix>1.2.3</VersionPrefix>
в свой csproj, а затем вызвать dotnet pack --version-suffix beta1
для создания YourApp.1.2.3-beta1.nupkg
(если у вас есть ссылка на проект, к которой вы хотите применить суффикс версии, вам нужно позвонить dotnet restore /p:VersionSuffix=beta1
до этого - это известная ошибка в инструменте).
Конечно, вы также можете использовать собственные переменные, см. эту проблему GitHub для нескольких примеров.
Для полной ссылки на поддерживаемые атрибуты сборки я предлагаю посмотреть исходный код логики сборки здесь (значения, окруженные $()
используются свойства).
И поскольку я уже говорю об источнике, this является логикой, которая составляет версию и несколько других свойств.
Ответ 2
dotnet build /p:AssemblyVersion=1.2.3.4
Это работает для вас?
Ответ 3
Чтобы ответить на ваш вопрос прямо: новый SDK для msbuild автоматически генерирует файл информации о сборке. Вы можете подавить это, используя директивы msbuild (чтобы увидеть его по образцу: invoke dotnet migrate
в проекте project.json).
Но позвольте мне рассказать вам о моей работе: у меня было несколько проектов, имеющих одну и ту же версию. Я добавил файл version.props
, содержащий группу свойств, включающую элемент с именем VersionPrefix
. Этот файл я включил через файл csproj (оператор Include
). Я также удалил все файлы AssemblyInfo.cs
и предоставил SDK их для меня.
Я изменяю файл version.props
во время сборки.
Ответ 4
Я использую Jenkins + Octopus для CI, и после этого работала достаточно хорошо:
- У вас есть pre-build
Powershell
script, который может принимать номер сборки CI в качестве параметра или по умолчанию для чего-то заданного.
- В проекте для CI есть отдельный файл
nuspec
.
- Предварительная сборка script обновит файл
nuspec
с последней версией сборки.
- Опубликовать проект с Jenkins.
- Вызовите
Nuget
вручную с помощью файла nuspec
из # 2.
- Нажмите
Nuget
пакет на Octopus.
Ответ 5
MsBuild 2017 сгенерирует некоторую информацию о сборке, если вы пропустили их в файле проекта.
Если вы можете прочитать целевой файл msbuild, вы можете посмотреть:
[VS Install Dir] \MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.GenerateAssemblyInfo.targets
Вы увидите, что вы можете использовать какое-либо свойство в своем файле проекта, чтобы отключить сгенерированную информацию сборки, чтобы предотвратить дублирование ваших сгенерированных инструментов.
-
<GenerateAssemblyInfo>
(Это свойство будет включать/выключать все данные сборки)
-
<GenerateAssemblyCompanyAttribute>
-
<GenerateAssemblyConfigurationAttribute>
-
<GenerateAssemblyCopyrightAttribute>
-
<GenerateAssemblyDescriptionAttribute>
-
<GenerateAssemblyFileVersionAttribute>
-
<GenerateAssemblyInformationalVersionAttribute>
-
<GenerateAssemblyProductAttribute>
-
<GenerateAssemblyTitleAttribute>
-
<GenerateAssemblyVersionAttribute>
-
<GenerateNeutralResourcesLanguageAttribute>
Ответ 6
В моем случае основным ключом был /property:Version=1.2.3.4
. И следующая командная строка сделала работу:
dotnet build SolutionName.sln -c Release /property:Version=1.2.3.4
Это заменит версию сборки по умолчанию.
Ответ 7
Как я ответил здесь, я создал инструмент CLI под названием dotnet-setversion, которые вы можете использовать для проектов .NET Core. *.csproj.
Во время сборки CI вы можете использовать GitVersion или другое средство для определения номера версии для вашего проекта, а затем вызвать dotnet-setversion $YOUR_VERSION_STRING
в корневом каталоге проекта.
Ответ 8
Передача/p: PropertyName = Значение как аргументы для меня не работает (ASP.Net Core 2.0 Web App).
Я нашел Manifest Versioning Build Tasks на рынке: https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-Versioning-Task