Quando si dovrebbe utilizzare un riferimento al progetto anziché un riferimento binario?

Question

La mia azienda dispone di una libreria di codici comune composta da molti progetti di librerie di classi insieme a progetti di test di supporto.Ogni progetto di libreria di classi produce un singolo file binario, ad es.Company.Common.Serialization.dll.Poiché possediamo i binari compilati e testati nonché il codice sorgente, si discute se le nostre applicazioni di consumo debbano utilizzare riferimenti binari o di progetto.

Alcuni argomenti a favore delle referenze di progetto:

• I riferimenti al progetto consentirebbero agli utenti di eseguire il debug e visualizzare tutto il codice della soluzione senza il sovraccarico di caricare progetti/soluzioni aggiuntivi.
• I riferimenti al progetto aiuterebbero a tenere il passo con le modifiche dei componenti comuni apportate al sistema di controllo del codice sorgente poiché le modifiche sarebbero facilmente identificabili senza la soluzione attiva.

Alcuni argomenti a favore dei riferimenti binari:

• I riferimenti binari semplificherebbero le soluzioni e velocizzerebbero i tempi di caricamento della soluzione.
• I riferimenti binari consentirebbero agli sviluppatori di concentrarsi sul nuovo codice piuttosto che essere potenzialmente distratti dal codice che è già pronto e dimostrato stabile.
• I riferimenti binari ci costringerebbero a sperimentare in modo appropriato le nostre cose poiché utilizzeremmo la libreria comune proprio come sarebbero tenuti a fare quelli esterni alla nostra organizzazione.
• Poiché non è possibile eseguire il debug di un riferimento binario (entrare in esso), si sarebbe costretti a replicare e risolvere i problemi estendendo i progetti di test esistenti anziché testare e correggere solo nel contesto dell'applicazione che lo utilizza.
• I riferimenti binari garantiranno che lo sviluppo simultaneo sul progetto della libreria di classi non avrà alcun impatto sull'applicazione che lo utilizza poiché verrà fatto riferimento a una versione stabile del binario anziché a una versione di afflusso.Spetterà al responsabile del progetto decidere se incorporare o meno una versione più recente del componente, se necessario.

Qual è la tua politica/preferenza quando si tratta di utilizzare riferimenti di progetto o binari?

Answer 1

Mi sembra che tu abbia trattato tutti i punti principali.Abbiamo avuto una discussione simile al lavoro di recente e non abbiamo ancora deciso.

Tuttavia, una cosa che abbiamo esaminato è fare riferimento ai file binari, per ottenere tutti i vantaggi noti, ma avere i binari creati da un sistema di compilazione comune in cui il codice sorgente si trova in una posizione comune, accessibile da tutte le macchine dello sviluppatore ( almeno se sono seduti in rete al lavoro), in modo che qualsiasi debug possa effettivamente immergersi nel codice della libreria, se necessario.

Tuttavia, sulla stessa nota, abbiamo anche etichettato molte delle classi base con attributi appropriati in modo da fare in modo che il debugger le salti completamente, perché qualsiasi debug che fai nelle tue classi (al livello che stai sviluppando) lo farebbe essere solo ampiamente sovradimensionato dal codice delle librerie di base.In questo modo quando premi il Entra eseguendo il debug del tasto di scelta rapida su una classe della libreria, riemergi nel pezzo di codice successivo al tuo livello attuale, invece di dover guadare tonnellate di codice della libreria.

Fondamentalmente, voto decisamente (in termini SO) i tuoi commenti su come mantenere il codice di libreria collaudato fuori dalla vista del normale sviluppatore.

Inoltre, se carico il file della soluzione globale, che contiene tutti i progetti e sostanzialmente proprio tutto, ReSharper 4 sembra avere qualche tipo di problema alle coronarie, poiché Visual Studio praticamente si ferma.

Answer 2

A mio avviso, il problema maggiore legato all'utilizzo dei riferimenti ai progetti è che non fornisce ai consumatori una base comune per il loro sviluppo.Presumo che le biblioteche stiano cambiando.In tal caso, crearli e assicurarsi che siano dotati di versione ti fornirà un ambiente facilmente riproducibile.

Non farlo significherà che il tuo codice si interromperà misteriosamente quando il progetto a cui fa riferimento cambia.Ma solo su alcune macchine.

Answer 3

Tendo a trattare le librerie comuni come questa come risorse di terze parti.Ciò consente alla libreria di avere i propri processi di compilazione, test di QA, ecc.Quando il QA (o chiunque altro) "benedice" una versione della libreria, questa viene copiata in una posizione centrale disponibile a tutti gli sviluppatori.Spetta quindi a ciascun progetto decidere quale versione della libreria utilizzare copiando i file binari in una cartella di progetto e utilizzando i riferimenti binari nei progetti.

Una cosa importante è creare file di simboli di debug (pdb) con ogni build della libreria e rendere disponibili anche quelli.L'altra opzione è creare effettivamente un archivio di simboli locale sulla rete e fare in modo che ogni sviluppatore aggiunga tale archivio di simboli alla propria configurazione VS.Ciò ti consentirebbe di eseguire il debug del codice e di avere comunque i vantaggi dell'utilizzo dei riferimenti binari.

Per quanto riguarda i vantaggi che menzioni per i riferimenti ai progetti, non sono d'accordo con il tuo secondo punto.Per me è importante che i progetti che li utilizzano sappiano esplicitamente quale versione della libreria comune stanno utilizzando e che facciano un passo deliberato per aggiornare quella versione.Questo è il modo migliore per garantire di non rilevare accidentalmente modifiche alla libreria che non sono state completate o testate.

Answer 4

quando non lo desideri nella tua soluzione o hai il potenziale per dividere la tua soluzione, invia tutto l'output della libreria a una directory bin comune e fai riferimento lì.

L'ho fatto per consentire agli sviluppatori di aprire una soluzione compatta che abbia solo dominio, test e progetti Web.I nostri servizi di vincita, il materiale Silverlight e le librerie di controllo Web si trovano in soluzioni separate che includono i progetti di cui hai bisogno quando li guardi, ma Nant può creare tutto.

Answer 5

Credo che la tua domanda riguardi in realtà quando i progetti vanno insieme nella stessa soluzione;il motivo è che i progetti nella stessa soluzione dovrebbero avere riferimenti di progetto tra loro e i progetti in soluzioni diverse dovrebbero avere riferimenti binari tra loro.

Tendo a pensare che le soluzioni dovrebbero contenere progetti sviluppati a stretto contatto.Come i tuoi assembly API e le tue implementazioni di tali API.

La vicinanza è tuttavia relativa.Un progettista per un'applicazione, per definizione, è strettamente correlato all'app, tuttavia non vorrai avere il progettista e l'applicazione all'interno della stessa soluzione (se sono del tutto complessi, ovviamente).Probabilmente vorrai sviluppare il designer rispetto a un ramo del programma che viene unito a intervalli più distanziati rispetto alla normale integrazione quotidiana.

Answer 6

Penso che se il progetto non è parte della soluzione, non dovresti includerlo lì...ma è solo la mia opinione

Lo separo per concetto in breve