Следует ли поместить AssemblyInfo.cs в систему контроля версий?

У меня есть автоматизированная система сборки с использованием CruiseControl. Я использую SvnRevisionLabeller, чтобы получить строку версии для использования. С помощью этой строки я могу использовать nant для обновления AssemblyInfo.cs, чтобы при сборке он имел правильную строку сборки. Я также могу использовать этот ярлык CC, чтобы пометить репозиторий Subversion.

Итак, все выровнено
- Метка сборки CCNet
- Исполняемый файл (информация о сборке)
- Контроль версий (тег subverson)

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

Я знаю, что это часто не рекомендуется, но следует ли мне проверять файл assemblyInfo.cs после каждой сборки, чтобы при последующей сборке из проверки svn использовалась правильная информация о версии?

Спасибо, Лиам


person Liam Donaldson    schedule 10.06.2009    source источник


Ответы (4)


Либо не создавайте версии AssemblyInfo.cs, либо поместите их «версию для разработчиков» в репозиторий и попросите CruiseControl.Net svn-revert их после сборки (я делаю это позже, чтобы сборки, сделанные на рабочих станциях разработчиков, были легко погашены из "официальные" скачаны с CruiseControl.Net).

Что касается воспроизведения тех же меток сборки позже - вам уже нужно выполнить перестройку, вызвав MSBuild / NAnt вручную, просто передайте ему CCNetLabel, для которого установлено соответствующее значение, и вы получите те же версии сборки, что и при сборке, вызванной из CruiseControl. .Net (MSBuild: /p:CCNetLabel=1.4.2.333, NAnt: -D:CCNetLabel=1.4.2.333).

person skolima    schedule 12.06.2009

Я использую файл CommonAssemblyInfo.cs, на который добавляю ссылку в каждом проекте.

Единственный атрибут, который у меня есть в этом файле, - AssemblyFileVersion, и CC.Net / Msbuild обновляют версию при каждой сборке.

Убедитесь, что любой проект, включающий CommonAssemblyInfo.cs, не имеет повторяющихся атрибутов в AssemblyInfo.cs.

Если вы посмотрите исходный код CC.Net, вы увидите, как они настроены.

person Ryu    schedule 24.07.2009

Я всегда проверяю это. На самом деле я считаю, что это поведение по умолчанию для Team System Source Control.

person Robert Kozak    schedule 10.06.2009
comment
Я использую Subversion и CrusieControl.NET. Я строю с использованием сценария NAnt. Все, что я прочитал, это то, что AssemblyInfo.cs - это результат, созданный в процессе сборки. Таким образом, последовательность сборки следующая: - CCNET (запуск SVN при регистрации репозитория @say версии 100) NAnt, называемый msbuild, с именем assemblyinfo.cs, создается после сборки. Теперь я возвращаю сборку assemblyInfo.cs? Если зарегистрирован, то репозиторий будет иметь версию 101. Так что моя цель, чтобы AssemblyInfo.cs соответствовала версии сборки, не была достигнута. Как мне это сделать? - person Liam Donaldson; 12.06.2009
comment
Я считаю, что причина, по которой вы не хотите проверять AssemblyInfo.cs в вашем случае, заключается в том, что ваша система CI генерирует его. При нормальной сборке, включая способ, которым это делают серверы сборки TFS, AssemblyInfo.cs регистрируется и не создается для каждой сборки. - person majinnaibu; 24.01.2013

У нас есть сценарий MSBuild, который генерирует все необходимые файлы AssemblyInfo.cs перед сборкой. Таким образом, я также могу использовать номер ревизии SVN в версиях сборки. Файлы AssemblyInfo.cs не регистрируются в SVN (они игнорируются, чтобы не беспокоить людей), а генерируются перед сборкой (независимо от того, является ли это сценарием автоматической сборки или из VS).

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

person jl.    schedule 18.12.2009