2012-11-07 25 views
11

Sto spostando il nostro codice sorgente da Vault a TFS, non preoccupandomi della migrazione o di altro, semplicemente tirando un ultimo nel Vault e aggiungendolo a TFS.NuGet Package Restore non ripristina pacchetti su build

La soluzione ha diversi progetti e ognuno ha almeno un pacchetto NuGet. Sto cercando di far funzionare di nuovo Package Restore. Ha funzionato in Vault (ma non nel modo in cui avrebbe dovuto). Avevo poco tempo, e all'inizio non funzionava, quindi ho aggiunto un evento Pre-Build per eseguire nuget.exe su packages.config per ogni progetto.

Il servizio di compilazione di TFS si lamenta di ciò, quindi sto cercando di farlo funzionare "correttamente".

  1. Ho impostato l'opzione nel menu Strumenti di Visual Studio.
  2. Ho installato NuGetEnablePackageRestore ed eseguito la correzione.
  3. Ho verificato che la directory dei pacchetti è il controllo del codice sorgente, ma è vuota.
  4. Ho verificato che i file di progetto di ogni sono i seguenti:
<RestorePackages>true</RestorePackages> 
<Import Project="$(SolutionDir)\.nuget\nuget.targets" /> 

Edificio con verbosità livello di diagnostica rivela che ogni progetto valuta tali proprietà, ma la RestoreCommand in nuget.targets non è mai eseguito.

Qualche idea?

ho cercato di implementare le soluzioni da questi link:

  1. nuget - package restore not working
  2. NuGet Package Restore Not Working - ho fatto inviare una domanda/commento sulla lì per chiedere chiarimenti ...
  3. http://nuget.codeplex.com/workitem/1879

Modifica

Annuncio dizionalmente, ho trovato che la proprietà RestoreCommand è stata valutata durante la compilazione. Verbosità diagnostico presenta:

RestoreCommand = (set EnableNuGetPackageRestore=true) && "C:\Source\Kiersted Direct And Related\Direct\Kiersted\.nuget\nuget.exe" install "packages.config" -source "@(PackageSource)" -o "C:\Source\Kiersted Direct And Related\Direct\Kiersted\packages" 

risposta

10

ho capito, e ho trovato la risposta qui: MSBuild not running BuildDependsOn tasks from an imported project

Il problema (dopo aver guardato attraverso l'uscita prolissità accumulo di diagnosi) è stato che l'impostazione BuildDependsOn stava diventando un-set . Il mio progetto file ognuno aveva l'istruzione import

<Import Project="$(SolutionDir)\.nuget\nuget.targets" /> 

ma questa affermazione era all'inizio della struttura XML. Apparentemente l'importazione per Microsoft.CSharp.targets può interferire con quella importazione e quindi con BuildDependsOn.

La mia soluzione era spostare l'importazione nuget.targets sotto l'importazione Microsoft.CSharp.targets. Ora tutto si costruisce magnificamente.

+1

Grazie per le informazioni. Tuttavia, la mia istruzione di importazione è già dopo l'importazione di Microsoft.CSharp e riceverò lo stesso errore. Continuerò a scavare e vedere cosa sta succedendo qui. –

+1

Nell'output di Build, prova a specificare Diagnostica. Emette un'enorme quantità di registrazione, ma il problema è lì da qualche parte. È così che ho capito il mio. – CodeWarrior

+0

Questo avviso viene visualizzato come avviso: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (1605): Impossibile risolvere questo riferimento. Impossibile trovare l'assembly "MongoDB.Bson". Verificare che l'assieme esista su disco. Se questo riferimento è richiesto dal codice, è possibile che si verifichino errori di compilazione. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (1605): Impossibile risolvere questo riferimento. Impossibile trovare l'assembly "MongoDB.Driver". Verificare che l'assembly esista su disco. Se questo riferimento è richiesto dal tuo codice, potresti ricevere errori di compilazione –

Problemi correlati