2015-04-02 10 views
22

Ho già cercato ampiamente una soluzione, ho provato approcci diversi ma nessuno ha funzionato, quindi mi sto chiedendo qui.NuGet e Git Submodules

La mia attuale necessità è di avere repository Git separati contenenti ciascuno un file di soluzione .Net con progetti correlati. Uno o più di questi repository conterranno solo le librerie di classi e ho bisogno di usare quelle librerie all'interno di altre soluzioni di repository.

Il mio primo pensiero è stato quello di utilizzare Git Submodule per evitare la brutta copia-incolla e avere ancora il codice sorgente delle librerie di classi disponibili durante lo sviluppo delle applicazioni.

Quindi il mio tentativo era includere il sottomodulo, quindi nella mia attuale soluzione fare "aggiungi progetto esistente" e caricare la libreria di classi desiderata.

L'enorme problema che non riesco a superare è il ripristino del pacchetto Nuget. I progetti importati riferimento biblioteche in ".. \ Packages *", ma se importati come modulo si trovano in una sottocartella supplementare in modo non riescono a trovare le dipendenze richieste:

- MySolution.sln 
- Packages folder 
- MyAppProject folder 
- Submodule folder 
-- EXPECTED packages folder for MyLibraryProject that I cannot generate 
-- MyLibraryProject folder 

Una soluzione che ho trovato e provato era this ma ha due problemi principali:

  • si suppone di lavorare utilizzando il ripristino pacchetto MsBuild e io assolutamente non voglio usarlo
  • Anche cercando di usare il pacchetto MsBuild il ripristino non ha funzionato affatto, mi avere ancora una singola cartella Packages nella mia attuale cartella della soluzione. Forse ho fatto qualcosa di sbagliato ma, di nuovo, non voglio usare l'approccio di MsBuild.

Ora mi piacerebbe sapere se c'è un modo pulito per risolvere questo problema, o se l'unica cosa che posso fare è rinunciare ad avere il codice sorgente delle biblioteche disponibile nelle mie soluzioni applicative e pubblicare le mie librerie su un feed NuGet privato e fare riferimento a loro da lì.

Grazie.

+1

Avete considerato l'utilizzo di NuGet per MyLibraryProject anziché i sottomoduli git? Eseguire un server NuGet locale, generare un pacchetto NuGet per la libreria e aggiungere un riferimento a tale nella propria app. Solo un'opzione ... –

+0

Grazie per il tuo suggerimento. Ho davvero preso in considerazione questa opzione, ma stiamo pensando di utilizzare un servizio di CI online come AppHarbor e che ci obbligherebbe a utilizzare un servizio pubblico (a pagamento) come Nuget, come MyGet, per poter ripristinare i pacchetti dal Server CI, e vorremmo evitarlo. –

+0

Ok. E devi avere i due livelli di directory per il progetto della biblioteca? (La directory del sottomodulo potrebbe essere solo la directory del progetto della libreria stessa?) –

risposta

5

Sembra che il problema sia che i progetti dal sottomodulo si trovano in un diverso livello di directory rispetto alla soluzione del repository. Questo è un problema di Nuget comune perché ripristina a livello di soluzione. Qui è possibile utilizzare lo script del percorso del suggerimento di correzione per sostituire i riferimenti con $ (SolutionDir) e probabilmente risolvere il problema. https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/README.md#fixhintpathsps1

+0

Vedo che c'è uno script PowerShell pulito che corregge gli hintpaths in modo da poterlo scrivere. Valuterò questa possibile soluzione, grazie. –

+0

Questo ha funzionato per te? – mshish

+0

Anche se questo è davvero fattibile, siamo ancora nel processo decisionale, anche se sembra che useremo Nuget per le dipendenze interne invece dei sottomoduli git, come suggerito da @ jon-skeet. –

Problemi correlati