La compilazione su TFS 2013 non è riuscita, ma a livello locale

Question

Quando ho controllato il codice, TFS 2013 ha creato automaticamente la soluzione. Va bene nel VS locale 2013 ma non è riuscito in TFS.

Ecco il riepilogo.

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

Il server di build TFS 2013 sta usando MSBuild 12,0 dove CodeTasksFactory exists in Microsoft.Build.Tasks.v12.0.dll piuttosto che Microsoft.Build.Tasks.v4.0.dll.

Idealmente si dovrebbe fare il seguente:

1) Aprire il file NuGet.targets: C: \ Builds \ 1 \ xxxx \ Processor FTP (Nuovo) \ src.nuget \ nuget.targets

2) Identificare l'attività che fa riferimento alla vecchia DLL.

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

3) Poi prova di futuro in questo modo:

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

Answer 2

Come di VS2013, si dovrebbe essere in esecuzione MSBuild da C: \ Program Files (x86) \ MSBuild \ 12.0 \ Bin \

non da C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319. Vedere

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

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

è risolto il problema per me.

Answer 3

Dopo molte ricerche e un sacco di "hack" ho continuato a capire la meccanica esatta del ripristino di nuget. Si scopre che tutto è cambiato da Nuget 2.7+ e non è più necessario includere la cartella ".nuget" e il nuget.exe associato e nuget.target

Per risolvere il mio processo di compilazione e utilizzare l'ultimo approccio raccomandato , ho fatto la seguente:

• Sposta nuget.config di essere con il file sln stesso percorso della cartella
• Elimina cartella ".nuget" del tutto
• Elimina i riferimenti a tale cartella nel file di .sln
• Elimina le seguenti righe da qualsiasi file .csproj

-

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

-

Questo potrebbe richiedere un certo tempo, se la soluzione progetto ha molti file o si lavora su molti progetti creati con Visual Studio 2013 e prima.

La buona notizia è, c'è uno script PowerShell validità di tale ricorsivamente su qualsiasi cartella:

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

In breve, si inverte "Abilita Nuget pacchetto Restore", permettendo il metodo di ripristino del pacchetto più recente funziona.

In Visual Studio 2013, il ripristino automatico del pacchetto è diventato parte dell'IDE (e del processo di generazione TFS). Questo metodo è più affidabile rispetto al ripristino del pacchetto integrato precedente, msg. . Non è necessario che a sia stato eseguito il check-in di nuget.exe per ciascuna soluzione e non siano necessari target di msbuild aggiuntivi per . Tuttavia, se si dispone dei file relativi a nel vecchio metodo di ripristino del pacchetto nel progetto, Visual Studio sostituirà il ripristino automatico del pacchetto con . (È probabile che questo comportamento cambi presto , si spera che lo faccia).

È possibile utilizzare questo script per rimuovere nuget.exe, nuget.targets, e tutte le progetti e soluzioni riferimenti a nuget.targets modo da poter prendere vantaggio di pacchetto ripristino automatico. Più o meno automatizza la procedura qui descritta.

Riceverà attraverso la directory da cui è stato eseguito lo script e lo farà da a qualsiasi soluzione che possa essere lì da qualche parte. Stai attento e divertiti! (Non è responsabile per tutto ciò che si rompe)

Un paio di buoni collegamenti sul tema:

• 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

ho avuto un problema simile. Siamo costretti ad usare il vecchio msbuild che viene fornito con il framework, piuttosto che la versione v14 fornita con Visual Studio 2015 perché abbiamo creato un vecchio codice Delphi.net. I nostri file vcxproj stanno attivando alcuni target di analisi automatica del codice che hanno un'attività che si basa su Microsoft.Build.Tasks.v12.0.dll. Sono stato in grado di ignorare questo compito copiando e incollandolo nella parte superiore del vcxproj e modificando il percorso della DLL. L'attività originale può essere trovata in "C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ CodeAnalysis \ Microsoft.CodeAnalysis.Targets". In altre parole, potresti essere in grado di ignorare l'attività problematica nel tuo progetto.

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