2011-12-15 13 views
6

Recentemente ho riscontrato un problema con il ripristino NuGet. Ho aggiunto una dipendenza del progetto (in questo caso PostSharp) e poi ho abilitato il ripristino. Ho controllato la fonte, ma non la directory/packages (come non avrei dovuto fare per .... giusto!). Quando TeamCity o un altro sviluppatore afferra la fonte e corre MsBuild, ricevono il seguente errore:NuGet Restore non riesce quando la dipendenza aggiunge un'importazione .targets al .csproj

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. 

Il problema è, NuGet non è stato eseguito ancora il ripristino/download PostSharp o è .targets file. Questo mi sembra un bug di NuGet, ma volevo vedere se altri hanno lo stesso problema.

Chiunque ha questo problema o conosce la risoluzione. Sì, potrei effettuare il check-in nella directory/packages, ma perché utilizzare NuGet?

risposta

1

@ porterhouse91, hai controllato il file csproj per assicurarti che sia stato impostato con il target di build appropriato?
Non ho ancora provato la nuova funzionalità di Ripristino pacchetti integrata, ma presumo che funzioni almeno in qualche modo come i precedenti flussi di lavoro sul Web. In questo caso, l'abilitazione del ripristino dei pacchetti nella soluzione influisce solo sui progetti nella soluzione al momento in cui viene abilitata. Se hai aggiunto un nuovo progetto (con dipendenze NuGet) alla soluzione dopo aver attivato il ripristino dei pacchetti, dovrai attivarlo di nuovo. Un'altra possibilità: i flussi di lavoro precedenti riguardavano una cartella .nuget che dovevi controllare in VCS, quindi potresti doverlo controllare se non è ancora stato effettuato il check in (se la funzione di Ripristino pacchetti integrata è davvero utilizzare questo approccio).

BTW, se questa risposta è utile, grazie a Stephen Ritchie - mi ha chiesto di dargli una possibilità.

1

Ho avuto un problema come questo, ma sono stato in grado di modificare il file .targets nel pacchetto sorgente per aggirare il problema. Fondamentalmente, RestorePackages è un obiettivo di build che viene eseguito quando viene creato il progetto. Sfortunatamente, il pacchetto non verrà nemmeno caricato correttamente prima che le importazioni siano soddisfatte. L'unico modo per risolvere questo problema è includere il file .targets come contenuto e quindi modificare la proprietà BuildDependsOn in modo che ripristini i pacchetti prima di eseguire le attività personalizzate.

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

Per essere chiari, questo non aiuta con i pacchetti precompilati, ma se si può costruire di nuovo il pacchetto da soli, si può risolvere il problema.

0

Mi sono imbattuto in questo stesso problema con Visual Studio 2012 e pacchetti NuGet non controllati nel controllo del codice sorgente.

L'errore:

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. 

ho trovato un msdn writeup sulla situazione che ha dato le seguenti soluzioni alternative per afferrare un progetto dal controllo di origine, senza i pacchetti Nuget.

  1. Smettere di usare il pacchetto di ripristino e il check-in tutti i file del pacchetto restauro
  2. pacchetto esplicitamente eseguire prima di costruire il progetto
  3. Check-in file .targets

ho deciso di andare con l'opzione # 2, tuttavia, attualmente NuGet (v2.6) non include un modo per installare tutti i pacchetti dal file packages.config da visual studio.Alcune ricerche hanno rivelato che è necessario utilizzare NuGet Command Line per eseguire il seguente comando prima di aprire Visual Studio (reference).

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

Un altro approccio è quello di modificare l'elemento <Import> in questione, per renderla condizionale, es .:

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

Questo dipende da una nuova proprietà definita in una precedente <PropertyGroup>. Io di solito aggiungere uno nella parte superiore del file di csproj con altre bandiere "globali", ad esempio:

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

Poi, in un obiettivo appropriato, come BeforeBuild, invia un messaggio di errore utile:

<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 questi modifiche, il progetto verrà caricato anche se il ripristino del pacchetto nuget non è mai stato fatto. Se il ripristino automatico del pacchetto è abilitato, il primo tentativo di build dovrebbe risolvere il problema dell'obiettivo mancante, ma in caso contrario verrà eseguito un ripristino del pacchetto manuale.

Problemi correlati