Di recente al lavoro ci siamo imbattuti in un problema in cui abbiamo taggato / ramificato un progetto e abbiamo avuto alcuni problemi di compilazione a causa dei riferimenti dll / project che puntavano alla vecchia struttura di cartelle.
Abbiamo creato una cartella 'bin esterno' per ciascuno dei progetti e copiato le DLL di riferimento in queste cartelle. È questo il modo migliore o esiste uno standard industriale specifico per gestirlo?
Risposte:
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. Basta creare un nuovo progetto ASP.NET vuoto e installare il nuget-serverpacchetto nuget (usando nuget;).
Ciò significa anche che non sarà necessario archiviare tutte le dipendenze e / o gestirne le versioni utilizzando TFS.
Non è proprio così: Microsoft afferma che il modo migliore per gestire i riferimenti è costruire il tuo progetto in un'unica grande soluzione. Sì, lo so, lo significano davvero anche loro.
Il team di modelli e pratiche ha messo insieme le migliori pratiche in relazione a TFS, ma si applica alle build generali. Esistono 3 tipi di configurazione della soluzione, la "1 grande soluzione", un approccio partizionato che è molto simile al modo in cui la maggior parte delle persone gestiva build costruendo a sua volta e copiando artefatti in una directory comune (che non è aiutata da .NET non con un percorso di 'inclusione' o 'libreria' a livello di server di riferimento) e un'impostazione a soluzione multipla 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 fare affidamento sulla mappatura dell'area di lavoro che è più simile agli esterni di sovversione. Personalmente, penso che il loro consiglio non sia una buona pratica, ma suppongo che stiano cercando di ridurre al minimo qualsiasi problema di build che potresti avere usando i riferimenti.
Ho avuto problemi con le build .NET che tentano di abbreviare il sistema creando solo ciò che è necessario, una build notturna che fa tutto e copia ogni nuovo assembly in una directory è stato il modo migliore per rimanere sincronizzati, in particolare i tester. Nota che questo vale solo per le app .NET, quelle C ++ tendono ancora a funzionare perché non hanno assembly con versione o aspetti simili che possono causare problemi con i componenti di chiamata. Questo approccio funziona bene, ma non si può sempre supporre che le build parziali siano ok, svapando tutto e ricostruire è più sicuro.
Ciò dipende da come è strutturata la soluzione e dalle capacità del software di controllo della versione. In precedenza, nelle nostre soluzioni mantenevamo un progetto incompleto / ignorato che conteneva documentazione e una cartella specifica per qualsiasi libreria di riferimento di terze parti. Poiché faceva parte della soluzione, è possibile fare riferimento al percorso di questi file utilizzando il percorso relativo. Dopo esserci spostati su TFS 2010, ci siamo sbarazzati di questo progetto e abbiamo semplicemente aggiunto una directory "Support" nella cartella di quella soluzione nel progetto del team parallelamente ai nostri rami principali. In entrambi i casi, la versione di controllo del codice sorgente della libreria finisce per trovarsi nello stesso posto, indipendentemente da come gli sviluppatori hanno configurato le loro macchine.
Quando si utilizza Subversion per il controllo della versione, è possibile utilizzare la proprietà "esterni" per questo scopo. Ciò consente di conservare una copia locale di una DLL condivisa in un percorso relativo vicino al progetto corrente. Ciò semplifica il riferimento a tale DLL tramite un percorso file relativo che non cambia, anche quando si cambia la directory principale del progetto in una cartella diversa. Gli esterni ti consentono anche di definire quale versione specifica o revisione includere.