Каков наилучший способ использования атрибутов управления версиями?

Question

Атрибуты AssemblyVersion и AssemblyFileVersion - это встроенный способ обработки номеров версий для сборников .NET. Хотя структура обеспечивает возможность определения наименее значимых частей номера версии (сборка и ревизия в терминах Microsoft) автоматически определяется, я нахожу метод для этого довольно слабым, и, несомненно, есть много других.

Итак, я хотел бы спросить, какие способы были определены, чтобы лучше всего использовать номера версий, которые лучше отражают фактическую версию проекта? У вас есть сценарий предварительной сборки, который устанавливает часть версии в дату и время или версию репозитория для вашей рабочей копии проекта? Вы просто используете автоматическое поколение, предоставляемое каркасом? Или что-то другое? Каков наилучший способ управления версиями сборки/файла?

Answer 1

В моем текущем проекте мы используем номер ревизии Subversion как наименее значимую (строчную) часть номера версии, и мы используем скрипт Nant для создания файла AssemblyInfo проекта. Мы используем тот же номер версии для атрибутов AssemblyVersion и AssemblyFileVersion. (Остальные три части являются major.minor.point, где major.minor будет увеличиваться каждый раз при изменении схемы базы данных, а точка увеличивается для каждой версии.)

Мы начали с того, что номер сборки был просто увеличен, но для этого требовалось, чтобы файл версии был проверен для каждой сборки и вызывал конфликты при слиянии. Когда это оказалось неработоспособным, мы начали использовать CruiseControl.NET для генерации номера сборки, но это затрудняло воспроизведение отдельных сборок вручную. В конце концов мы перешли к текущей схеме (Subversion-revision).

Примечание: К сожалению, с .NET невозможно полностью воссоздать сборку из прошлой версии, поскольку компиляторы .NET кодируют текущую временную метку в объектный файл при компиляции. Каждый раз, когда вы компилируете один и тот же код, вы получаете другой объектный файл.

Answer 2

Наши скрипты сборки вводят номер набора изменений из TFS в версию. Таким образом, мы точно знаем, какие проверки находятся в сборке.

Answer 3

Мы используем версию из подрывной деятельности и имеем buildscripts, обновляем информацию о версии сборки, поэтому исходные проверки контролируют управление версиями.

Answer 4

Атрибут AssemblyVersionAttribute является частью идентификатора сборки. Изменение означает, что это другая сборка, и программы, связанные с этой сборкой, необходимо перекомпилировать/связать или применить политику версии. Мы не обнаружили, что apealing, поэтому мы решили только увеличить AssemblyFileVersion для каждого исправления и только изменить AssemblyVersion для каждой основной версии. Мы осознаем, что это решение возвращает часть адской версии win32. Мы увеличиваем AssemblyFileVersion для каждой сборки и метки/тега системы управления версиями с этой версией, чтобы мы знали, из какого источника появился двоичный файл.

Answer 5

На предыдущем задании, в котором мы использовали Subversion, у меня был сценарий nant, который запускал ccnet для извлечения версии репозитория и использовал это как окончательное число.

В этой работе мы используем VSS (затвор), так что это не вариант, поэтому мы имеем политику обновления вручную, со следующими указаниями:

• мажор: достоверны (> 25%) изменения или дополнения в функциональность или интерфейс.
• Малый: небольшие изменения или дополнения в функциональности или интерфейсе.
• Сборка: незначительные изменения, которые нарушают интерфейс.
• Редакция: исправления для сборки, которые не меняют интерфейс.

Мы также сохраняем сборку & версий файлов в синхронизации. Версия Assembly легко читается программно, а версия файла может отображаться в виде столбца в режиме сведений в проводнике Windows.

Answer 6

Мы стремимся внедрить дату выпуска (или сборки) в сборку. Например, если построено сегодня версия будет «2008.10.06» (скрипт сборки обновляет ее).

Answer 7

У нас есть сервер сборки CruiseControl.NET, который встраивает номер списка изменений perforce в AssemblyFileVersion - это позволяет нам отследить исходный код для любой сборки, построенной сервером сборки. (Мы всегда строим из основного филиала.)

Для собраний, на которые будут ссылаться клиенты, мы оставляем константу AssemblyVersion, если не произошли нарушения, и в этом случае мы увеличиваем версию, чтобы гарантировать, что код клиента будет перестроен против новая версия.

Answer 8

Я вижу здесь много сообщений об использовании номера ревизии подвариантности в качестве компонента версии сборки. Остерегайтесь: 4 номера версии, доступные в окнах (a.b.c.d), ограничены 16 бит (макс = 65535). Номер версии подвыражения может легко превысить этот предел, особенно если вы размещаете несколько проектов в одном хранилище.