Автоматическое обновление и регистрация файлов AssemblyInfo.cs иногда вызывает частичный сбой - PullRequest
Новая
       18

Автоматическое обновление и регистрация файлов AssemblyInfo.cs иногда вызывает частичный сбой

2 голосов
/ 06 октября 2008

Наша сборка TFS 2008 настроена для извлечения всех файлов AssemblyInfo.cs в проекте, обновления их с помощью AssemblyInfoTask, а затем отменяет извлечение или проверку в зависимости от того, прошла сборка или нет. К сожалению, когда две сборки находятся в очереди близко друг к другу, это приводит к Частично завершенной сборке, поскольку файлы AssemblyInfo.cs, кажется, извлекаются из более ранней версии, чем предыдущая регистрация.

Чтобы обойти это, я подумал, что мог бы использовать задачу «Получить», чтобы принудительно установить файлы AssemblyInfo.cs до последней версии перед их обновлением, но, похоже, это не имеет никакого эффекта. Есть идеи? 

<Target Name="AfterGet" Condition="'$(IsDesktopBuild)'!='true'">
<Message Text="SolutionRoot = $(SolutionRoot)" />
<Message Text="OutDir = $(OutDir)" />
<!-- Set the AssemblyInfoFiles items dynamically -->
<CreateItem Include="$(SolutionRoot)\Main\Source\InputApplicationSln\**\$(AssemblyInfoSpec)">
  <Output ItemName="AssemblyInfoFiles" TaskParameter="Include" />
</CreateItem>

<Message Text="$(AssemblyInfoFiles)" />

<!-- When builds are queued up successively, it is possible for the next build to be set up before the AssemblyInfoSpec is checked in so we need to force 
    the latest these versions of these files to be got before a checkout -->
<Get Condition=" '$(SkipGet)'!='true' " TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Workspace="$(WorkspaceName)" Filespec="$(AssemblyInfoSpec)"  Recursive="$(RecursiveGet)" Force="$(ForceGet)" />

<Exec WorkingDirectory="$(SolutionRoot)\Main\Source\InputApplicationSln"
          Command="$(TF) checkout /recursive $(AssemblyInfoSpec)"/>

Ответы [ 2 ]

0 голосов
/ 08 октября 2008

Изменение: 

<Get Condition=" '$(SkipGet)'!='true' " TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Workspace="$(WorkspaceName)" Filespec="$(AssemblyInfoSpec)"  Recursive="$(RecursiveGet)" Force="$(ForceGet)" />

Кому: 

<Get Condition=" '$(SkipGet)'!='true' " TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Workspace="$(WorkspaceName)" Filespec="$(AssemblyInfoSpec)"  Recursive="True" Force="True" />

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

0 голосов
/ 06 октября 2008

Перезаписывает ли ваша сборка файлы AssemblyInfo и затем возвращает их обратно? Или вы просто изменяете файлы AssemblyInfo локально. Лично я предпочитаю последний подход - как описано на сайте получателей TFSBuild:

http://tfsbuild.com/AssemblyVersioning%20.ashx

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

  1. Запрос сборки, текущий набор изменений = 42
  2. Начинается сборка 1 для ревизии 42
  3. Запрос на сборку, текущий набор изменений = 42 (все еще)
  4. Сборка 2 для ревизии 42 в очереди
  5. Build 1 проверяет новые файлы assemblyinfo, текущий набор изменений = 43
  6. Сборка 1 завершена
  7. Запускается сборка 2 для набора изменений 42, которая получает набор изменений 42, означающий, что файлы AssemblyInfo являются сложенными.

Как я уже сказал, не совсем уверен, когда определяется номер набора изменений для сборки - во время постановки в очередь или во время выполнения. Хотя было бы разумнее, чтобы это было во время очередей.

...