Librerie di terze parti in un progetto C # open source

Se nuget non è disponibile, il modo più pulito potrebbe essere quello di fornire uno script di esportazione che estrae il codice sorgente della libreria necessaria dal proprio repository esterno (del fornitore della libreria) nella propria directory di lavoro. Questo funzionerà anche se il sistema SCC delle librerie esterne è diverso da Git (purché abbia un'interfaccia a linea di comando). EDIT: funzionerà anche quando il codice sorgente non è disponibile in alcun sistema SCC, proprio come ftp o http, ad esempio.

È possibile integrare lo script nel processo di creazione, naturalmente. Quando usi Visual Studio, come hai detto, puoi scrivere un classico Makefile (usando NMake), o usare MSBuild per chiamare quello script quando la lib esterna non è nella tua directory di lavoro. Forse l'approccio più semplice è quello di aggiungere lo script a un evento pre-build, i dettagli dipendono molto da come è organizzato il resto del processo di generazione.

Ho il sospetto che potrei avere downvoted per questo, ma ho voluto buttarlo fuori comunque.

Penso che includere le DLL stesse non sia davvero una cattiva idea.

Certo, non sono testo ; ma questo è vero per molti tipi di risorse che comunemente sono inclusi nei repository sorgente (ad es. immagini).

Certo, non puoi davvero differire loro; ma questo è vero per altre risorse compilate che sono anche spesso incluse nei repository (ad esempio, file JavaScript compressi mininosi e compressi).

In generale, non dovrebbero essere molto grandi (raramente vedo DLL che sono più di una Mb o due); nondimeno gonfiare il tuo repository e renderlo noioso da clonare non dovrebbe essere un problema, neanche.

Riconosco che NuGet è lo standard di fatto per la gestione delle dipendenze esterne in .NET. Tuttavia, nel caso in cui un pacchetto NuGet non sia disponibile per la libreria che si desidera utilizzare, penso davvero che includere la DLL sia l'approccio meno doloroso, senza alcun inconveniente gravemente orribile che riesco a vedere.

Si presume che non si aggiornino frequentemente queste DLL (ad esempio, sono librerie che hanno raggiunto la maturità e rilasciano nuove versioni su una base non frequente al massimo). In questo caso, la cartella contenente le DLL è un'istantanea delle dipendenze in qualsiasi punto della cronologia. Quando aggiorni la tua dipendenza, puoi semplicemente aggiornare la DLL.

Se, d'altra parte, queste sono librerie che cambiano molto frequentemente (ad esempio, sono le tue proprie librerie a cui stai lavorando in parallelo con questo progetto), quindi prendo indietro tutto ciò che ho appena detto. Non vuoi ingombrare la cronologia Git con aggiornamenti DLL costanti. In questo caso, in realtà suggerirei di saperne di più sui sottomoduli Git , o usando Idea di script di Do Brown .