Установка номера версии для проектов .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 в корневом каталоге проекта.