web-dev-qa-db-fra.com

Construire sur TFS 2013 a échoué mais ça va localement

Lorsque j'ai vérifié le code, TFS 2013 a construit la solution automatiquement. C'est bien dans le local VS 2013 mais cela a échoué dans TFS.

Voici le résumé.

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)
tfsmsbuildnugetvisual-studio-2013tfs2013
26
user1108948

Votre serveur de génération TFS 2013 utilise MSBuild 12.0 où CodeTasksFactory existe dans Microsoft.Build.Tasks.v12.0.dll plutôt que Microsoft.Build.Tasks.v4.0.dll. 

Idéalement, vous devriez faire ce qui suit:

1) Ouvrez votre fichier NuGet.targets: C:\Builds\1\xxxx\Processeur FTP (Nouveau)\src.nuget\nuget.targets

2) Identifiez la tâche référençant l’ancienne DLL.

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

3) Puis la preuve future comme ça:

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

À partir de VS2013, vous devriez exécuter MSBuild à partir de C:\Program Files (x86)\MSBuild\12.0\Bin \ 

pas de C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Voir 

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

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

cela a résolu le problème pour moi.

4
Ranadheer Reddy

Après de nombreuses recherches et avoir essayé un tas de "bidouilles", j'ai ensuite compris la mécanique exacte de la restauration de pépites. En fait, tout a changé depuis Nuget 2.7+ et vous n’êtes plus obligé d’inclure le dossier ".nuget" et les fichiers nuget.exe et nuget.target associés.

Pour corriger mon processus de génération et utiliser la dernière approche recommandée, j'ai procédé comme suit:

  • Déplacer nuget.config pour qu’il soit avec le fichier .sln même chemin du dossier
  • Supprimer le dossier ".nuget" entièrement
  • Supprimer les références à ce dossier dans le fichier .sln
  • Supprimer les lignes suivantes de tout fichier .csproj

-

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

-

Cela peut prendre un certain temps si votre solution de projet contient de nombreux fichiers ou si vous travaillez sur de nombreux projets construits avec Visual Studio 2013 et versions antérieures.

La bonne nouvelle est qu’il existe un script PowerShell qui applique ce qui précède de manière récursive à n’importe quel dossier:

En bref, il inverse "Enable Nuget Package Restore", autorisant le nouvelle méthode de restauration de paquet pour fonctionner.

Dans Visual Studio 2013, la restauration automatique du package est devenue partie intégrante du fichier IDE (et le processus de construction de TFS). Cette méthode est plus fiable que le ancien, restauration de package intégré msbuild. Cela ne vous oblige pas à avez vérifié que nuget.exe est bien connecté à chaque solution et n’a pas besoin de des cibles msbuild supplémentaires. Toutefois, si vous avez les fichiers liés à l’ancienne méthode de restauration de package dans votre projet, Visual Studio utilisera ignorer la restauration automatique du paquet. (Ce comportement est susceptible de changer Bientôt, espérons-le.).

Vous pouvez utiliser ce script pour supprimer nuget.exe, nuget.targets et tous les fichiers références de projet et de solution à nuget.targets afin que vous puissiez prendre avantage de la restauration automatique du paquet. Il automatise plus ou moins le processus décrit ici.

Il va recurse à travers le répertoire à partir duquel vous exécutez le script et faites-le cela à des solutions qui peuvent être là quelque part. Soyez prudent et s'amuser! (pas responsable de tout ce qui casse)

Quelques bons liens sur le sujet:

2
Korayem

J'ai eu un problème similaire. Nous sommes obligés d'utiliser l'ancienne version de msbuild fournie avec le framework, plutôt que la version v14 fournie avec visual studio 2015, car nous avons créé du vieux code Delphi.net. Nos fichiers vcxproj déclenchent une cible d’analyse de code automatique dont la tâche repose sur Microsoft.Build.Tasks.v12.0.dll. J'ai pu remplacer cette tâche en la copiant et en la collant dans la partie supérieure de vcxproj et en modifiant le chemin d'accès à la dll. La tâche d'origine se trouve dans "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.Targets". En d'autres termes, vous pourrez peut-être remplacer la tâche problématique de votre projet.

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