Best practice per ILMerge

Question

Usi ILMerge?Utilizzi ILMerge per unire più assiemi per facilitare la distribuzione delle DLL?Hai riscontrato problemi con la distribuzione/il controllo delle versioni in produzione dopo l'unione degli assiemi ILMerging?

Sto cercando qualche consiglio riguardo all'utilizzo di ILMerge per ridurre gli attriti di distribuzione, se ciò è possibile.

Answer 1

Utilizzo ILMerge per quasi tutte le mie diverse applicazioni.L'ho integrato direttamente nel processo di creazione del rilascio, quindi quello che ottengo è un exe per applicazione senza DLL aggiuntive.

Non è possibile ILMerge alcun assembly C++ con codice nativo.Inoltre, non puoi ILMerge alcun assembly che contenga XAML per WPF (almeno non ho avuto alcun successo con quello).Si lamenta in fase di esecuzione che le risorse non possono essere individuate.

Ho scritto un eseguibile wrapper per ILMerge in cui passo il nome dell'exe di avvio per il progetto che desidero unire e un nome dell'exe di output, quindi riflette gli assembly dipendenti e chiama ILMerge con i parametri della riga di comando appropriati.Ora è molto più semplice quando aggiungo nuovi assembly al progetto, non devo ricordarmi di aggiornare lo script di build.

Answer 2

introduzione

Questo post mostra come sostituire tutto .exe + .dll files con un singolo combined .exe.Mantiene anche il debug .pdb file intatto.

Per le app della console

Ecco le basi Post Build String per Visual Studio 2010 SP1, utilizzando .NET 4.0.Sto creando un file .exe della console con tutti i file sub-.dll inclusi al suo interno.

"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards

Suggerimenti di base

• L'output è un file "AssemblyName.all.exe" che combina tutte le sottodll in un unico file .exe.
• Notare il ILMerge\ directory.È necessario copiare l'utilità ILMerge nella directory della soluzione (in modo da poter distribuire l'origine senza doversi preoccupare di documentare l'installazione di ILMerge) oppure modificare il percorso this in modo che punti al punto in cui risiede ILMerge.exe.

Suggerimenti avanzati

Se hai problemi con il mancato funzionamento, accendilo Output, e selezionare Show output from: Build.Controllare il comando esatto effettivamente generato da Visual Studio e verificare la presenza di errori.

Script di creazione di esempio

Questo script sostituisce tutto .exe + .dll files con un singolo combined .exe.Mantiene inoltre intatto il file .pdb di debug.

Per usarlo, incollalo nel tuo file Post Build passo, sotto il Build Events scheda in un progetto C# e assicurati di regolare il percorso nella prima riga a cui puntare ILMerge.exe:

rem Create a single .exe that combines the root .exe and all subassemblies.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
rem Remove all subassemblies.
del *.dll
rem Remove all .pdb files (except the new, combined pdb we just created).
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).all.pdb.temp"
del *.pdb
ren "$(TargetDir)$(TargetName).all.pdb.temp" "$(TargetName).all.pdb"
rem Delete the original, non-combined .exe.
del "$(TargetDir)$(TargetName).exe"
rem Rename the combined .exe and .pdb to the original project name we started with.
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).pdb"
ren "$(TargetDir)$(TargetName).all.exe" "$(TargetName).exe"
exit 0

Answer 3

Utilizziamo ILMerge sui blocchi di applicazioni Microsoft: invece di 12 file DLL separati, abbiamo un singolo file che possiamo caricare nelle nostre aree client, inoltre la struttura del file system è molto più ordinata.

Dopo aver unito i file, ho dovuto modificare l'elenco dei progetti di Visual Studio, rimuovere i 12 assiemi separati e aggiungere il singolo file come riferimento, altrimenti si lamenterebbe di non riuscire a trovare l'assieme specifico.Tuttavia non sono sicuro di come funzionerebbe dopo la distribuzione, potrebbe valere la pena provarlo.

Answer 4

So che questa è una vecchia domanda, ma non usiamo ILMerge solo per ridurre il numero di dipendenze ma anche per internalizzare le dipendenze "interne" (ad esempio automapper, restsharp, ecc.) utilizzate dall'utilità.Ciò significa che sono completamente astratti e il progetto che utilizza l'utilità unita non ha bisogno di conoscerli.Ciò riduce nuovamente i riferimenti richiesti nel progetto e consente di utilizzare/aggiornare la propria versione della stessa libreria esterna, se necessario.

Answer 5

Usiamo ILMerge su parecchi progetti.IL Fabbrica di software per servizi Web, ad esempio produce qualcosa come 8 assembly come output.Uniamo tutte queste DLL in un'unica DLL in modo che l'host del servizio debba fare riferimento a una sola DLL.

