Vantaggi dell'uso dei file .dll rispetto al collegamento dei file .cs ai progetti (per le mie classi helper generiche / metodi di estensione)

Ho un progetto di aiuto che utilizzo in tutte le applicazioni che creo. Contiene alcuni metodi di estensione e un gruppo di classi helper generiche, controlli ecc. Di tanto in tanto aggiorno / estendo il progetto helper. Questi di solito sono progetti piccoli e non correlati, e io sono l'unica persona che lavora su tutti loro.

Ho provato due approcci per usarlo

• aggiungere i file .cs direttamente (Aggiungi come collegamento) a ciascun progetto in cui li utilizzo
• compilarlo come .dll e aggiungerlo come riferimento

Vedo alcuni vantaggi e svantaggi di questi approcci.
Il primo:

• è più semplice, perché le classi helper vengono compilate nel file exe, quindi spesso posso facilmente fornire un solo file .exe che funzionerà perfettamente. Poiché aggiungo come collegamento, posso essere abbastanza sicuro che ogni volta che creo un progetto che utilizza l'helper, i file dell'helper saranno la versione più recente.
• è ancora più semplice, perché posso separare i file, in modo che i miei metodi di estensione che funzionano correttamente su .NET 4.0 possano essere referenziati separatamente da quelli che richiedono .NET 4.5, il che significa che l'app nel suo complesso può funzionare su .NET 4.0
• Permette il debug attraverso il codice, con tutti i vantaggi di breakpoint ecc. Ecc.
• non sembra essere la "migliore pratica"

Il secondo:

