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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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