Rende la vita un po' più facile, ma non è neanche un grosso problema.

Answer 6

Abbiamo avuto lo stesso problema con la combinazione delle dipendenze WPF ....ILMerge non sembra occuparsi di questi.Costura.Fody ha comunque funzionato perfettamente per noi e ci sono voluti circa 5 minuti per iniziare...un'esperienza molto positiva.

Basta installarlo con Nuget (selezionando il progetto predefinito corretto nella Console di gestione pacchetti).Si introduce nel progetto di destinazione e le impostazioni predefinite hanno funzionato immediatamente per noi.

Unisce tutte le DLL contrassegnate "Copia locale" = true e produce un file .EXE unito (insieme all'output standard), che è ben compresso in dimensioni (molto inferiore alla dimensione totale dell'output).

La licenza è MIT quindi è possibile modificare/distribuire come richiesto.

https://github.com/Fody/Costura/

Answer 7

Tieni presente che per i programmi GUI di Windows (ad esempio WinForms) ti consigliamo di utilizzare /target:winexe interruttore.
Il bersaglio:exe switch crea un file unito consolle applicazione.

Answer 8

Abbiamo riscontrato problemi durante l'unione di DLL che dispongono di risorse nello stesso spazio dei nomi.Nel processo di fusione uno degli spazi dei nomi delle risorse è stato rinominato e pertanto non è stato possibile individuare le risorse.Forse stiamo semplicemente facendo qualcosa di sbagliato e stiamo ancora indagando sul problema.

Answer 9

Abbiamo appena iniziato a utilizzare ILMerge nelle nostre soluzioni che vengono ridistribuite e utilizzate in altri nostri progetti e finora tutto bene.Tutto sembra funzionare bene.Abbiamo addirittura offuscato direttamente l'assembly impacchettato.

Stiamo valutando di fare lo stesso con gli assembly di MS Enterprise Library.

L'unico vero problema che vedo è il controllo delle versioni dei singoli assembly dal pacchetto.

Answer 10

Recentemente ho avuto un problema per cui avevo incorporato l'assembly nell'assembly. Avevo alcune classi che venivano chiamate tramite riflessione nel CMS opensource Umbraco.

Le informazioni per effettuare la chiamata tramite riflessione sono state prese dalla tabella db che aveva il nome dell'assembly e lo spazio dei nomi della classe implementata e dell'interfaccia.Il problema era che la chiamata di riflessione avrebbe fallito quando dll fosse stato unito, tuttavia se dll fosse stato separato tutto avrebbe funzionato bene.Penso che il problema possa essere simile a quello che sta riscontrando Longeasy?

Answer 11

Sto appena iniziando a utilizzare ILMerge come parte della mia build CI per combinare molti contratti WCF a grana fine in un'unica libreria.Funziona molto bene, tuttavia la nuova libreria unita non può coesistere facilmente con le sue librerie di componenti o con altre librerie che dipendono da tali librerie di componenti.

Se, in un nuovo progetto, fai riferimento sia alla tua libreria ILMerged che a una libreria legacy che dipende da uno degli input che hai fornito a ILMerge, scoprirai che non puoi passare alcun tipo dalla libreria ILMerged a nessun metodo in la libreria legacy senza eseguire una sorta di mappatura dei tipi (ad es.mappatura automatica o mappatura manuale).Questo perché una volta compilato tutto, i tipi vengono effettivamente qualificati con un nome di assembly.

Anche i nomi entreranno in collisione, ma puoi risolverlo utilizzando alias esterno.

Il mio consiglio sarebbe quello di evitare di includere nell'assembly unito qualsiasi libreria disponibile pubblicamente esposta dall'assembly unito (ad es.tramite un tipo restituito, parametro metodo/costruttore, campo, proprietà, generico...) a meno che non si sappia con certezza che l'utente dell'assembly unito non dipende e non dipenderà mai dalla versione indipendente della stessa libreria.

Answer 12

Mi sembra che la migliore pratica ILMerge n. 1 sia Non utilizzare ILMerge.Invece, usa SmartAssembly.Uno dei motivi è che la procedura consigliata n. 2 per ILMerge consiste nell'eseguire sempre PEVerify dopo aver eseguito un ILMerge, poiché ILMerge non garantisce che unirà correttamente gli assembly in un eseguibile valido.

Altri svantaggi di ILMerge:

• durante la fusione, rimuove i commenti XML (se mi importasse, utilizzerei uno strumento di offuscamento)
• non gestisce correttamente la creazione di un file .pdb corrispondente

Un altro strumento a cui vale la pena prestare attenzione è Mono.Cecil e lo strumento Mono.Linker [2].

[2]:http://www.mono-project.com/Linker