Ho una situazione simile con fonti di pacchetti interne ed esterne con progetti a cui si fa riferimento in più di una soluzione. Oggi ho appena funzionato con una delle nostre basi di codice e sembra funzionare con le workstation di sviluppo e il nostro server di build. Il processo seguente ha in mente questo scenario (anche se non dovrebbe essere difficile adattarsi per avere la cartella dei pacchetti comune dove altro).
- codebase
- Progetto A
- Progetto B
- Progetto C
- soluzioni
- Soluzione 1
- Soluzione 2
- Soluzione 3
- Pacchetti (questo è quello comune condiviso da tutte le soluzioni)
Risposta aggiornata a partire da NuGet 3.5.0.1484 con Visual Studio 2015 Update 3
Questo processo è un po 'più semplice ora rispetto a quando inizialmente l'ho affrontato e ho pensato che fosse tempo di aggiornarlo. In generale, il processo è lo stesso solo con meno passaggi. Il risultato è un processo che risolve o fornisce quanto segue:
- Tutto ciò che deve essere impegnato nel controllo del codice sorgente è visibile e tracciato nella soluzione
- L'installazione di nuovi pacchetti o l'aggiornamento di pacchetti mediante Gestione pacchetti in Visual Studio utilizzerà il percorso di repository corretto
- Dopo la configurazione iniziale, nessun hacking di file .csproj
- Nessuna modifica della workstation di sviluppo (il codice è pronto per il check out)
Ci sono alcuni aspetti negativi potenziali di cui essere a conoscenza (non li ho ancora sperimentati, YMMV). Vedi la risposta e i commenti del Benol di seguito.
Aggiungi NuGet.Config
Si desidera creare un file NuGet.Config nella radice della cartella \ Solutions \. Assicurati che questo sia un file codificato UTF-8 che crei, se non sei sicuro di come farlo, usa il menu File-> Nuovo-> File di Visual Studio e quindi scegli il modello File XML. Aggiungi a NuGet.Config quanto segue:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="$\..\Packages" />
</config>
</configuration>
Per l'impostazione repositoryPath, è possibile specificare un percorso assoluto o un percorso relativo (consigliato) utilizzando il token $. Il token $ si basa su dove si trova NuGet.Config (il token $ è effettivamente relativo a un livello al di sotto della posizione di NuGet.Config). Quindi, se ho \ Solutions \ NuGet.Config e voglio \ Solutions \ Pacchetti, dovrei specificare $ \ .. \ Pacchetti come valore.
Successivamente, vorrai aggiungere una cartella della soluzione alla tua soluzione chiamata "NuGet" (fai clic con il pulsante destro del mouse sulla soluzione, Aggiungi-> Nuova cartella della soluzione). Le cartelle della soluzione sono cartelle virtuali che esistono solo nella soluzione Visual Studio e non creeranno una cartella effettiva sull'unità (e puoi fare riferimento ai file da qualsiasi luogo). Fare clic con il tasto destro del mouse sulla cartella della soluzione "NuGet", quindi Aggiungi-> Articolo esistente e selezionare \ Soluzioni \ NuGet.Config.
Il motivo per cui lo stiamo facendo è che è visibile nella soluzione e dovrebbe aiutare a verificare che sia correttamente impegnato nel controllo del codice sorgente. È possibile che si desideri eseguire questo passaggio per ogni soluzione nella base di codice che partecipa ai progetti condivisi.
Posizionando il file NuGet.Config in \ Solutions \ sopra qualsiasi file .sln, stiamo sfruttando il fatto che NuGet navigherà ricorsivamente la struttura delle cartelle verso l'alto dalla "directory di lavoro corrente" alla ricerca di un file NuGet.Config da usare. La "directory di lavoro corrente" indica un paio di cose diverse qui, una è il percorso di esecuzione di NuGet.exe e l'altra è la posizione del file .sln.
Passare alla cartella dei pacchetti
Innanzitutto, ti consiglio vivamente di esaminare ciascuna delle cartelle della soluzione ed eliminare tutte le cartelle \ Pacchetti \ esistenti (dovrai prima chiudere Visual Studio). Ciò semplifica la visualizzazione della posizione in cui NuGet posiziona la cartella \ Pacchetti \ appena configurata e garantisce che eventuali collegamenti alla cartella \ Pacchetti \ errata non vadano a buon fine e possono quindi essere corretti.
Apri la tua soluzione in Visual Studio e dai il via a Ricostruisci tutto. Ignora tutti gli errori di build che riceverai, questo è previsto a questo punto. Tuttavia, ciò dovrebbe dare il via alla funzione di ripristino del pacchetto NuGet all'inizio del processo di compilazione. Verifica che la cartella \ Soluzioni \ Pacchetti \ sia stata creata nel punto desiderato. In caso contrario, rivedere la configurazione.
Ora, per ogni progetto nella tua soluzione vorrai:
- Fare clic con il tasto destro del mouse sul progetto e selezionare Scarica progetto
- Fare clic con il tasto destro del mouse sul progetto e selezionare Modifica your-xxx.csproj
- Trova eventuali riferimenti a \ pacchetti \ e aggiornali nella nuova posizione.
- La maggior parte di questi saranno riferimenti <HintPath>, ma non tutti. Ad esempio, WebGrease e Microsoft.Bcl.Build avranno impostazioni di percorso separate che dovranno essere aggiornate.
- Salvare il file .csproj e quindi fare clic con il tasto destro del mouse sul progetto e selezionare Ricarica progetto
Una volta che tutti i tuoi file .csproj sono stati aggiornati, dai il via a un altro Ricostruisci tutto e non dovresti più avere errori di compilazione sui riferimenti mancanti. A questo punto il gioco è fatto e ora NuGet è configurato per utilizzare una cartella di pacchetti condivisa.
A partire da NuGet 2.7.1 (2.7.40906.75) con VStudio 2012
Prima di tutto la cosa da tenere a mente è che nuget.config non controlla tutte le impostazioni del percorso nel sistema di pacchetti nuget. Ciò è stato particolarmente confuso da capire. In particolare, il problema è che msbuild e Visual Studio (chiamando msbuild) non usano il percorso in nuget.config ma piuttosto lo sovrascrivono nel file nuget.targets.
Preparazione dell'ambiente
Innanzitutto, vorrei passare attraverso la cartella della soluzione e rimuovere tutti i \ pacchetti \ cartelle esistenti. Ciò contribuirà a garantire che tutti i pacchetti vengano installati visibilmente nella cartella corretta e a rilevare eventuali riferimenti errati ai percorsi in tutte le soluzioni. Quindi, mi assicurerei di avere installato l'estensione nuget di Visual Studio più recente. Vorrei anche assicurarmi di avere l'ultimo nuget.exe installato in ogni soluzione. Aprire un prompt dei comandi e accedere a ciascuna cartella $ (SolutionDir) \ .nuget \ ed eseguire il comando seguente:
nuget update -self
Impostazione del percorso della cartella del pacchetto comune per NuGet
Aprire ogni $ (SolutionDir) \ .nuget \ NuGet.Config e aggiungere quanto segue nella sezione <configurazione>:
<config>
<add key="repositorypath" value="$\..\..\..\Packages" />
</config>
Nota: è possibile utilizzare un percorso assoluto o un percorso relativo. Tenere presente che se si utilizza un percorso relativo con $ che è relativo a un livello inferiore alla posizione di NuGet.Config (si ritiene che si tratti di un bug).
Impostazione del percorso della cartella del pacchetto comune per MSBuild e Visual Studio
Apri ogni $ (SolutionDir) \ .nuget \ NuGet.targets e modifica la seguente sezione (nota che per non Windows c'è un'altra sezione sotto di essa):
<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
<!-- Windows specific commands -->
<NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
<PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
<PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>
Aggiorna pacchetti Direttamente
<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>
Nota: GetFullPath risolverà il nostro percorso relativo in un percorso assoluto.
Ripristino di tutti i pacchetti nuget nella cartella comune
Apri un prompt dei comandi e vai a $ (SolutionDir) \ .nuget ed esegui il comando seguente:
nuget restore ..\YourSolution.sln
A questo punto, dovresti avere una singola cartella \ pacchetti \ nella tua posizione comune e nessuna all'interno delle cartelle della tua soluzione. In caso contrario, verifica i tuoi percorsi.
Correzione dei riferimenti al progetto
Apri tutti i file .csproj in un editor di testo e trova tutti i riferimenti a \ pacchetti e aggiornali nel percorso corretto. La maggior parte di questi saranno riferimenti <HintPath>, ma non tutti. Ad esempio, WebGrease e Microsoft.Bcl.Build avranno impostazioni di percorso separate che dovranno essere aggiornate.
Crea la tua soluzione
Apri la tua soluzione in Visual Studio e dai il via a una build. Se si lamenta di pacchetti mancanti che devono essere ripristinati, non dare per scontato che il pacchetto sia mancante e debba essere ripristinato (l'errore può essere fuorviante). Potrebbe essere un brutto percorso in uno dei tuoi file .csproj. Verificare prima di ripristinare il pacchetto.
Hai un errore di build relativo ai pacchetti mancanti?
Se hai già verificato che i percorsi nei tuoi file .csproj sono corretti, allora hai due opzioni da provare. Se questo è il risultato dell'aggiornamento del codice dal controllo del codice sorgente, puoi provare a estrarre una copia pulita e quindi a crearlo. Questo ha funzionato per uno dei nostri sviluppatori e penso che ci fosse un artefatto nel file .suo o qualcosa di simile. L'altra opzione è forzare manualmente un ripristino del pacchetto utilizzando la riga di comando nella cartella .nuget della soluzione in questione:
nuget restore ..\YourSolution.sln
$anteriore del relativo percorso. Inoltre, la risposta alla tua domanda sui file NuGet.Config è qui . Si cerca prima nella .nuget, poi in tutte le directory principali, quindi il file 'globale' nel vostro AppData: poi li applica in ordine inverso (qualunque sia che significhi).