Як я можу автоматично збільшити версію збірки C # за допомогою нашої платформи CI (Хадсон)?

Я та моя група надзвичайно великі, коли збільшуються номери версій монтажу, і ми часто постачаємо збірки з версіями 1.0.0.0. Очевидно, це викликає багато головних болів.

Ми набагато покращуємо свою практику через нашу платформу CI, і я дуже хотів би встановити її для автоматичного збільшення значень у assemblyinfo.csфайлі, щоб версії наших збірок автоматично оновлювалися зі змінами коду в цій збірці.

Раніше я налаштовував (перш ніж ми знайшли Хадсона ) спосіб збільшити значення за допомогою будь-якого msbuildабо командного рядка (не пам'ятаю), але з Хадсоном це оновить сховище SVN і запустить СКЛАДНУ збірку. Це призведе до повільного нескінченного циклу, оскільки Гудсон щогодини опитує SVN.

Чи погана ідея збільшення Хадсона на номер версії? Який був би альтернативний спосіб зробити це?

В ідеалі моїми критеріями рішення були б такі:

• Збільшує число збірки assemblyinfo.csперед збіркою
• Тільки збільшує кількість збірки в збірках, які змінилися. Це може бути неможливо, оскільки Хадсон видаляє папку проектів щоразу, коли збирає
• Подає змінений Assemblyinfo.cs у сховище коду (зараз VisualSVN )
• Не змушує Хадсон запускати нову збірку наступного разу, коли він сканує зміни

Опрацьовуючи це в голові, я міг легко придумати рішення більшості цього за допомогою пакетних файлів / команд, але всі мої ідеї змусять Хадсона запустити нову збірку наступного разу, коли вона сканує. Я не шукаю, щоб хтось зробив для мене все, просто вкажіть мене в правильному напрямку, можливо, техніка, щоб змусити Гудсона ігнорувати певні зобов’язання SVN тощо.

Все, що я знайшов до цього часу, - це лише стаття, в якій пояснюється, як автоматично збільшувати номер версії. Ніщо не враховує платформу CI, яку можна було б повернути у нескінченний цикл.

Проста альтернатива - дозволити середовищу C # збільшити версію збірки для вас, встановивши атрибут версії до major.minor.*(як описано в шаблоні файлу AssemblyInfo.)

Ви, можливо, шукаєте більш комплексне рішення.

EDIT (відповідь на запитання в коментарі):

Від AssemblyInfo.cs:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

Ось що я зробив для штампування атрибута AssemblyFileVersion.

Видалено AssemblyFileVersion з AssemblyInfo.cs

Додайте до проекту новий, порожній файл під назвою AssemblyFileInfo.cs.

Встановіть набір інструментів завдань спільноти MSBuild на машину збирання hudson або як залежність NuGet у своєму проекті.

Відредагуйте файл проекту (csproj), це лише файл msbuild і додайте наступне.

Десь <PropertyGroup>з'явиться версія, де зазначено версію. Змініть так, щоб він читався, наприклад

 <Major>1</Major>
 <Minor>0</Minor>
 <!--Hudson sets BUILD_NUMBER and SVN_REVISION -->
 <Build>$(BUILD_NUMBER)</Build>
 <Revision>$(SVN_REVISION)</Revision>

Хадсон надає ті змінні env, які ви бачите там, коли проект побудований на Гудзоні (припускаючи, що він отриманий із підривної роботи).

Внизу файлу проекту додайте

 <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" />
  <Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')">
    <Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" />
    <AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " />
  </Target>

Для цього використовується MSBuildCommunityTasks для генерування AssemblyFileVersion.cs для включення атрибута AssemblyFileVersion перед тим, як проект будується. Ви можете зробити це для будь-якого / всіх атрибутів версії, якщо хочете.

Результатом є щоразу, коли ви випускаєте побудову Гудзона, отримана збірка отримує AssemblyFileVersion 1,0.HUDSON_BUILD_NR.SVN_REVISION, наприклад, 1.0.6.2632, що означає 6-ю збірку # в Хадсоні, що купується з ревізії підконтрольної версії 2632.

Ось вишукане рішення, яке потребує невеликої роботи наперед при додаванні нового проекту, але обробляє процес дуже легко.

Ідея полягає в тому, щоб кожен проект посилався на файл рішення, який містить лише інформацію про версію збірки. Тож ваш процес збирання повинен лише оновити один файл, і всі версії збірки витягуються з одного файлу при компіляції.

Кроки:

1. Додайте до файлу рішення клас * файл .cs, я назвав min SharedAssemblyProperties.cs
2. Видаліть всю інформацію CS з цього нового файлу
3. Виріжте інформацію про збірку з файлу AssemblyInfo: [Assembly: AssemblyVersion ("1.0.0.0")] [Assembly: AssemblyFileVersion ("1.0.0.0")]
4. Додайте вислів "за допомогою System.Reflection;" у файл, а потім вставити дані у новий файл cs (колишній SharedAssemblyProperties.cs)
5. Додайте до проекту існуючий елемент (зачекайте ... читайте далі, перш ніж додавати файл)
6. Виберіть файл і перед натисканням кнопки Додати натисніть спадне меню біля кнопки "Додати" та виберіть "Додати як посилання".
7. Повторіть кроки 5 та 6 для всіх існуючих та нових проектів у рішенні

Коли ви додаєте файл у якості посилання, він зберігає дані у проектному файлі і після компіляції витягує інформацію про версію збірки з цього файлу.

У керуванні джерелом ви додаєте bat-файл або файл сценарію, який просто збільшує файл SharedAssemblyProperties.cs, і всі ваші проекти оновлять інформацію про його збірку з цього файлу.

Хадсон може бути налаштований на ігнорування змін до певних контурів і файлів, щоб він не вимагав нової збірки.

На сторінці конфігурації завдання в розділі Керування вихідним кодом натисніть кнопку Додатково . У полі Виключені регіони ви вводите одне або більше регулярних виразів, щоб відповідати виключенням.

Наприклад, щоб ігнорувати зміни у файлі version.properties, ви можете використовувати:

/MyProject/trunk/version.properties

Це буде працювати для інших мов, крім C #, і дозволяє зберігати інформацію про версію в межах підривної роботи.

.NET робить це за вас. У файлі AssemblyInfo.cs встановіть версію збірки на major.minor. * (Наприклад: 1.0. *).

Коли ви будуєте проект, версія генерується автоматично.

Я думаю, що номери збірки та ревізії створюються на основі дати, використовуючи епоху unix. Збірка заснована на поточному дні, а перегляд ґрунтується на кількості секунд з півночі.

Я ніколи не бачив, щоб ця функція 1.0. * Працювала у VS2005 або VS2008. Чи потрібно щось зробити, щоб VS збільшував значення?

Якщо AssemblyInfo.cs жорстко кодується з 1.0. *, То де зберігаються реальні збірки / версії?

Після додавання 1.0. * У AssemblyInfo, ми не можемо використовувати наступне твердження, оскільки ProductVersion тепер має недійсне значення - воно використовує 1.0. *, А не значення, призначене VS:

Version version = new Version(Application.ProductVersion);

Зітхання - це, здається, одна з тих речей, про які всі запитують, але чомусь ніколи не існує надійної відповіді. Роки тому я бачив рішення для створення ревізійного номера та збереження його у AssemblyInfo як частина процесу після збирання. Я сподівався, що такий тип танцю не буде потрібен для VS2008. Може бути, VS2010?

Я припускаю, що це також можна зробити з текстовим шаблоном, коли ви створюєте атрибути збірки під час руху з навколишнього середовища, як, наприклад, AssemblyVersion.tt.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
var build = Environment.GetEnvironmentVariable("BUILD_NUMBER");
build = build == null ? "0" : int.Parse(build).ToString();
var revision = Environment.GetEnvironmentVariable("SVN_REVISION");
revision = revision == null ? "0" : int.Parse(revision).ToString();    
#>
using System.Reflection;
[assembly: AssemblyVersion("1.0.<#=build#>.<#=revision#>")]
[assembly: AssemblyFileVersion("1.0.<#=build#>.<#=revision#>")]

Як продовження відповіді MikeS, я хотів би додати, що для того, щоб це працювало, потрібно встановити SDK для візуалізації та моделювання VS + Visual Studio, і вам також потрібно змінити файл проекту. Слід зазначити, що я використовую Jenkins як сервер збірки, що працює на сервері Windows 2008 R2 з модулем версії, де я отримую BUILD_NUMBER.

Файл мого текстового шаблона version.tt виглядає приблизно так

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
var build = Environment.GetEnvironmentVariable("BUILD_NUMBER");
build = build == null ? "0" : int.Parse(build).ToString();
var revision = Environment.GetEnvironmentVariable("_BuildVersion");
revision = revision == null ? "5.0.0.0" : revision;    
#>
using System.Reflection;
[assembly: AssemblyVersion("<#=revision#>")]
[assembly: AssemblyFileVersion("<#=revision#>")]

У групах властивостей є наступне

<PropertyGroup>
    <TransformOnBuild>true</TransformOnBuild>
    <OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
    <TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>

після імпорту Microsoft.CSharp.targets я маю це (залежно від місця встановлення VS

<Import Project="C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TextTemplating\v10.0\Microsoft.TextTemplating.targets" />

Тоді на моєму сервері збірки у мене є наступний скрипт для запуску перетворення тексту перед фактичним складанням, щоб отримати останній номер набору змін на TFS

set _Path="C:\Build_Source\foo"

pushd %_Path% 
"%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" history . /r /noprompt /stopafter:1 /Version:W > bar
FOR /f "tokens=1" %%foo in ('findstr /R "^[0-9][0-9]*" bar') do set _BuildVersion=5.0.%BUILD_NUMBER%.%%foo
del bar
popd

echo %BUILD_NUMBER%
echo %_BuildVersion%
cd C:\Program Files (x86)\Jenkins\jobs\MyJob\workspace\MyProject
MSBuild MyProject.csproj /t:TransformAll 
...
<rest of bld script>

Таким чином я можу відслідковувати збірки та набори змін, тому якщо я не перевіряв нічого в минулому з моменту останньої збірки, остання цифра не повинна змінюватися, проте я могла внести зміни в процес збирання, отже, потреба в другому останньому номері . Звичайно, якщо ви зробите кілька реєстрацій перед збіркою, ви отримаєте лише останню зміну, відображену у версії. Я думаю, ви могли б поєднати це, що потрібно.

Я впевнений, що ви можете зробити щось більш фантазійне і зателефонувати в TFS безпосередньо з шаблону tt, проте це працює для мене.

Тоді я можу отримати свою версію під час виконання, як це

Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
return fvi.FileVersion;

Моє рішення не вимагає додавання зовнішніх інструментів або мов скриптів - це майже гарантовано працює на вашій машині побудови. Я вирішую цю проблему в декількох частинах. По-перше, я створив файл BUILD.BAT, який перетворює параметр Jenkins BUILD_NUMBER в змінну середовища. Я використовую функцію "Виконати пакетну команду Windows" Дженкінса, щоб запустити пакетний файл збірки, ввівши наступну інформацію для складання Дженкінса:

     ./build.bat --build_id %BUILD_ID% -build_number %BUILD_NUMBER%

У середовищі збірки у мене є файл build.bat, який починається наступним чином:

     rem build.bat
     set BUILD_ID=Unknown
     set BUILD_NUMBER=0
     :parse_command_line
     IF NOT "%1"=="" (
         IF "%1"=="-build_id" (
             SET BUILD_ID=%2
             SHIFT
             )
         IF "%1"=="-build_number" (
             SET BUILD_NUMBER=%2
             SHIFT
         )
         SHIFT
         GOTO :parse_command_line
     )
     REM your build continues with the environmental variables set
     MSBUILD.EXE YourProject.sln

Як тільки я це зробив, я клацнув правою кнопкою миші на проект, який потрібно побудувати на панелі провідника Рішення Visual Studio, і вибрав "Властивості", виберіть "Події збирання" та ввів наступну інформацію як командний рядок "Попередньо побудувати події", який автоматично створює файл .cs містить інформацію про номер збірки на основі поточних параметрів змінної середовища:

     set VERSION_FILE=$(ProjectDir)\Properties\VersionInfo.cs
     if !%BUILD_NUMBER%==! goto no_buildnumber_set
     goto buildnumber_set
     :no_buildnumber_set
     set BUILD_NUMBER=0
     :buildnumber_set
     if not exist %VERSION_FILE% goto no_version_file
     del /q %VERSION_FILE%
     :no_version_file
     echo using System.Reflection; >> %VERSION_FILE%
     echo using System.Runtime.CompilerServices; >> %VERSION_FILE%
     echo using System.Runtime.InteropServices; >> %VERSION_FILE%
     echo [assembly: AssemblyVersion("0.0.%BUILD_NUMBER%.1")] >> %VERSION_FILE%
     echo [assembly: AssemblyFileVersion("0.0.%BUILD_NUMBER%.1")] >> %VERSION_FILE%

Можливо, вам доведеться підлаштувати свій смак. Я будую проект вручну один раз, щоб генерувати початковий файл Version.cs в каталозі Властивості основного проекту. Нарешті, я вручну включаю файл Version.cs у рішення Visual Studio, перетягуючи його на панель Провідник рішень, під вкладку Властивості цього проекту. У майбутніх збірках Visual Studio потім зчитує файл .cs у часі збірки Дженкінса і отримує з нього правильну інформацію про номер збірки.

Отже, у нас є проект з одним рішенням, який містить кілька проектів, які мають збірки з різними номерами версій.

Дослідивши кілька перерахованих вище методів, я просто здійснив крок збирання для запуску сценарію Powershell, який робить пошук і заміну у файлі AssemblyInfo.cs. Я все ще використовую номер версії 1.0. * У контролі джерела, і Дженкінс просто вручну оновлює номер версії до запуску msbuild.

dir **/Properties/AssemblyInfo.cs | %{ (cat $_) | %{$_ -replace '^(\s*)\[assembly: AssemblyVersion\("(.*)\.\*"\)', "`$1[assembly: AssemblyVersion(`"`$2.$build`")"} | Out-File $_ -Encoding "UTF8" }
dir **/Properties/AssemblyInfo.cs | %{ (cat $_) | %{$_ -replace '^(\s*)\[assembly: AssemblyFileVersion\("(.*)\.\*"\)', "`$1[assembly: AssemblyFileVersion(`"`$2.$build`")"} | Out-File $_ -Encoding "UTF8" }

Я додав параметр -Encoding "UTF8", тому що git почав обробляти файл .cs як бінарні файли, якщо я цього не зробив. Звичайно, це не має значення, оскільки я ніколи фактично не здійснюю результат; це просто вийшло, як я тестував.

У нашому середовищі CI вже є можливість асоціювати побудову Дженкінса з конкретним git-комітетом (спасибі плагін Stash!), Тому я не хвилююся, що немає git-комітету із доданим до нього номером версії.

Це простіший механізм. Він просто передбачає додавання команди Windows Batch для створення завдання перед кроком MSBuild та використання простої програми пошуку та заміни (FART).

Крок партії

fart --svn -r AssemblyInfo.cs "[assembly: AssemblyVersion(\"1.0.0.0\")]" "[assembly: AssemblyVersion(\"1.0.%BUILD_NUMBER%.%SVN_REVISION%\")]"
if %ERRORLEVEL%==0 exit /b 1
fart --svn -r AssemblyInfo.cs "[assembly: AssemblyFileVersion(\"1.0.0.0\")]" "[assembly: AssemblyFileVersion(\"1.0.%BUILD_NUMBER%.%SVN_REVISION%\")]"
if %ERRORLEVEL%==0 exit /b 1
exit /b 0

Якщо ви використовуєте джерело управління, крім svn, змініть параметр --svn на відповідний для вашого scm середовища.

Завантажити Фарт

Я вирішив використати пару методів, використовуючи попередній збір сценарію Powershell ( https://gist.github.com/bradjolicoeur/e77c508089aea6614af3 ) для збільшення кожної успішної збірки, то в Global.asax я щось подібний:

  // We are using debug configuration, so increment our builds.
  if (System.Diagnostics.Debugger.IsAttached)
  {
      string version = System.Reflection.Assembly.GetExecutingAssembly()
                                                       .GetName()
                                                       .Version
                                                       .ToString();

      var psi = new ProcessStartInfo(@"svn", "commit -m \"Version: " + version + "\n \"");
      psi.WorkingDirectory = @"C:\CI\Projects\myproject";
      Process.Start(psi); 
  }

Я все ще думаю, що весь процес є надскладним, і я розглядаю більш ефективний метод досягнення того ж результату. Я хотів цього головним чином для передачі версії в SVN, а потім у Jenkin's без занадто багато додаткових інструментів.