Построить на TFS 2013 не удалось, но нормально локально

Ответ 1

Сервер сборки TFS 2013 использует MSBuild 12.0, где CodeTasksFactory существует в Microsoft.Build.Tasks.v12.0.dll, а не Microsoft. Build.Tasks.v4.0.dll.

В идеале вы должны сделать следующее:

1) Откройте файл NuGet.targets: C:\Builds\1\xxxx\FTP-процессор (новый)\src.nuget\nuget.targets

2) Определите задачу, ссылающуюся на старую DLL.

<UsingTask AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" TaskFactory="CodeTaskFactory" >
...

3) Тогда в будущем это будет выглядеть так:

<UsingTask AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v$(MSBuildToolsVersion).dll" TaskFactory="CodeTaskFactory" >
...

Ответ 2

Как и VS2013, вы должны запускать MSBuild из C:\Program Files (x86)\MSBuild\12.0\Bin\

не из C:\Windows\Microsoft.NET\Framework64\v4.0.30319. См.

http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx

источник: http://gyorgybalassy.wordpress.com/2013/12/31/msb4175-the-task-factory-codetaskfactory-could-not-be-loaded/

он решил проблему для меня.

Ответ 3

После долгих исследований и попыток кучки "хаков" я продолжил понимать точную механику восстановления nuget. Оказывается, все изменилось с nuget 2.7+, и вам больше не нужно включать папку ".nuget" и связанные с ней файлы nuget.exe и nuget.target

Чтобы исправить мой процесс сборки и использовать последний рекомендованный подход, я сделал следующее:

• Перенесите nuget.config в файл .sln с таким же путем.
• Полностью удалить папку ".nuget"
• Удалить ссылки на эту папку в файле .sln
• Удалить следующие строки из любого файла .csproj

-

<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />

-

Это может занять некоторое время, если в вашем проектном решении много файлов или вы работаете над многими проектами, созданными с помощью Visual Studio 2013 и ранее.

Хорошая новость заключается в том, что есть powershell script, который применяет вышеперечисленные рекурсии в любой папке:

• https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/migrateToAutomaticPackageRestore.ps1

Короче говоря, он отменяет "Включить восстановление пакета Nuget", что позволяет более новый метод восстановления пакета.

В Visual Studio 2013 автоматическое восстановление пакета стало частью IDE (и процесс сборки TFS). Этот метод более надежен, чем старше, встроенное восстановление пакета msbuild. Это не требует от вас nuget.exe проверяет каждое решение и не требует никаких дополнительные цели msbuild. Однако, если у вас есть файлы, связанные с старый метод восстановления пакета в вашем проекте, Visual Studio будет пропустить автоматическое восстановление пакета. (Такое поведение, вероятно, изменится скоро, надеюсь, это так).

Вы можете использовать этот script для удаления nuget.exe, nuget.targets и всех ссылки на проект и решение для nuget.targets, чтобы вы могли принять преимущество автоматического восстановления пакетов. Это более или менее автоматизирует описанный здесь.

Он перезапустится через каталог, в котором вы запускаете script, и выполняете это к любым решениям, которые могут быть где-то там. Будьте осторожны и повеселись! (не несет ответственности за все, что ломается)

Несколько хороших ссылок на эту тему:

• http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
• http://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore

Ответ 4

У меня была аналогичная проблема. Мы вынуждены использовать более старый msbuild, который поставляется с каркасом, а не версию v14, которая поставляется с visual studio 2015, потому что мы создаем старый код Delphi.net. Наши файлы vcxproj запускают некоторую автоматическую цель анализа кода, у которой есть задача, которая зависит от Microsoft.Build.Tasks.v12.0.dll. Я смог переопределить эту задачу, скопировав ее и вставив ее в верхнюю часть vcxproj и изменив путь к dll. Оригинальную задачу можно найти в "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.Targets". Таким образом, другими словами, вы могли бы переопределить проблемную задачу в своем проекте.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <!-- override a task which we can't use with the old msbuild -->
  <UsingTask TaskName="SetEnvironmentVariable" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll">
    <ParameterGroup>
      <EnvKey ParameterType="System.String" Required="true" />
      <EnvValue ParameterType="System.String" Required="true" />
    </ParameterGroup>
    <Task>
      <Using Namespace="System" />
      <Code Type="Fragment" Language="cs">
        <![CDATA[
            try {
                Environment.SetEnvironmentVariable(EnvKey, EnvValue, System.EnvironmentVariableTarget.Process);
            }
            catch  {
            }
        ]]>
      </Code>
    </Task>
  </UsingTask>