Cuando me registré en el código, TFS 2013 construyó la solución de forma automática. Está bien en local VS 2013, pero no 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\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.0\bin\amd64\Microsoft.Build.Tasks.v4.0.dll". Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild.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)
InformationsquelleAutor | 2013-12-18

4 Comentarios

  1. 55

    Su TFS 2013 servidor de generación es el uso de MSBuild 12.0 donde CodeTasksFactory existe en Microsoft.Build.Tasks.v12.0.dll en lugar de Microsoft.Build.Tasks.v4.0.dll.

    Idealmente, usted debe hacer lo siguiente:

    1) Abrir el NuGet.objetivos archivo:
    C:\Builds\1\xxxx\FTP Procesador (Nueva)\src.nuget\nuget.objetivos

    2) Identificar la tarea hace referencia a la DLL anterior.

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

    3), Entonces el futuro es así:

    <UsingTask AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v$(MSBuildToolsVersion).dll" TaskFactory="CodeTaskFactory" >
    ...
    • Se encuentra el hecho, de que puede cambiar el nuget.objetivos archivo. Pero, ¿necesitamos cambiar el ToolsVersion valor en csproj archivo? En realidad mi local de uso de la máquina VS 2013, mi TFS utiliza la versión antigua.
    • Puede cambiar el valor en su .archivo csproj, pero otra opción es reemplazar que el uso de la toolsversion interruptor cuando se llama a msbuild.exe. msdn.microsoft.com/en-us/library/bb383985.aspx
    • Voy a actualizar, gracias.
    • Tuve que hacer este cambio Y corregir mis archivos de Proyecto para establecer ToolsVersion=»12.0″ en lugar de 4.0.
    • sin embargo, tenga cuidado: stackoverflow.com/a/32455949/1244816
  2. 2

    Después de mucho investigar y probar un montón de «hacks» me fui a comprender exactamente la mecánica de nuget de restauración. Resulta que todo ha cambiado desde nuget 2.7+ y ya no es necesario incluir «.nuget» de la carpeta y los asociados nuget.exe y nuget.objetivo

    A arreglar mi proceso de generación y uso de la última enfoque recomendado, hice lo siguiente:

    • Mover nuget.config para estar con ella .archivo sln misma ruta de la carpeta de
    • Eliminar «.nuget» carpeta totalmente
    • Eliminar las referencias a dicha carpeta .archivo sln
    • Eliminar 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 tomar algún tiempo si su solución de proyecto tiene muchos archivos o trabajar en muchos proyectos construidos con Visual Studio 2013 y antes.

    La buena noticia es que hay un script de powershell que se aplica la anterior de forma recursiva en cualquier carpeta:

    En definitiva, se invierte «Habilitar el Paquete de Nuget de Restauración», permitiendo a la
    más reciente paquete de restauración de método de trabajo.

    En Visual Studio 2013, automático, paquete de restauración se convirtió en parte de la
    IDE (y el TFS proceso de construcción). Este método es más fiable que el
    mayores, msbuild paquete integrado de restauración. No requiere que usted
    han nuget.exe comprueba en cada solución y no requiere ningún tipo de
    adicionales objetivos de msbuild. Sin embargo, si usted tiene los archivos relacionados a
    el paquete antiguo método de restauración en el proyecto, Visual Studio
    saltar automática del paquete de la restauración. (Este comportamiento es probable que el cambio
    pronto, esperemos que sí).

    Puede utilizar esta secuencia de comandos para quitar nuget.exe, de nuget.objetivos, y todos los
    proyecto y solución de referencias a nuget.los objetivos de modo que usted puede tomar
    ventaja de Automática Paquete de Restauración. Es más o menos automatiza el
    el proceso que se describe aquí.

    Que se llame a sí misma a través del directorio de ejecutar la secuencia de comandos y hacer
    a las soluciones que pueden estar en alguna parte. Tenga cuidado y
    divertirse! (no se hace responsable de cualquier cosa que se rompe)

    Un par de buenos enlaces sobre el tema:

  3. 0

    Yo tenía un problema similar. Estamos forzados a usar la mayor msbuild que viene con el marco, más que la v14 versión que viene con visual studio 2015, ya que podemos construir algunos de los antiguos Delphi.net código. Nuestro vcxproj archivos de los reajustes automáticos de análisis de código de destino que tiene una tarea que se basa en Microsoft.Build.Tasks.v12.0.dll. Yo era capaz de anular la tarea de copiar y pegar en la parte superior de la vcxproj y el ajuste de la ruta de acceso a la dll. La tarea original se puede encontrar en «C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.Objetivos». Así que, en otras palabras, usted podría ser capaz de anular el problema de la tarea en el 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>  

Dejar respuesta

Please enter your comment!
Please enter your name here