Как вы управляете файлом AssemblyInfo.cs, который хранится в SVN и изменяется при каждой сборке?

У меня есть следующий сценарий: Приложение собирается через IDE и через скрипт сборки. Сценарий сборки используется для первоначальной настройки (извлечение зависимостей, настройка среды), для создания двоичных файлов и для процесса непрерывной интеграции. Я хочу, чтобы двоичные файлы имели в качестве AssemblyFileVersion месяц и день сборки и версию svn для версии. Это приводит к изменению файла AssemblyInfo.cs для каждой версии, что создает много шума в журнале управления версиями. Я могу игнорировать файлы, но тогда как часть установки мне нужно будет их восстановить.

Я хотел бы знать, есть ли у кого-нибудь другие идеи, или что вы делаете в этом случае.


.net msbuild assemblyinfo build-process
person Bruno Lopes    schedule 27.03.2009    source источник

Ответы (5)


arrow_upward
6
arrow_downward

Прямо сейчас я остановился на решении, вдохновленном ответом Энди Уайта:

  • AssemblyInfo.cs создается задачей AssemblyInfo с сайта http://msbuildtasks.tigris.org/ и хранится вне дерева управления версиями.
  • Версия [основная].[дополнительная].[месяц][день].[версия svn]. Major и Minor задаются вручную, остальные управляются скриптом сборки. Пакет Community Tasks включает в себя как задачи, необходимые для получения версии SVN рабочей копии, так и Дата.

Обратная сторона:

  • Когда кто-то извлекает свежую копию, должна быть запущена цель setup скрипта сборки, иначе Visual Studio сообщит об отсутствующих файлах. Это проблема, которую я хотел бы устранить в будущем.
person Bruno Lopes    schedule 27.03.2009
comment
Мы используем почти такое же решение в нашем проекте, но код, отвечающий за генерацию AssemblyInfo, помещается в отдельный целевой файл сборки. На этот целевой файл, в свою очередь, ссылается каждый проект. Таким образом, AssemblyInfo генерируется при каждой сборке, поэтому код создается из репозитория. С 50 проектами в решении мы не говорим о замедлении сборки. Единственная нерешенная (для меня) проблема - сложно контролировать все проекты, использующие этот код. Вот вопрос для этого: ‹stackoverflow.com/questions/5715435/› - person Andriy K; 19.04.2011

arrow_upward
5
arrow_downward

Я думаю, что обычной практикой для AssemblyInfo.cs является просто динамическое создание его как части процесса сборки, а не сохранение статического файла.

Генерируя, вы можете использовать любые произвольные/настраиваемые параметры.

Я считаю, что у NAnt есть задача <asminfo> для этой цели. Я предполагаю, что есть что-то подобное и для MSBuild. Или вы можете просто написать собственный скрипт генерации файлов и использовать его для добавления пользовательского AssemblyInfo.cs в вашу сборку.

person Andy White    schedule 27.03.2009
comment
Что мне не нравится в динамической генерации, так это то, что всегда существует риск того, что процесс, генерирующий файл, со временем изменится, поэтому это может быть хорошо для основной разработки, но что произойдет через 2 года, когда вы захотите проверить файл? старая ветка или тег... можете ли вы полностью на это положиться? - person si618; 27.03.2009
comment
@Si: это не было бы проблемой, если бы сам процесс находился под контролем версий, не так ли? - person Bruno Lopes; 27.03.2009
comment
Правда, если вы верифицируете процесс и инструменты, то это должно быть надежно. У меня нет проблем с динамической генерацией AssemblyInfo в магистрали, но тогда svn нужно будет ее игнорировать (избегая шума), поэтому вам придется возиться с удалением svn:ignore и добавлением AssemblyInfo в вашу ветку выпуска. - person si618; 27.03.2009

arrow_upward
1
arrow_downward

Мы обновляем AssemblyInfo в магистрали только после сборки релиза RTM/RTW/GA/(Whatever:).

Наши сборки Nightly/Beta/RC/QA/(Whatever:) просто берут копию обновленного AssemblyInfo.cs (из рабочей копии на сервере CI) в соответствующую ветку или тег. Мы используем Subversion, и вы можете ветвить/помечать рабочую копию с незафиксированными изменениями.

Это позволяет нам хранить как правильную версию AssemblyInfo для ночной/бета-сборки в ветке или теге, так и касаться AssemblyInfo в основной ветке только после окончательного выпуска. У сервера сборки есть переключатель, который сообщает ему, что нужно зафиксировать это в магистрали для этого типа сборки.

FWIW, мы управляем всем этим из сценариев MSBuild, используя разные значения свойств, установленных для каждого типа проекта, переданного с нашего сервера сборки (CruiseControl.NET).

[EDIT] Также обратите внимание, что версия AssemblyInfo разработчика не обновляется (если они не изменяют ее вручную), поэтому они не получают шума измененной AssemblyInfo при каждой сборке. Мы позволяем разработчикам контролировать Major.Minor, сервер сборки контролирует Build, и мы оставляем Revision для QA, чтобы он связывался с их собственной системой (поскольку WiX/MSI все равно игнорирует его). .

person si618    schedule 27.03.2009
comment
Кажется, это хороший способ управлять им для среднего/большого проекта. Я просто немного беспокоюсь о том, что сервер CI фиксирует репо. Чувствуется немного странно. - person Bruno Lopes; 27.03.2009
comment
Достаточно справедливо, но наш сервер сборки автоматически создает ветку/тег на основе своей собственной сборки, а также создает проект CI для этой ветки. Я предпочитаю иметь один сервер (или образ сервера) с известной настройкой, контролирующей выпуски, а не оставлять это на усмотрение систем разработчиков :) - person si618; 27.03.2009

arrow_upward
0
arrow_downward

Если вы не вернете измененный AssemblyInfo.cs обратно в систему управления версиями, тогда почему возникает шум?

Я бы рекомендовал использовать одно значение AssemblyFileVersion для всей сборки и либо вернуть один файл, содержащий эту версию, либо пометить сборку номером версии. Таким образом, вам не нужно будет возвращать несколько измененных файлов AssemblyInfo.cs.

person John Saunders    schedule 27.03.2009
comment
Если файл остается измененным в локальной рабочей копии, тогда возникает шум, когда я хочу зафиксировать изменения, и мне нужно будет напомнить себе, что не следует фиксировать эти файлы. Я сталкивался с такими сценариями в прошлом, и это создавало некоторую хрупкую среду. - person Bruno Lopes; 27.03.2009
comment
Ой. Я не пользователь SVN - никогда бы не подумал, что это зафиксирует файлы, которые не были проверены. - person John Saunders; 27.03.2009
comment
@ Джон, возможно, я неправильно прочитал твой ответ. Если файла нет в репозитории, его нужно игнорировать, чтобы он не отображался в списке изменений. В этом случае Svn не стал бы пытаться зафиксировать это. - person Bruno Lopes; 27.03.2009

arrow_upward
0
arrow_downward

Мы также используем этап генерации для создания файлов AssemblyInfo.[cs|vb], хотя мы просто используем шаблонную копию файла в качестве источника, а затем небольшой сценарий Perl для анализа этого шаблона, замены строки версии и создания окончательный вывод.

Проблема с этой системой заключается в том, что проекты VB постоянно загружают файл AssemblyInfo, а это означает, что проект будет иметь ошибку при первой загрузке, даже до того, как шаг PreBuild сможет запуститься для создания файла AssemblyInfo.vb. Мы еще не нашли решения этой проблемы - если у кого-то есть понимание, я хотел бы его услышать...

person Community    schedule 21.05.2009