Strategia per il mantenimento dei riferimenti all'assembly in TFS

Penso che tu abbia un paio di cose da considerare.

1 - Se l'albero dei sorgenti è ragionevolmente complesso, ti suggerisco di separare i file della soluzione dal tuo sistema di build e creare i file * proj MSBuild direttamente usando i consigli di Microsoft come MSBuild Traversal projects (vedi questo articolo per maggiori informazioni su questa best practice

link

Il disaccoppiamento del file di soluzione dal sistema di generazione consente di mantenere uno stretto controllo sul sistema di costruzione, sfruttare i riferimenti di progetto laddove hanno senso e consentire comunque agli sviluppatori di utilizzare le soluzioni a proprio piacimento come opzione di produttività. Se un dev aggiunge un nuovo progetto, c'è una decisione consapevole di includerlo nella posizione appropriata nel processo di compilazione. Inoltre, è possibile utilizzare la proprietà "BuildProjectReferences" di MSBuild per indicare se MSBuild deve creare automaticamente riferimenti di progetto o utilizzare l'output esistente.

2 - Nuget ... link

L'uso di un sistema di gestione dei pacchetti come Nuget per ospitare e distribuire le dipendenze di terze parti può eliminarle dal controllo del codice sorgente e consentire di pubblicare nuove versioni e creare nuovi pacchetti Nuget a proprio piacimento. C'è stato un tasso di adozione abbastanza ampio per Nuget di recente e la documentazione internet risultante dovrebbe aiutarti a decidere se ospitare il tuo server Nuget, utilizzare quello pubblico o saltare del tutto.

Dopo aver detto tutto questo e indipendentemente dal fatto che una di queste soluzioni ti sia piaciuta, ti incoraggerei sicuramente a ottenere una build CI in esecuzione il prima possibile. È inestimabile per far rispettare la qualità e per far sì che una squadra abbia l'abitudine di seguire il protocollo. Infatti, se hai problemi a migliorare la qualità dopo aver creato una build CI, ti incoraggio a utilizzare un build Gated-Checkin (parte di TFS gratuitamente) per assicurarti che le build vengano compilate correttamente prima del check-in.

Se scegli di mantenere la tua albero delle dipendenze controllata nel controllo del codice sorgente, allora ti suggerisco di: a) separare le dipendenze interne da quelle di terze parti eb) mantenere la cartella delle dipendenze specifica del ramo in modo da poter costruire contro diversi set di dipendenze basato sul ramo facilmente.

Ciò che ha funzionato meglio per noi è assicurarci che tutti abbiano spazi di lavoro identici con la stessa struttura di cartelle locale. Quindi i riferimenti possono utilizzare percorsi di file relativi nel file di progetto. OSSIA nel file di progetto Project1 dev vedresti qualcosa di simile:

<Reference Include="Project2">
    <HintPath>..\..\..\Project2_Dev\Project2\bin\Release\Project2.dll</HintPath>
</Reference>'

I progetti non sono nella stessa soluzione ma questo funziona per tutti perché abbiamo la stessa struttura di cartelle. Ciò elimina la necessità di archiviare e aggiornare gli assembly in TFS. Devi solo avere le ultime novità su Project2 e costruirlo.

Gli svantaggi sono:

• Per creare Project1, devi anche avere tutti i progetti di riferimento localmente e devono anche essere in grado di creare. Questo può essere noioso a volte se si ha una catena di dipendenze tra diversi progetti. È stato anche un problema nei casi in cui forniamo a un appaltatore l'accesso a Project1 ma non vogliamo impostarli con tutti gli altri progetti. In questo caso, abbiamo appena creato la struttura di cartelle vuota per loro e abbiamo inserito solo la DLL precompilata nel cestino, oppure utilizzato temporaneamente una cartella di Assemblies condivisa come descritto nella domanda.
• Quando si uniscono, TFS vuole far coincidere i file del progetto in modo che proverà a sovrascrivere i relativi percorsi nel file di progetto. Questo è particolarmente un problema per me dal momento che l'aggiornamento a VS 2013 perché non chiede più quale versione voglio mantenere. Ne sceglie automaticamente solo uno. Quindi, prima di fare il check-in, devo annullare manualmente le modifiche a quelle righe nei file csproj (che è quello che mi ha portato a questa domanda nella speranza di trovare una soluzione per.)