Как вы управляете AssemblyInfo.cs, который хранится в SVN и изменяется с каждой сборкой
У меня есть следующий сценарий: приложение создается с помощью IDE и сценария сборки. Сценарий сборки используется для начальной настройки (выборки зависимостей, настройка среды), для создания двоичных файлов и для процесса непрерывной интеграции. Я хочу, чтобы исполняемые файлы имели в качестве AssemblyFileVersion месяц и день сборки, а svn - ревизию. Это приводит к изменению AssemblyInfo.cs при каждой ревизии, что создает много шума в журнале контроля версий. Я могу игнорировать файлы, но затем, как часть установки, мне нужно будет восстановить их.
Я хотел бы знать, есть ли у кого-нибудь другие идеи, или что вы делаете в этом случае.
5 ответов
Прямо сейчас я остановился на решении, вдохновленном ответом Энди Уайта:
- AssemblyInfo.cs генерируется задачей AssemblyInfo из http://msbuildtasks.tigris.org/ и хранится вне дерева управления исходным кодом.
- Версия: [Major].[Несовершеннолетний]. [Месяц][день]. [SVN Revision]. Major и Minor устанавливаются вручную, остальные управляются скриптом сборки. Пакет задач сообщества включает в себя обе задачи, необходимые для получения рабочей версии svn-версии и даты.
Обратная сторона:
- Когда кто-то извлекает свежую копию, необходимо запустить цель установки сценария сборки, иначе Visual Studio будет жаловаться на отсутствующие файлы. Это проблема, которую я хотел бы устранить в будущем.
Я думаю, что обычная практика для AssemblyInfo.cs - просто генерировать ее динамически как часть процесса сборки, а не хранить статический файл.
Создавая, вы можете использовать любые произвольные / настраиваемые параметры, которые вы хотите.
Я считаю, что NAnt имеет <asminfo> Задача для этого. Я предполагаю, что есть что-то похожее и для MSBuild. Или вы можете просто написать собственный сценарий создания файла и использовать его для вставки собственного AssemblyInfo.cs в вашу сборку.
Мы обновляем только 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).
Мы также используем шаг генерации для создания файлов AssemblyInfo.[Cs|vb], хотя мы просто используем шаблонную копию файла в качестве источника, а затем небольшой скрипт на Perl для анализа этого шаблона, замены строки версии и генерации окончательный вывод.
Проблема с этой системой заключается в том, что проекты VB, по-видимому, постоянно загружают файл AssemblyInfo, что означает, что проект будет иметь ошибку при первой загрузке, даже до того, как будет выполнен шаг PreBuild для создания файла AssemblyInfo.vb. Мы еще не нашли решение этой проблемы - если у кого-то есть понимание, я хотел бы услышать это...
Если вы не вернули измененный AssemblyInfo.cs обратно в систему управления версиями, то почему там шум?
Я бы порекомендовал использовать одно значение AssemblyFileVersion для всей сборки и чтобы вы либо отметили один файл, содержащий эту версию, и / или пометили сборку номером версии. Таким образом, вы не будете нуждаться в проверке нескольких измененных файлов AssemblyInfo.cs.