Версия сборки vs Номер версии

У меня есть приложение asp.net/C#, которое использует subversion для управления версиями.

Мое приложение автоматически увеличивает его AssembleVersion и AssemblyFileVersion для каждой сборки, которая работает как шарм, и отображает номер сборки в административной части сайта.

Мы отслеживаем AssembleVersion и AssemblyFileVersion при развертывании, однако, когда возникает проблема, и нам нужно откат к определенной версии, мы не имеем представления о том, какая ревизия цели в subversion.

У меня мало идей:

  1. Сохранить AssembleVersion как комментарий в каждом файле
  2. Имейте ключевое слово в комментариях коммита, которые будут заменены на AssembleVersion для каждой фиксации (все равно нужно выяснить, как это сделать)

Любая помощь и предложения будут оценены

Обновлено: опция «1» на самом деле является глупой идеей, потому что это будет означать, что каждый раз, когда я строю, все файлы будут отмечены как обновленные, и когда я зафиксирую, каждый файл будет обновлен

Solutions Collecting From Web of "Версия сборки vs Номер версии"

Когда я строю, я помещаю этот номер сборки всюду.

  • Я положил его в тег в svn.
  • Я помещаю его в метаданные Ассамблеи каждой сборки, которую я создаю.
  • Я добавляю его в конец имени файла в установщиках.
  • Я помещал его в нижний колонтитул каждого из моих развернутых веб-страниц.
  • Я поставил его в нижнем колонтитуле моих отчетов.
  • Я положил его в заставку своих приложений на стороне клиента.
  • Я положил его на экран приветствия для моих инсталляторов.

Единственное, что я не вставляю, это мой кофе, который я делаю черным .

Все это позволяет разработчику точно знать, откуда пришел код, что они видят, просматривают ли они веб-страницу или просматривают свойства одной из встроенных сборок в проводнике или что-то еще.

Как насчет использования тегов.

http://svnbook.red-bean.com/en/1.1/ch04s06.html

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

И вы должны иметь возможность извлекать версию сборки на своих страницах ASP.NET и печатать ее программно в нижнем колонтитуле или что-то в этом роде.

Вы можете пометить сундук Subversion с помощью AssembleVersion или AssemblyFileVersion, в зависимости от того, что имеет наибольший смысл.

Вы также можете отслеживать номер версии Subversion так же, как вы в настоящее время отслеживаете AssembleVersion и AssemblyFileVersion при развертывании.

Примените тег к исходному дереву после обновления AssemblyVersion и AssemblyFileVersion .

Вы можете «отделиться». Перед созданием сборки выпуска вы можете разветвить соединительную линию, а затем создать тег в новой ветке с номером версии выпуска.

  + release tag / +--------------------- release branch / ----------+----------------------------------------------------- trunk 

Это позволит вам отслеживать все отдельные релизы в SVN. Это также позволит вам сделать изолированные исправления ошибок в ветвях выпуска, которые могут быть выпущены в виде патчей. Исправление ошибки затем может быть объединено обратно в багажник.

  + + patch release tag / / +-----------------+-+---- release branch / | merged fix into trunk... ----------+----------------------------------------------------- trunk 

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

Вы также можете (или дополнительно) включить номер версии svn в AssemblyInfo. Один из подходов заключается в использовании задачи AssemblyInfo из проекта msbuildtasks по адресу http://msbuildtasks.tigris.org

Для получения дополнительной информации, google msbuild svn revision assemblyinfo

Затем вы можете обойтись без тегов / ветвей, так как вы всегда можете проверить конкретную ревизию и / или создать ветвь из определенной ревизии.

Другой вариант – использовать последнюю измененную ревизию в качестве номера сборки. Это означает, что каждый раз, когда вы создаете автоматический тег. Это легко с hudson / jenkins, так как у вас есть переменная окружения SVN_REVISION. Проблема в том, что номер редакции становится очень большим, а обсуждения в коридорах около 1.0.0.20456 против 1.0.0.20489 – это глоток.