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

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

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


person Chris Charabaruk    schedule 06.10.2008    source источник


Ответы (8)


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

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

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

person Craig Trader    schedule 06.10.2008
comment
С CruiseControl.NET у вас есть каждая отдельная сборка, когда-либо созданная, нет причин пересобирать старую версию. Если вы хотите добавить исправления в более старую версию, вам необходимо разветвить свой код в системе управления версиями в этой конкретной версии. - person Sandor Davidhazi; 16.01.2009
comment
Есть разница между извлечением сборки из хранилища и возможностью доказать, что вы захватили все элементы, необходимые для сборки любого конкретного выпуска. Существует множество переменных среды, которые могут повлиять на создание любой конкретной сборки. Мой стандарт заключается в том, чтобы оформление заказа было как можно более автономным, чтобы вы могли выполнять оформление заказа на новой машине и создавать программное обеспечение с нуля. Этого труднее достичь с помощью .Net (в отличие от Java), но все же это достойная цель. Это означает, что я зашел так далеко, что зарегистрировал Java, Ant и все библиотеки вместе с моим исходным кодом. - person Craig Trader; 27.04.2009

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

person Wim Coenen    schedule 15.01.2009
comment
Ага, гораздо лучше использовать AssemblyInformationalVersion. - person Wim Hollebrandse; 08.01.2010
comment
Ссылка на указанный атрибут: msdn.microsoft.com/en-us / library / - person Chris Charabaruk; 13.07.2010
comment
Не могли бы вы рассказать, как это помогает? пытается ли он проанализировать его и только предупредить, а не потерпит неудачу, если он превышает? Это настоящая проблема / позор. Наличие svn revs в номере версии действительно удобно, но теперь у нас есть 70 000+ ревизий, поэтому он постоянно падает. - person Jon H; 17.11.2011
comment
@JonH: если вы попытаетесь поместить такой номер версии в код C #, например как [assembly: AssemblyVersion("1.1.1.70000")] , то компилятор остановится на ошибке Ошибка выдачи атрибута 'System.Reflection.AssemblyVersionAttribute' - 'Указанная версия' 1.1.1.70000 'недействительна'. - person Wim Coenen; 17.11.2011
comment
Ага ... это то, что у меня / у нас есть прямо сейчас ... Полагаю, это неразрешимо. - person Jon H; 17.11.2011

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

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

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

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

person James Curran    schedule 06.10.2008

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

person Lou Franco    schedule 06.10.2008
comment
В каком поле номера версии? - person Chris Charabaruk; 06.10.2008
comment
Хорошая идея, но, вероятно, взорвется после того, как changeset-id достигнет 0xfffe, если вы ограничите его только одним из полей версии, major, minor, build, revision. - person GertGregers; 06.10.2008

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

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

person Daniel Fortunov    schedule 15.01.2009

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

person Bob Dizzle    schedule 06.10.2008

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

person Atanas Korchev    schedule 06.10.2008
comment
Звучит хорошо, но если вы делаете несколько сборок в день или поддерживаете несколько веток, я вижу, что это довольно быстро разваливается. - person Chris Charabaruk; 06.10.2008
comment
Совершенно верно. Включение номера сборки или времени сборки может быть жизнеспособным решением. - person Atanas Korchev; 06.10.2008
comment
Вы также можете использовать время, см. stackoverflow.com/questions/971476/ - person Cheeso; 11.06.2009

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

person Lars Truijens    schedule 06.10.2008
comment
Перекомпиляция или файл политики требуется только в том случае, если сборка имеет строгое имя. - person James Curran; 06.10.2008