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

Hai già avvistato la maggior parte dei pro e dei contro. Usare i file CS come riferimenti è davvero più leggero e spesso più facile da gestire. Tuttavia, consiglio di utilizzare questo approccio esclusivamente quando i file cs sono completamente autonomi e non hanno requisiti di compilazione speciali.

Utilizzo di DLL separate

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

• consente di definire configurazioni di build specifiche (ad esempio, se una classe funziona solo con la configurazione x86 o se ha almeno .NET 4.0, la configurazione di build dell'assembly rende esplicito questo requisito).

Quindi, soprattutto se disponi di molti componenti autonomi a una sola classe, l'uso del riferimento ai file va bene, ma se hai dei componenti che fanno riferimento ad altri componenti o specifici requisiti di compilazione, ti consiglio 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 assiemi in un singolo file eseguibile. Nel nostro ambiente, affrontiamo il problema in modo diverso, utilizzando uno script di distribuzione per ogni applicazione. Questo script garantisce 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 parti che richiedono aggiornamenti, ma non l'intera applicazione. Quindi, se stai scrivendo MS Word, è comodo avere il codice di controllo ortografico in una DLL che può essere aggiornata senza dover aggiornare l'intera MS Word. Se quello che stai scrivendo è una piccola app di utilità (o una serie di app autonome che capita di utilizzare tutti lo stesso codice), non fa molta differenza se il codice è incorporato nell'app o meno.

L'hai quasi riassunto nella tua domanda, ho solo un paio di punti da aggiungere.

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

In alternativa, se decidi di utilizzare le DLL, puoi utilizzare strumenti come Costura per incorporare tale riferimento nel file eseguibile come risorsa incorporata. Per utilizzarlo basta aggiungere il pacchetto Costura.Fody :

Install-Package Costura.Fody

Se una dll è più vantaggiosa o meno dipende da diversi fattori:

1. La dimensione del codice (quando compilato).
2. Quanti ex si usano.
3. Quante volte hai intenzione di aggiornare il codice.
4. Indipendentemente dal fatto che gli ex siano destinati o meno alla conservazione o all'esistenza completamente separati.

Lo scopo di una libreria condivisa è quello di prendere il codice che è comune a più file eseguibili e centralizzarlo in modo che tutti gli eseguibili condividano una copia. Questo ha lo scopo di risparmiare spazio e rendere il codice più facile da aggiornare.

Se la quantità di codice nella tua classe helper è molto piccola, potrebbe non valere la pena di spostarla in una DLL perché il sovraccarico del codice che si trova in una DLL potrebbe neutralizzare il vantaggio di risparmio di spazio di averlo centralizzato.

Inoltre, se stai facendo solo pochi eseguibili, la dimensione del codice in ogni eseguibile potrebbe essere abbastanza piccola da non costituire un problema. Tuttavia, più eseguibili si utilizzano lo stesso codice, più utile sarebbe avere il codice spostato in una DLL.

Come esempio semplificato, diciamo che la tua classe helper compila a 128 byte in un file exe, ma quando viene spostata in una DLL, la dll è 512 byte. Se si dispone solo di 3 file eseguibili, si risparmia spazio includendo il codice nei file eseguibili. Tuttavia, se avessi 5 file eseguibili, ti troverei nel punto in cui dovresti avere una dll perché lo spazio combinato occupato da 5 copie del codice (5 * 128 = 640 byte) è più dello spazio occupato avendo il codice in una DLL (512 byte).

Ora dì ad esempio che trovi un bug nel tuo codice di aiuto. Se hai compilato tutti i tuoi eseguibili con il codice inserito, devi ricompilare ogni singolo eseguibile e ridistribuire le versioni ricompilate. Se hai compilato il codice su una dll, dovresti solo ricompilare e ridistribuire l'unica DLL, e il bug verrà automaticamente riparato per tutti gli eseguibili che lo utilizzano.

Infine, per un programma per trovare 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 tutti la troveranno subito. Se li stai tenendo intenzionalmente separati, diventa più difficile coordinarli per usare la stessa dll.

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

• Il tuo "progetto di supporto" è sempre aggiornato su tutti i diversi progetti.
• Puoi fare riferimento al codice del progetto quando vuoi vedere rapidamente le modifiche.
• Puoi crearlo ogni volta con la versione .NET corretta.
• In ogni caso è possibile incorporare una DLL in un exe, quindi non preoccuparti di poterlo avere solo come parte della build.

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

Un'altra quarta alternativa che non hai menzionato è quella di metterla su un repository NuGet privato che ti consentirebbe di eseguire correttamente la versione e di riferirla senza il progetto aggiuntivo in ogni 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 errori nell'utilità anche!) più eventuali modifiche apportate all'utilità vengono automaticamente incluse nell'applicazione .

Quindi, in realtà la decisione dipende da quanto matura è l'utilità ! Se non sei sicuro dei bug dell'utilità, dovresti sempre includere il file .cs di quell'utilità per scoprire i bug .. Ma se sei sicuro che l'Utility sia abbastanza matura e non ci sarà un risultato con qualche bug e lì non c'è spazio per miglioramenti nell'utilità, puoi andare avanti e includere il file DLL.