TFS build 2008 - BuildNumberOverrideTarget Зависит от того, что не выполняется в правильном порядке для начальной сборки - PullRequest
1 голос
/ 19 ноября 2009

Я создал файл tfsbuild.proj, который создает версию выпуска моего решения, и в нем я создал пользовательскую цель для BuildNumberOverrideTarget, которая обрабатывает пользовательские версии. Я храню номер версии в расположении файла в TFS, и пользовательская задача получит номер версии, проверит файлы assemblyinfo.cs, отредактирует сведения о версии, зарегистрирует и затем увеличит номер версии для следующей сборки.

Это все работало нормально, но только если вы позволили TFS выполнить первую сборку перед добавлением изменений контроля версий в ваш файл tfsbuild.proj, это похоже на то, что он полагается на структуру каталогов Sources \, которая уже существует из более ранней сборки , Поэтому, если вы решите разветвить свой исходный код и запустить сборку как есть, произойдет сбой со странной ошибкой, такой как:

Target "InitializeWorkspace" skipped. Previously built successfully.
Target "BuildNumberOverrideTarget" in file "e:\tfstemp\TestProject\TestProject MainBranch Release\BuildType\TFSBuild.proj" from project "e:\tfstemp\TestProject\TestProject MainBranch Release\BuildType\TFSBuild.proj":
Task "Message"
  Loading last build number from file "e:\tfstemp\TestProject\TestProject MainBranch Release\BuildType\..\Sources\Version Number\buildnumber.txt"
Done executing task "Message".
Using "Exec" task from assembly "Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "Exec"
  Command:
  "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe" get /force /noprompt /overwrite buildnumber.txt
e:\tfstemp\TestProject\TestProject MainBranch Release\BuildType\TFSBuild.proj(472,5): error MSB6003: The specified task executable "cmd.exe" could not be run. The directory name is invalid
Done executing task "Exec" -- FAILED.
Done building target "BuildNumberOverrideTarget" in project "TFSBuild.proj" -- FAILED.
Done Building Project "e:\tfstemp\TestProject\TestProject MainBranch Release\BuildType\TFSBuild.proj" (EndToEndIteration target(s)) -- FAILED.

Build FAILED.

После некоторых исследований я обнаружил следующий веб-сайт, на котором говорится, что порядок не правильный, если вы хотите переопределить целевой номер сборки. Он предлагает либо изменить порядок выполнения, либо добавить DependsOnTarget в BuildNumberOverrideTarget.

http://social.msdn.microsoft.com/forums/en-US/tfsbuild/thread/9103c92d-4b03-41d4-9eae-93c78cb6ea3a/

Я попробовал оба предложения в посте, но я просто не могу заставить его работать, ошибка сборки, кажется, пропускает InitializeWorkspace.

У меня был обходной путь, который частично работает, но затем мы видим ошибки в разветвленных областях о том, что рабочая область не существует. Наш обходной путь заключался в создании структуры каталогов в BuildNumberOverrideTarget со следующими изменениями в файле tfsbuild.proj:

<Target Name="BuildNumberOverrideTarget">
    <!-- Create a custom build number, matching the assembly version -->
    <Message Text="Loading last build number from file &quot;$(MSBuildProjectDirectory)\..\Sources\Version Number\buildnumber.txt&quot;" />

    <!--need to ensure that the sources folder exists-->
    <PropertyGroup>
      <SourcesDirectory>$(MSBuildProjectDirectory)\..\Sources\Version Number</SourcesDirectory>
    </PropertyGroup>
    <MakeDir Directories="$(SourcesDirectory)"/>

    <Exec Command="$(TF) get /force /noprompt /overwrite buildnumber.txt"
          WorkingDirectory="$(MSBuildProjectDirectory)\..\Sources\Version Number\">
    </Exec>

    <Exec Command="$(TF) checkout buildnumber.txt"
      WorkingDirectory="$(MSBuildProjectDirectory)\..\Sources\Version Number\" IgnoreExitCode="true">
    </Exec>
  ... rest omitted to keep short...
</Target>

Есть ли способ заставить msbuild при запуске автоматически получить всю исходную структуру перед попыткой запустить какую-либо из моих пользовательских целей? Мы делаем сборку релиза, и мне не нравится идея, что, возможно, она пытается кэшировать старые версии файлов и структур папок.

Большое спасибо,

Эмма

1 Ответ

0 голосов
/ 14 декабря 2012

Я не уверен, что это работает в TFS 2008, но мне удалось решить эту проблему в TFS 2010, установив следующие зависимости:

<Target Name="BuildNumberOverrideTarget" DependsOnTargets="CoreInitializeWorkspace;CoreCleanAll;CoreGet">

Вам нужны все 3 зависимости:

  • CoreInitializeWorkspace просто создает рабочее пространство, но не получает никаких файлов
  • CoreGet получает файлы, что мы и хотим
  • CoreCleanAll для очистки старого кода из предыдущих сборок. Если мы не зависим от него, то он запустится после CoreGet и удалит весь код, который мы только что извлекли, тогда сборка не удастся, потому что у нее нет кода для компиляции: -)
...