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

Question

У нас есть TFS 2008, наша сборка настроена для проверки всех файлов AssemblyInfo.cs в проекте, обновления их с помощью AssemblyInfoTask, а затем либо отменить checkout, либо checkin в зависимости от была ли построена или нет. К сожалению, когда две сборки находятся в очереди близко друг к другу, это приводит к частично завершенной сборке, поскольку файлы 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)"/> 

Answer 1

Изменение:

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

To:

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

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

Answer 2

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

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

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

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

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