У нас есть ночной процесс сборки что автоматически версии весь C++ projecs. Вот то, как это работает. Существует общий заголовочный файл VersionNumber.h
это имеет определенное #define
для номера версии. Ночная сборка проверяет этот файл, увеличивает целое число позади этого #define
и регистрирует его. Все проекты Visual C++ #include
тот заголовок в их файлы ресурсов и использование, которые определяют для определения версии (версия - что-то как 1.0.3.ThatNumber
).
Пока все хорошо. Теперь я хотел бы иметь то же для библиотек классов C#, созданных в той же ежедневной сборке. В настоящее время они все имеют
[assembly: AssemblyVersion("1.0.*")]
в файлах AssemblyInfo.cs и библиотеках заканчиваются с 1.0.HorribleNumber.AnotherHorribleNumber
поскольку версия и эти два числа не коррелируют к числу, используемому проектами C++.
Как у меня есть та же детерминированная автоматическая нумерация версии в моих проектах C# с минимальным усилием?
Во-первых, вы можете указать полную версию следующим образом:
[assembly: AssemblyVersion("1.0.9.10")]
Во-вторых, общий подход к созданию это немного более просто (и перекликается с вашим подходом C ++) - иметь один файл Version.cs (имя неважно), который находится в общем месте, в котором есть атрибуты версии. Затем вы можете добавить этот файл в качестве ссылки ко всем вашим проектам cs, не забыв удалить атрибуты версии из файлов AssemblyInfo.cs. Таким образом, вам нужно обновить только один файл (перед запуском сборки). Вы также можете поместить в файл Version.cs другие общие атрибуты сборки, например NeutralResourcesLanguage или CLSCompliant.
Если вы не используете единый подход «Version.cs», вы можете рекурсивно работать со структурой каталогов исходного кода и обновлять файлы AssemblyInfo по отдельности (перед запуском сборки).
Возможно, это не имеет отношения к вам, но номера версий (в AssemblyVersion) имеют максимальный диапазон 16 бит. Я видел, что это стало проблемой, когда для этих чисел использовались даты. Если вы хотите иметь больше свободы, то AssemblyFileVersion не имеет этих ограничений, но предназначена исключительно для информационных целей только в .Net, а не является частью идентичности сборки. Обычно для AssemblyVersion и AssemblyFileVersion устанавливаются одинаковые значения, поскольку некоторые инструменты отображают их комбинации.
См. Следующие сведения о AssemblyVersion и AssemblyFileVersion:
В чем разница между AssemblyVersion, AssemblyFileVersion и AssemblyInformationalVersion?
Мы используем FinalBuilder для автоматизированных сборок (у нас его вызывает TeamCity), и он делает подобные вещи автоматически (то есть может получить номер сборки откуда-то еще (ini-файл, переменная среды, командная строка и т. Д.), А затем обновите для вас все версии сборки, указав номер сборки.)
Очевидно, это не единственный способ сделать это, но если вы не использовали что-то вроде FinalBuilder, попробуйте - по нашему опыту, вы начинаете задаваться вопросом, почему раньше вы так долго умели работать с Makefile и пакетными файлами ...
Но если вы не хотите этого делать, можете ли вы использовать тот же процесс, который генерирует / изменяет файл VersionNumber.h, чтобы он также выдавал VersionNumber. cs, со строкой AssemblyVersion в нем? Затем вы можете просто включить этот файл в свой проект.
Директива AssemblyVersion не обязательно должна находиться в том же файле, что и все остальные ваши данные AssemblyInfo.
Вы можете сделать что-то вроде того, что уже делаете для своей техники C ++, но найдите строку "assembly: AssemblyVersion (
и замените число в кавычках на полное, обязательное номер версии.
В C # подстановочный знак в номере версии указывает компилятору автоматически обновлять номер версии - если подстановочный знак отсутствует, он просто будет использовать полный предоставленный номер.
например
[assembly: AssemblyVersion("1.0.3.10")]
Всегда будет использовать это номер версии, пока вы не измените его в файле.
Вы можете установить версию сборки из другого файла, добавив на него ссылку. Аналогичное решение -