Qual è il modo migliore per gestire i riferimenti in un'applicazione .NET

Direi che nuget è il modo migliore per gestire le dipendenze.

nuget può gestire le versioni E scaricare automaticamente le dipendenze dal server nuget locale .

È abbastanza facile creare / configurare un server locale. Crea semplicemente un nuovo progetto ASP.NET vuoto e installa il pacchetto nuget-server nuget (usando nuget;).

Questo significa anche che non dovrai controllare tutte le dipendenze e / o gestire le loro versioni usando TFS.

Non è proprio così - Microsoft dice che il modo migliore per gestire i riferimenti è quello di costruire il tuo progetto in un'unica soluzione. Sì, lo so, lo vogliono davvero anche loro.

Il team di modelli e pratiche ha inserito best practice insieme a TFS, ma si applica alle build generali. Esistono 3 tipi di configurazione della soluzione, la "1 soluzione grande", un approccio partizionato che assomiglia molto a come la maggior parte delle persone usava gestire le build costruendo a sua volta e copiando gli artefatti in una directory comune (che non è stata aiutata da .NET avere un percorso "include" o "libreria" per riferimento da parte del server) e una configurazione a soluzioni multiple che è una versione più complessa di quella partizionata.

Dicono

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

Per TFS raccomandano di ramificare qualsiasi progetto esterno all'interno del progetto, piuttosto che affidarsi alla mappatura dello spazio di lavoro che è più simile agli esterni di sovversione. Personalmente, penso che i loro consigli non siano le migliori pratiche, ma suppongo che stiano cercando di minimizzare eventuali problemi di build che si otterranno usando i riferimenti.

Ho avuto problemi con le build di .NET che provano a collegare il sistema costruendo solo ciò che è necessario, una build notturna che fa tutto e copia ogni nuovo assembly in una directory era il modo migliore per tutti di mantenere la sincronizzazione, specialmente i tester. Nota: questo si applica solo alle app .NET, quelle C ++ funzionano ancora perché non hanno assembly versionati o aspetti simili che possono causare problemi con i componenti di chiamata. Questo approccio funziona bene, ma non si può sempre presumere che le build parziali siano ok, svapare il tutto e ricostruire è più sicuro.

Dipende dal modo in cui la soluzione è strutturata e da quali sono le capacità del software di controllo della versione. In precedenza, tenevamo un progetto non montato / ignorato nelle nostre soluzioni che contenevano la documentazione e una cartella appositamente per le librerie di riferimento di terze parti. Poiché faceva parte della soluzione, il percorso di questi file poteva essere referenziato utilizzando il percorso relativo. Dopo il passaggio a TFS 2010, ci siamo sbarazzati di questo progetto e abbiamo semplicemente aggiunto una directory "Support" nella cartella di quella soluzione nel progetto di team parallelo alle nostre filiali principali. In entrambi i casi, la versione di controllo del codice sorgente della libreria finisce nello stesso posto, indipendentemente dal modo in cui gli sviluppatori hanno configurato le macchine.

Quando utilizzi subversion per il controllo della versione, puoi utilizzare la proprietà "esterni" per questo scopo. Ciò consente di mantenere una copia locale di una DLL condivisa in un percorso relativo vicino al progetto corrente. In questo modo è facile fare riferimento a tale DLL tramite un percorso file relativo che non cambia, anche quando si modifica la directory principale del progetto in una cartella diversa. Gli esterni ti permettono anche di definire quale versione specfic o revisione includere.