Sistemi di gestione delle dipendenze .NET

NuGet sarebbe probabilmente la mia risposta. Dopo aver lavorato sul precursore (Nu), che era appena seduto sopra RubyGems, posso dire che avere risorse per qualcosa aiuta. Ora, una volta che lavoro mi sono ritrovato con una versione rattoppata dell'eseguibile perché avevamo un repository locale oltre a quelli remoti. Non sono sicuro che abbiano risolto il problema o meno, ma dal momento che accettano le patch, dovrebbe essere facile correggerle. Su tutti i progetti open source nell'arena .NET su cui lavoro ora facciamo tutto attraverso NuGet. È molto più semplice, anche se pubblicare la catena richiede un po 'di tempo.

OpenWrap è un'opzione, ma tutto ha bisogno di essere costruito. Che è un po 'un dolore nel sedere. Se non riesci a ottenere il progetto giusto, ci vuole un po 'di tempo per occuparsene. Openwrap ha cercato di risolvere questo problema per molto tempo ed è ancora davvero imbarazzante. La distribuzione solo binaria è molto più semplice (a volte) ...

Gli altri due con cui non ho familiarità. Quindi non posso commentare su di loro una tonnellata.

Ho appena scaricato l'ultima versione di NuGet per vedere cosa è cambiato dall'ultima volta. Per favore correggimi se ho torto (sto davvero pensando di migrare la mia roba su nuget):

I pacchetti NuGet non specificano ancora una "piattaforma" come dipendenza del pacchetto. Ho appena installato "Ninject" e ha fatto riferimento alla versione .NET 4.0 in una sottocartella "pacchetti". Suppongo sia stata una buona ipotesi visto che il mio progetto è in 4.0, ma è abbastanza pericoloso supporre. Non capisco quale piattaforma verrà selezionata dalla dipendenza dei pacchetti.

"Package Restore" trasforma la mia soluzione aggiungendo un passo pre-build personalizzato. Non mi piace qualcosa che modifica i file della mia soluzione, ma non è un problema. Non capisco quanto spesso controlli le nuove versioni (mi piacerebbe impostare una frequenza per i repository privati abbastanza spesso).

Potrei essermi completamente sbagliato qui, tuttavia sembra che nuget non aggiorni automaticamente la dipendenza del progetto quando viene aggiornata una versione del pacchetto. Package Restore creerà una nuova sottocartella per una nuova versione del pacchetto, tuttavia devo scegliere manualmente quella cartella da Visual Studio cancellando preventivamente il riferimento.

Alcuni pacchetti (come jQuery) eseguiranno uno script PowerShell incorporato all'avvio. Non mi piacciono davvero le esecuzioni personalizzate e la dipendenza PS, che non è sempre presente in Windows e manca completamente nei build Mono non Windows. A proposito, come ho già detto in precedenza MSBuild, anche questa dipendenza potrebbe non essere realistica per soddisfare alcune build di C ++ (altrimenti mi mancherà la funzionalità di Restore dei pacchetti?).

L'ultimo potrebbe non essere così importante, tuttavia ci vuole un po 'di tempo per ripristinare le dipendenze quando ne ho un bel po'.

NuGet è ancora l'opzione migliore a questo punto.

Il problema principale con NuGet come gestore delle dipendenze è che si pensava che fosse un gestore delle dipendenze del "tempo di sviluppo", non un gestore delle dipendenze "build time".

Uno sviluppatore ripristinerebbe un pacchetto NuGet attraverso Visual Studio ... e questo potrebbe eseguire uno script PowerShell durante il ripristino che modifica i file nel progetto.

Questo è diverso da altri sistemi di gestione delle dipendenze che ho visto, poiché l'aggiunta di una dipendenza e la sua risoluzione possono alterare il sistema facendo riferimento alla dipendenza.

Non esiste un meccanismo integrato per garantire o controllare l'idempotenza nello script PowerShell, quindi eseguirlo più volte sullo stesso set di file potrebbe non essere deterministico.

Sembra che molti utilizzino NuGet per caricare pacchetti attraverso Visual Studio durante il tempo di sviluppo, ma non sono a conoscenza di una solida raccomandazione su come dovrebbe funzionare su un server di build.