Best practice per la fusione di assiemi?

Question

Mi chiedo quali sono le euristiche durante la creazione di versioni di librerie da includere in altri progetti in relazione alle dipendenze e se dovrei includerle o meno.

Il mio problema è il seguente:

Ho una libreria CommonUtilities che fornisce come il nome implica una serie di utility che possono essere utilizzate in più di un posto. Le dipendenze di CommonUtilities includono log4net.dll (il framework di registrazione) e Oracle.DataAccess.dll (driver del database).

Ho un altro progetto chiamato MyProject in cui voglio includere CommonUtilities. MyProject dipende anche da Oracle.DataAccess.

Se utilizzo ILMerge e unisco CommonUtilities in un unico assembly CommonUtilities.dll e faccio riferimento a tutto ciò che viene compilato da MyProject, ma sono sicuro che dovrei fare esplicito riferimento a Oracle.DataAccess da MyProject poiché è una dipendenza e non utilizzare l'assembly unito in CU . L'aggiunta di un riferimento a Oracle.DataAccess genera anche istruzioni di utilizzo ambigue in quanto vi sono due assembly Oracle.DataAccess a cui viene fatto riferimento.

L'uso di ILMerge / Internalize nel mio caso provoca errori di compilazione poiché i tipi dell'assembly Oracle.DataAccess interiorizzato vengono restituiti da CommonUtilities e poiché sono contrassegnati come MyProject interno non riconosce il tipo restituito.

L'unico modo per farlo funzionare è semplicemente quello di non unire questo particolare assembly (Oracle.DataAccess) in CommonUtilities e fare riferimento solo a quello di MyProject. Questo a sua volta crea un nuovo problema: quale Oracle.DataAccess.dll dovrei fare riferimento: la dipendenza distribuita con CommonUtils o no?

Ci sono altri modi per fare tutto questo?

Answer 1

La versione semplice e breve:

  

Ogni riferimento all'interno di un processo a un determinato assieme dovrebbe fare riferimento alla stessa versione.

In caso contrario, potresti avere grossi problemi perché una parte dell'app non può comunicare con un'altra a causa della mancata corrispondenza della versione.

Anche con " veramente privato " cose come log4net potresti perdere le possibilità di spazio di configurazione condiviso, come usare un logger root comune per tutte le parti dell'app. Naturalmente, in questo caso l'ultima chiamata è - come sempre - con lo sviluppatore responsabile.

Vedi anche questa altra domanda su ILMerge e assemblee di terze parti .

Answer 2

Il motivo principale per cui utilizziamo ILMerge è rendere il nostro passaggio di offuscamento molto più difficile da invertire. Unendoli insieme usando il flag / internalize, l'obfuscator può quindi rinominare le classi e i metodi pubblici che abbiamo unito nell'assembly padre.

Dalla documentazione di UN merge: " [Internalize] controlla se i tipi di assiemi diversi dall'assemblaggio primario hanno la visibilità modificata. Quando è vero, tutti i tipi non esenti che sono visibili al di fuori del loro assieme hanno la loro visibilità modificata in modo che non siano visibili dall'esterno dell'assieme unito "

Se le assemblee sono tenute separate, l'offuscatore non le rinominerà.

BTW Eazfuscator è fantastico e gratuito: http://www.foss.kharkov.ua/g1/ progetti / eazfuscator / dotnet / Default.aspx

Answer 3

Non uniamo affatto le librerie. Non riesco a vedere molto vantaggio nell'unire insieme le librerie che non puoi ottenere, ma semplicemente costruendole in un assembly in primo luogo.

Riesco a vedere i vantaggi della fusione di librerie con un EXE. Potrebbe essere davvero utile. Il problema con l'unione delle librerie è che possono avere diverse versioni di una dipendenza nel tuo EXE e che possono creare compagni di letto scomodi.

Non credo che l'unione delle dll insieme possa essere considerata la migliore pratica, tranne quando le unisci in un EXE per presentare un singolo file anziché più file.

Answer 4

Suppongo che potrebbe esserci qualche vantaggio per quanto riguarda la tenuta di un gruppo di assemblee localizzate in una (cosa che, non sono nemmeno sicuro che tu possa fare)

Non unirei le librerie di altri fornitori, poiché spesso dispongono di una propria licenza e, aggiornandole, è necessario ridistribuire una nuova versione del codice.

Unire le proprie librerie può essere vantaggioso se si dispone di molte librerie per mantenere ordinata la directory o assicurarsi che parte del codice sia SEMPRE nell'assembly principale in esecuzione.

Penso che ILMerge faccia meglio con l'unione delle librerie in un EXE, in modo da avere un file anziché molti.