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

Question

Когда я проверил код, TFS 2013 автоматически построил решение. Это нормально в локальном VS 2013, но не удалось в TFS.

Вот резюме.

Summary 
FTPProcessor | Any CPU 
1 error(s), 56 warning(s) 
$/xxxx/NewServiceHost/New-Branch/NewServiceHost/packageRestore.proj - 0 error(s), 0 warning(s) 
$/xxxx/NewServiceHost/New-Branch/GenericWindowsServices.sln - 1 error(s), 56 warning(s) 
C:\Builds\1\xxxx\FTP Processor (New)\src\.nuget\nuget.targets (71): The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Build.Tasks.v4.0.dll". Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Build.Tasks.v4.0.dll' or one of its dependencies. The system cannot find the file specified. 
Other Errors 
1 error(s) 
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException) Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation) 

Answer 1

Ваш TFS 2013 сервер сборки использует MSBuild 12.0, где CodeTasksFactory exists in Microsoft.Build.Tasks.v12.0.dll вместо Microsoft.Build.Tasks.v4.0.dll.

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

1) Откройте файл NuGet.targets: C: \ Строит \ 1 \ хххх \ FTP Processor (New) \ 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" > 
... 

Answer 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/

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

Answer 3

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

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

• Move 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 скрипт, который применяется выше рекурсивно на любой папке:

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

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

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

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

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

Пару хороших ссылок по теме:

• 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

Answer 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>