Lavorare con librerie comuni/di utilità

Question

Nell'azienda per cui lavoro abbiamo un progetto "Utility" a cui fa riferimento praticamente ogni applicazione che creiamo.Ha molte cose come NullHelpers, ConfigSettingHelpers, Common ExtensionMethods ecc.

Il modo in cui lavoriamo è che quando vogliamo creare un nuovo progetto, otteniamo la versione più recente del progetto dal controllo del codice sorgente, la aggiungiamo alla soluzione e quindi facciamo riferimento al progetto da tutti i nuovi progetti che vengono aggiunti alla soluzione.

Questo ha funzionato bene, tuttavia ci sono stati un paio di casi in cui le persone hanno apportato "modifiche sostanziali" al progetto comune, il che funziona per loro, ma non funziona per gli altri.

Ho pensato che invece di aggiungere la libreria comune come riferimento al progetto forse dovremmo iniziare a sviluppare la libreria comune come una DLL autonoma e pubblicare versioni diverse e indirizzare una versione particolare per un progetto particolare in modo che le modifiche possano essere apportate senza alcun rischio ad altri progetti utilizzando la libreria comune.

Detto questo, sono interessato a vedere come gli altri fanno riferimento o utilizzano le loro librerie comuni.

Answer 1

Questo è esattamente quello che stiamo facendo.Abbiamo un progetto di utilità che ha alcune funzioni utili non specifiche del progetto.Aumentiamo la versione manualmente (minore), creiamo il progetto nella versione Release, lo firmiamo e lo inseriamo in una posizione condivisa.

Le persone quindi utilizzano la versione specifica di biblioteca.

Se in alcuni progetti specifici vengono implementati alcuni metodi utili che potrebbero trovare la loro strada nel progetto Utility principale, li inseriamo in una classe helper speciale nel progetto e li contrassegniamo come possibile candidato Utility (semplice //TODO).Alla fine del progetto, esaminiamo i candidati e, se rimangono, li spostiamo nel main biblioteca.

Le modifiche importanti sono vietate e, se necessario, contrassegniamo metodi e classi come [Obsolete].

Ma non importa perché aumentiamo la versione ad ogni pubblicazione.

Spero che questo ti aiuti.

Answer 2

Usiamo la ramificazione nel controllo del codice sorgente;tutti usano il ramo principale finché non effettuano un rilascio.Quando ramificano la versione, ramificano anche il progetto delle utilità comuni.

Inoltre, il nostro progetto di utilità ha i propri test unitari.In questo modo, gli altri team possono sapere se interromperebbero la build per altri team.

Naturalmente, abbiamo ancora problemi come quelli che menzioni di tanto in tanto.Ma quando una squadra inserisce una modifica che interrompe la build di un'altra squadra, di solito significa che il contratto per quel metodo/oggetto è stato rotto da qualche parte.Consideriamo queste opportunità per migliorare la progettazione del progetto dei servizi comuni...o almeno scrivere più test unitari:/

Answer 3

Ho avuto il ESATTO stesso problema!

Usavo i riferimenti ai progetti, ma sembra che tutto vada male, quando, come dici tu, ci sono molti progetti che fanno riferimento ad esso.

Ora compilo in una DLL e imposto la proprietà CopyLocal per il riferimento DLL su false dopo la prima compilazione (altrimenti trovo che possa sovrascrivere i sottoprogetti e diventare semplicemente un disastro).

Immagino che in teoria dovrebbe probabilmente essere GAC, ma se è un problema che sta cambiando molto (come il mio) questo può diventare problematico..