• sembra essere l'approccio giusto, ma:
• mi richiede di consegnare un file DLL separato, che per qualche ragione è molto più difficile per gli utenti (tendono a condividere i miei programmi senza il DLL, che quindi si arresta in modo anomalo all'avvio)
• poiché viene compilato in una singola DLL, richiederà la versione più alta di .NET - molti dei miei utenti non hanno .NET 4.5 e solo alcuni elementi della mia classe di supporto lo richiedono, il che significa che posso forzare alcune persone per aggiornare i loro sistemi senza motivo
• Devo anche assicurarmi che ogni volta che aggiorno uno dei miei programmi, consegno anche il file .dll, anche se non so se è stato modificato dall'ultima versione, oppure no (avrebbe potuto essere, ma poteva potrebbe anche essere la stessa versione). Non riesco a vedere un modo semplice per determinarlo, senza tenere traccia della versione dell'assembly, che è un lavoro aggiuntivo. Per ora, quando aggiorno i miei programmi, consegno solo exe aggiornato e mi piace mantenerlo piccolo e di basso profilo.

Quindi, qual è il vantaggio effettivo dell'utilizzo del file DLL qui? Tieni presente che sono l'unica persona che modifica il codice di tutte le applicazioni e i file di supporto.

Inoltre, per chiarire: le app sono in genere molto piccole, mentre il codice contenuto nelle classi di supporto è completamente generico per tutte (alcune semplici comparazioni di stringhe, percorsi o operazioni XML, ecc.)

In realtà, qualcuno mi ha fatto capire proprio ora che c'è una terza opzione. Dato che ho il codice helper in un progetto separato, posso aggiungere questo progetto alle soluzioni di ciascuna delle mie applicazioni separate - che funziona in un modo come "Aggiungi come collegamento" per singoli file, tranne che per aggiungere solo un singolo progetto ... Ma come notato da Doc Brown, ciò significa essenzialmente che .dll dovrà comunque essere aggiunto al progetto ...

Ancora un'altra cosa che è in qualche modo a favore del non usare i file DLL è la possibilità di eseguire il debug attraverso la classe helper attivamente ...

Hai già individuato la maggior parte dei pro e dei contro. L'uso dei file cs come riferimenti è infatti più leggero e spesso più facile da gestire. Tuttavia, ti consiglio di utilizzare questo approccio esclusivamente quando i tuoi csfile sono completamente autonomi e non hanno particolari requisiti di build.

Utilizzo di DLL separate

• renderà esplicite le dipendenze da altre utilità o librerie (quindi finché non si hanno tali dipendenze, funzionerà bene)

• ti consentirà di definire specifiche configurazioni di build (ad esempio, se una classe funziona solo in configurazione x86 o necessita almeno di .NET 4.0, la configurazione di build dell'assembly rende esplicito questo requisito).

Quindi, specialmente se disponi di molti componenti autonomi di una sola classe, l'uso del riferimento ai file va bene, ma se hai componenti che fanno riferimento ad altri componenti o requisiti di build specifici, consiglierei di utilizzare le DLL.

Per mitigare i problemi con la gestione di molte DLL separate, è possibile creare un pacchetto di installazione o utilizzare ILMerge , che può incorporare un set di assembly in un singolo eseguibile. Nel nostro ambiente, affrontiamo il problema in modo diverso, utilizzando uno script di distribuzione per ogni applicazione. Questo script assicura che tutte le DLL necessarie vengano sempre consegnate alla produzione quando viene pubblicata una nuova versione dell'applicazione.

Le DLL sono utili quando un'applicazione è grande e ci sono pezzi che richiedono aggiornamenti, ma non l'intera applicazione. Quindi, se stai scrivendo MS Word, è utile avere il codice di controllo ortografico in una DLL che può essere aggiornato senza dover aggiornare interamente MS Word. Se quello che stai scrivendo è una piccola app di utilità (o una serie di app autonome che utilizzano tutte lo stesso codice) non fa molta differenza se il codice è incorporato o meno nelle app.

Hai praticamente riassunto la tua domanda, ho solo un paio di punti da aggiungere.

Mono Options è un ottimo esempio di pacchetto NuGet che utilizza molto bene il primo approccio.

In alternativa, se decidi di usare le dll puoi usare strumenti come Costura per incorporare quel riferimento nel tuo eseguibile come risorsa incorporata. Per usarlo basta aggiungere il Costura.Fodypacchetto:

Install-Package Costura.Fody

Se una DLL sia più vantaggiosa o meno dipende da diversi fattori:

1. La dimensione del codice (una volta compilato).
2. Quanti ex lo usano.
3. Con quale frequenza intendi aggiornare il codice.
4. Se gli ex debbano essere tenuti insieme o esistano completamente separatamente.

Lo scopo di una libreria condivisa è prendere il codice comune a più eseguibili e centralizzarlo in modo che tutti gli eseguibili condividano una copia. Questo ha lo scopo di risparmiare spazio e facilitare l'aggiornamento del codice.

Se la quantità di codice nella tua classe di supporto è molto piccola, potrebbe non valere la pena spostarlo in una dll poiché l'overhead del codice che si trova in una dll può contrastare il vantaggio di risparmiare spazio di averlo centralizzato.

Inoltre, se stai realizzando solo alcuni eseguibili, la dimensione del codice in ciascun eseguibile potrebbe essere abbastanza piccola da non costituire un problema. Tuttavia, più file eseguibili si utilizza lo stesso codice, più vantaggioso sarebbe che il codice venisse spostato in una dll.

Come esempio semplificato, supponiamo che la tua classe helper si compili in 128 byte in un file exe, ma quando viene spostata in una dll, la dll è di 512 byte. Se hai solo 3 eseguibili, risparmierai spazio includendo il codice negli eseguibili. Tuttavia, se avessi 5 eseguibili, allora saresti nel punto in cui sarebbe meglio avere una dll perché lo spazio combinato occupato da 5 copie del codice (5 * 128 = 640 byte) è maggiore dello spazio occupato avendo il codice in una dll (512 byte).

Ora dì per esempio che trovi un bug nel tuo codice helper. Se hai compilato tutti i tuoi eseguibili con il codice inserito, devi ricompilare ogni singolo eseguibile e quindi ridistribuire le versioni ricompilate. Se hai compilato il codice in una dll, dovresti solo ricompilare e ridistribuire la dll e il bug verrebbe automaticamente riparato per tutti gli eseguibili che lo utilizzavano.

Infine, affinché un programma trovi una dll, deve sapere dove cercare la dll. Se stai mantenendo tutti i tuoi eseguibili insieme, puoi semplicemente mettere la dll nella stessa directory e la troveranno subito. Se li stai tenendo intenzionalmente separati, diventa più difficile coordinarli per usare la stessa dll.

La terza opzione è la più appropriata (aggiungerla come progetto separato "libreria di classi" alla soluzione). Questo combina i vantaggi di tutti gli approcci:

• Il tuo "progetto di aiuto" è sempre aggiornato su tutti i diversi progetti.
• È possibile fare riferimento al codice del progetto quando si desidera vedere rapidamente le modifiche.
• È possibile crearlo per la versione .NET corretta ogni volta.
• Puoi comunque incorporare una DLL in un exe, quindi non preoccuparti che puoi averlo come parte della tua build.

Lo facciamo sempre e non posso fare altro che raccomandare questo approccio.

Un'altra quarta alternativa che non hai menzionato è quella di metterlo su un repository NuGet privato che ti consentirebbe di eseguirne la versione corretta e di fare riferimento a esso senza il progetto aggiuntivo in ciascuna soluzione.

Come sviluppatore, mi piace sempre includere il riferimento della soluzione dell'utilità alla mia applicazione in quanto mi consente di eseguire il debug del codice (e individuare eventuali bug anche nell'utilità!) E qualsiasi modifica apportata all'utilità viene automaticamente inclusa nell'applicazione.

Quindi, in realtà la decisione dipende da quanto è matura l'utilità ! Se non sei sicuro dei bug di Utility, allora dovresti sempre includere il file .cs di quella utility per scoprire i bug .. Ma se sei sicuro che Utility sia abbastanza matura e non restituirà il risultato con nessun bug e lì non esiste alcun margine di miglioramento nell'utilità, è possibile andare avanti e includere il file DLL.