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

Question

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

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

Answer 1

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

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

Недостатки:

• Когда кто-то извлекает свежую копию, необходимо запустить цель setup сценария сборки, в противном случае Visual Studio будет жаловаться на отсутствующие файлы. Это проблема, которую я хотел бы устранить в будущем.

Answer 2

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

Создавая, вы можете использовать любые произвольные / настраиваемые параметры, которые вы хотите.

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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