wake-up-neo.com

Build auf TFS 2013 ist fehlgeschlagen, aber lokal in Ordnung

Beim Einchecken des Codes hat TFS 2013 die Lösung automatisch erstellt. Es ist in lokalem VS 2013 in Ordnung, aber in TFS fehlgeschlagen.

Hier ist die Zusammenfassung.

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)
26
user1108948

Ihr TFS 2013-Buildserver verwendet MSBuild 12.0, wobei CodeTasksFactory in Microsoft.Build.Tasks.v12.0.dll und nicht in Microsoft.Build.Tasks.v4.0.dll vorhanden ist. 

Idealerweise sollten Sie Folgendes tun:

1) Öffnen Sie Ihre NuGet.targets-Datei: C:\Builds\1\xxxx\FTP Processor (neu)\src.nuget\nuget.targets

2) Identifizieren Sie die Task, die auf die alte DLL verweist.

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

3) Dann zukunftssicher es so:

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

Ab VS2013.... Sollten Sie MSBuild unter C:\Programme (x86)\MSBuild\12.0\Bin\ausführen. 

nicht aus C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Sehen 

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

source: http://gyorgybalassy.wordpress.com/2013/12/31/msb4175-the-task-factory-codetaskfactory-could-not-be-loaded/

es löste das Problem für mich.

4
Ranadheer Reddy

Nach langem Suchen und Ausprobieren einer Reihe von "Hacks" verstand ich die genauen Mechanismen der Nuget-Wiederherstellung. Es stellt sich heraus, dass sich seit Nuget 2.7+ alles geändert hat und Sie müssen nicht mehr den Ordner ".nuget" und die zugehörigen Dateien nuget.exe und nuget.target enthalten

Um meinen Erstellungsprozess zu korrigieren und den neuesten empfohlenen Ansatz zu verwenden, habe ich Folgendes getan:

  • Verschieben Sie nuget.config so, dass derselbe Ordnerpfad in der .sln-Datei enthalten ist
  • Löschen Sie den ".nuget" -Ordner vollständig
  • Löschen Sie Verweise auf diesen Ordner in der .sln-Datei
  • Löschen Sie die folgenden Zeilen aus einer beliebigen .csproj-Datei

-

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

-

Dies kann einige Zeit in Anspruch nehmen, wenn Ihre Projektlösung viele Dateien enthält oder Sie an vielen Projekten arbeiten, die mit Visual Studio 2013 erstellt wurden.

Die gute Nachricht ist, dass es ein Powershell-Skript gibt, das das obige rekursiv auf jeden Ordner anwendet:

Kurz gesagt, es wird "Nuget Package Restore aktivieren" rückgängig gemacht, wodurch .__ zugelassen wird. neuere Methode zur Wiederherstellung des Pakets.

In Visual Studio 2013 wurde die automatische Wiederherstellung von Paketen Bestandteil von IDE (und der TFS-Buildprozess). Diese Methode ist zuverlässiger als die ältere, msbuild integrierte Paketwiederherstellung. Es erfordert nicht, dass Sie habe nuget.exe in jede Lösung eingecheckt und erfordert keine zusätzliche mebuild Ziele. Wenn Sie jedoch über die Dateien verfügen, die sich auf .__ beziehen. Wenn Sie die alte Methode zum Wiederherstellen des Pakets in Ihrem Projekt verwenden, wird Visual Studio Automatische Paketwiederherstellung überspringen. (Dieses Verhalten ändert sich wahrscheinlich Bald, hoffentlich auch).

Sie können dieses Skript verwenden, um nuget.exe, nuget.targets und alle .__ zu entfernen. Projekt- und Lösungsverweise auf nuget.targets, damit Sie .__ nehmen können. Vorteil der automatischen Paketwiederherstellung. Es automatisiert mehr oder weniger das hier beschriebenen Prozess.

Es wird erneut durch das Verzeichnis geführt, aus dem Sie das Skript ausführen, und wird ausgeführt Es gibt alle Lösungen, die irgendwo drin sein könnten. Seien Sie vorsichtig und habe Spaß! (nicht verantwortlich für alles, was kaputt geht)

Ein paar gute Links zum Thema:

2
Korayem

Ich hatte ein ähnliches Problem. Wir sind gezwungen, die ältere Version von msbuild zu verwenden, die mit dem Framework geliefert wird, und nicht die Version 14, die mit Visual Studio 2015 geliefert wird, da wir alten Delphi.net-Code erstellen. Unsere vcxproj-Dateien lösen ein automatisches Ziel für die Code-Analyse aus, dessen Aufgabe auf Microsoft.Build.Tasks.v12.0.dll beruht. Ich konnte diese Aufgabe überschreiben, indem ich sie kopierte und in den oberen Bereich des vcxproj einfügte und den Pfad zur DLL verfeinerte. Die ursprüngliche Aufgabe befindet sich unter "C:\Programme (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.Targets". Mit anderen Worten, Sie können die Problemaufgabe in Ihrem Projekt also überschreiben.

<?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>  
0
flobadob