Restauración NuGet falla cuando la dependencia agrega una importación .targets a .csproj

Question

Me encontré con un problema recientemente con la restauración de NuGet. Agregué una dependencia de proyecto (en este caso PostSharp) y luego habilité la restauración. Revisé la fuente, pero no el directorio/packages (como no debería necesitar ... ¡correcto!). Cuando TeamCity u otro desarrollador agarra la fuente y se ejecuta MSBUILD, que reciben el error siguiente:

C:\TeamCity\buildAgent\work\e374975c0264c72e\ProjectName\ProjectName.csproj(70, 3): error MSB4019: The imported project "C:\TeamCity\buildAgent\work\e374975c0264c72e\packages\PostSharp.2.1.5.1\tools\PostSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. 

El problema es, NuGet aún no se ha ejecutado para restaurar/o descarga PostSharp Es .targets archivo. Esto se siente como un error NuGet para mí, pero quería ver si otros tienen el mismo problema.

Cualquiera tiene este problema o conoce la resolución. Sí, podría registrarme en el directorio/packages, pero ¿por qué utilizar NuGet?

Answer 1

@ porterhouse91, ¿ha comprobado su archivo csproj para asegurarse de que se ha configurado con el objetivo de compilación adecuado?
Aún no he probado la nueva función incorporada de Restauración de paquetes, pero supongo que funciona al menos algo así como los flujos de trabajo anteriores que existen en las interwebs. Si ese es el caso, habilitar la Restauración de paquetes en su solución solo afecta los proyectos en su solución al momento de habilitarlo. Si ha agregado un nuevo proyecto (que tiene dependencias NuGet) a la solución ya que habilita Restauración de paquetes, tendrá que habilitarlo de nuevo. Otra posibilidad: los flujos de trabajo anteriores implicaban tener una carpeta .nuget que necesitara registrar en VCS, por lo que es posible que deba verificarla si todavía no se ha registrado (si la función incorporada de Restauración de paquetes sí lo hace) usa este enfoque).

Por cierto, si esta respuesta es del todo útil, gracias Stephen Ritchie - me pidió que le diera una oportunidad.

Answer 2

Tuve un problema como este también, pero pude modificar el archivo .targets en el paquete fuente para evitarlo. Básicamente, RestorePackages es un objetivo de compilación que se ejecuta cuando se construye el proyecto. Desafortunadamente, el paquete ni siquiera se cargará correctamente antes de que se satisfagan las importaciones. La única manera que conozco de solucionar esto es incluir el archivo .targets como contenido y luego cambiar la propiedad BuildDependsOn para que restaure los paquetes antes de que ejecute las tareas personalizadas.

<PropertyGroup> 
    <BuildDependsOn Condition="$(BuildDependsOn.Contains('RestorePackages'))"> 
    RestorePackages; 
    CustomTarget; 
    $(BuildDependsOn); 
    </BuildDependsOn> 
    <BuildDependsOn Condition="!$(BuildDependsOn.Contains('RestorePackages'))"> 
    CustomTarget; 
    $(BuildDependsOn); 
    </BuildDependsOn> 
</PropertyGroup> 

Para ser claros, esto no ayuda con paquetes pre-construidos, pero si se puede construir el paquete de nuevo a sí mismo, se puede arreglar.

Answer 3

Me encontré con este mismo problema con Visual Studio 2012 y paquetes NuGet no controlados en el control de código fuente.

El error:

The imported project "\packages\Microsoft.Bcl.Build.1.0.7\tools\Microsoft.Bcl.Build.targets" was not found. 
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. 

he encontrado una MSDN writeup en la situación que dio las siguientes soluciones para agarrar un proyecto de control de origen de los paquetes sin NuGet.

1. Deje de usar paquete de restaurar y check-in totalidad de los paquetes
2. paquete explícitamente de restauración antes de ejecutar la construcción del proyecto
3. Registro de los archivos .targets

decidí ir con la opción # 2, sin embargo, NuGet actualmente (v2.6) no incluye una forma de instalar todos los paquetes del archivo packages.config desde Visual Studio.Algunas búsquedas revelaron que necesita utilizar NuGet Command Line para ejecutar el siguiente comando antes de abrir Visual Studio (reference).

c:\path\to\nuget.exe install -o packages project-folder\packages.config 

Answer 4

Otro enfoque es modificar el elemento <Import> en cuestión, para que sea condicional, por ejemplo .:

<Import Project="$(CodeAssassinTargets)" Condition="Exists($(CodeAssassinTargets))" /> 

Esto depende de una nueva propiedad se define en una anterior <PropertyGroup>. Yo suelo añadir una en la parte superior del archivo de csproj con otras banderas "globales", por ejemplo:

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
     <CodeAssassinTargets>$(SolutionDir)packages\CodeAssassin.ConfigTransform.1.1\tools\CodeAssassin.ConfigTransform.targets</CodeAssassinTargets> 
     <AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings> 
     <UseMsdeployExe>true</UseMsdeployExe> 
    </PropertyGroup> 

Luego, en un objetivo apropiado, como BeforeBuild, da un mensaje de error útiles:

<Target Name="BeforeBuild"> 
    <Error Text="CodeAssassin.ConfigTransforms target is missing. It needs to exist at $(CodeAssassinTargets) in order to build this project!" Condition="!Exists($(CodeAssassinTargets))" /> 
</Target> 

Con estos modificaciones, el proyecto se cargará incluso si la restauración del paquete nuget nunca se ha realizado. Si la restauración automática del paquete está habilitada, el primer intento de compilación debe aclarar el problema del objetivo faltante, pero si no lo hace, se realizará una restauración manual del paquete.