descargar - Build en TFS 2013 falló pero está bien localmente

tfs 2017 sql server requirements

Question

Cuando registré el código, TFS 2013 construyó la solución automáticamente. Está bien en VS 2013 local pero falló en TFS.

Aquí está el resumen.

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

A partir de VS2013, debe ejecutar MSBuild desde C: / Archivos de programa (x86) / MSBuild / 12.0 / Bin /

no desde C: / Windows / Microsoft.NET / Framework64 / v4.0.30319. Ver

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

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

resolvió el problema para mí.

Answer 2

Después de mucha investigación y probar un montón de "hacks", entendí la mecánica exacta de la restauración nuget. Resulta que todo ha cambiado desde nuget 2.7+ y ya no es necesario incluir la carpeta ".nuget" y los nuget.exe y nuget.target asociados.

Para arreglar mi proceso de compilación y utilizar el último enfoque recomendado, hice lo siguiente:

• Mover nuget.config para estar con el archivo .sln misma ruta de la carpeta
• Eliminar la carpeta ".nuget" por completo
• Eliminar referencias a esa carpeta en el archivo .sln
• Eliminar las siguientes líneas de cualquier archivo .csproj

-

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

-

Esto podría llevar algo de tiempo si la solución de su proyecto tiene muchos archivos o si trabaja en muchos proyectos creados con Visual Studio 2013 y versiones anteriores.

La buena noticia es que hay un script de PowerShell que aplica lo anterior de forma recursiva en cualquier carpeta:

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

En resumen, invierte "Enable Nuget Package Restore", lo que permite que funcione el nuevo método de restauración de paquetes.

En Visual Studio 2013, la restauración automática de paquetes se convirtió en parte del IDE (y del proceso de compilación TFS). Este método es más confiable que el anterior, la restauración del paquete integrado msbuild. No requiere que tenga nuget.exe registrado en cada solución y no requiera ningún objetivo adicional de msbuild. Sin embargo, si tiene los archivos relacionados con el antiguo método de restauración del paquete en su proyecto, Visual Studio omitirá la restauración automática del paquete. (Es probable que este comportamiento cambie pronto, con suerte lo hará).

Puede utilizar esta secuencia de comandos para eliminar nuget.exe, nuget.targets y todas las referencias de proyectos y soluciones a nuget.targets para que pueda aprovechar la restauración automática de paquetes. Más o menos automatiza el proceso descrito aquí.

Recurrirá a través del directorio desde el que ejecuta el script y lo hará a cualquier solución que pueda estar allí en alguna parte. ¡Ten cuidado y diviértete! (no se hace responsable por nada que se rompa)

Un par de buenos enlaces sobre el 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 3

Su servidor de compilación TFS 2013 está utilizando MSBuild 12.0 donde CodeTasksFactory existe en Microsoft.Build.Tasks.v12.0.dll en lugar de Microsoft.Build.Tasks.v4.0.dll.

Idealmente, deberías estar haciendo lo siguiente:

1) Abra su archivo NuGet.targets: C: / Builds / 1 / xxxx / FTP Processor (Nuevo) / src.nuget / nuget.targets

2) Identificar la tarea que hace referencia a la antigua DLL.

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

3) Entonces, prueba futura como esta:

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

Answer 4

Tuve un problema similar. Nos vemos obligados a utilizar el msbuild más antiguo que viene con el framework, en lugar de la versión v14 que viene con visual studio 2015 porque construimos un viejo código Delphi.net. Nuestros archivos vcxproj están activando un objetivo de análisis de código automático que tiene una tarea que se basa en Microsoft.Build.Tasks.v12.0.dll. Pude anular esa tarea copiándola y pegándola en la parte superior de vcxproj y modificando la ruta al dll. La tarea original se puede encontrar en "C: / Archivos de programa (x86) / MSBuild / Microsoft / VisualStudio / v14.0 / CodeAnalysis / Microsoft.CodeAnalysis.Targets". Entonces, en otras palabras, es posible que pueda anular la tarea problemática en su proyecto.

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