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

Question

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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