Tocmai am început să folosim ILMerge în soluțiile noastre redistribuite și utilizate în celelalte proiecte și până acum foarte bine. Totul pare să funcționeze bine. Ne-am obfuscat chiar și ansamblul ambalat.

Considerăm că facem același lucru și cu ansamblurile bibliotecii MS Enterprise.

Singura problemă reală pe care o văd cu aceasta este versiunea de ansambluri individuale din pachet.

Folosim ILMerge pe o serie de proiecte. Fabrica de Software pentru Web Service , de exemplu, produce ca ieșire ceva de genul 8 ansambluri. Am îmbinat toate aceste DLL-uri într-un singur DLL, astfel încât gazda de serviciu va trebui doar să facă referire la un DLL.

Ea face viața mai ușoară, dar nici nu este o afacere mare.

Introducere

Această postare arată cum să înlocuiți toate fișierele .exe + .dll cu un singur combinat .exe . De asemenea, păstrează intact fișierul .pdb de depanare.

Pentru aplicațiile Console

Aici este elementul de bază Post Build String pentru Visual Studio 2010 SP1, folosind .NET 4.0. Construiesc o consolă .exe cu toate fișierele sub-.dll incluse în ea.

"$(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

Sugestii de bază

• Ieșirea este un fișier " AssemblyName.all.exe " care combină toate subdll-urile într-un .exe.
• Observați directorul ILMerge \ . Trebuie fie să copiați utilitarul ILMerge în directorul de soluții (astfel încât să puteți distribui sursa fără să vă faceți griji cu privire la documentarea instalării ILMerge), fie să schimbați această cale pentru a indica locul în care se află ILMerge.exe.

Sugestii avansate

Dacă aveți probleme cu faptul că nu funcționează, activați Output și selectați Show output from: Build . Verificați comanda exactă pe care Visual Studio a generat-o și verificați erorile.

Sample Build Script

Acest script înlocuiește toate fișierele .exe + .dll cu un singur combinat .exe . De asemenea, păstrează fișierul .pdb de depanare intact.

Pentru a utiliza această opțiune, plasați-o în pasul Postați postarea , sub fila Build Events într-un proiect C# și asigurați-vă că ajustați calea din prima linie pentru a indica < code> 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

Știu că aceasta este o întrebare veche, dar nu numai că folosim ILMerge pentru a reduce numărul dependențelor, ci și pentru a internaliza dependențele "interne" (de exemplu, automapper, restsharp etc.) utilizate de utilitate. Aceasta înseamnă că acestea sunt complet abstracte, iar proiectul care utilizează utilitatea fuzionată nu are nevoie să știe despre ele. Aceasta reduce din nou referințele necesare în proiect și îi permite să utilizeze/actualizeze propria versiune a aceleiași biblioteci externe, dacă este necesar.

Am întâmpinat probleme când fuzionăm DLL-uri cu resurse în același spațiu de nume. În procesul de fuziune, unul dintre denumirile de resurse a fost redenumit și, prin urmare, resursele nu au putut fi localizate. Poate că facem doar ceva rău acolo, investigând problema.

Utilizăm ILMerge pe blocurile de aplicații Microsoft - în loc de 12 fișiere DLL separate, avem un singur fișier pe care îl putem încărca în zonele clientului nostru, plus structura sistemului de fișiere este mult mai netedă.

După ce am fuzionat fișierele, trebuia să editez lista de proiecte pentru studioul vizual, să scot 12 asamblări separate și să adaug un singur fișier drept referință, altfel s-ar plânge că nu ar putea găsi ansamblul specific. Nu sunt prea sigur cum ar funcționa post-implementarea, dar ar putea fi o încercare.

Folosesc ILMerge pentru aproape toate aplicațiile mele diferite. Am integrat-o chiar în procesul de lansare a versiunii, astfel încât ceea ce am terminat este cu un exe per aplicație fără dll-uri suplimentare.

Nu puteți să ILMergeți niciun ansamblu C ++ care are cod nativ. De asemenea, nu puteți să ILMergegeți orice ansambluri care conțin XAML pentru wpf (cel puțin nu am avut niciun succes cu asta). Se plânge în timpul execuției că resursele nu pot fi localizate.

Am scris un executabil de wrapper pentru ILMerge unde trec în numele exe de pornire pentru proiectul pe care doresc să îl fuzionez și un nume exe de ieșire și apoi reflectă ansamblurile dependente și sună ILMerge cu parametrii corespunzători ai liniei de comandă. Este mult mai ușor acum când adaugă noi ansambluri la proiect, nu trebuie să-mi amintesc să actualizez scriptul de construire.

Recent am avut o problemă în care am avut iluminat asamblarea în adunare, am avut câteva clase pe care le-am numit prin reflecție în Umbraco opensource CMS.

Informația de efectuare a apelului prin reflecție a fost luată din tabelul db care avea numele de asamblare și spațiul de nume al clasei implementate și interfața. Problema a fost că apelul de reflecție ar eșua când dll-ul a fost unificat, totuși, dacă dll-ul era separat, totul funcționa bine. Cred că problema poate fi similară cu cea pe care o are longeasy?

Mi se pare ca cea mai buna practica ILMerge # 1 este sa nu folositi ILMerge. În schimb, utilizați SmartAssembly . Un motiv pentru aceasta este faptul că # 2 ILMerge Best Practice este de a rula întotdeauna PEVerify după ce faceți un ILMerge, deoarece ILMerge nu garantează că va fuziona corect ansamblurile într-un executabil valid.

Alte dezavantaje ale ILMerge:

• atunci când fuzionează, scindează comentariile xml (dacă îmi pasă de asta, aș folosi un instrument de confuzie)
• nu se ocupă corect cu crearea unui fișier .pdb corespunzător

Un alt instrument care merită acordat atenție este Mono.Cecil și instrumentul Mono.Linker [2].

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

Am avut aceeași problemă cu combinarea dependențelor wpf ... ILMerge nu pare să se ocupe de acestea. Costura.Fody a lucrat perfect pentru noi și a durat aproximativ 5 minute pentru a merge ... o experiență foarte bună.

Doar instalați cu Nuget (selectând proiectul implicit corect din Consola Manager pachet). Se introduce în proiectul țintă, iar setările implicite au funcționat imediat pentru noi.

Acesta combină toate DLL-urile marcate "Copy Local" = true și produce o .EXE (împreună cu ieșirea standard), care este comprimată frumos în dimensiune (mult mai mică decât dimensiunea totală de ieșire).

Licența este MIT, astfel încât să puteți modifica/distribui după cum este necesar.

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

Încep doar să folosesc ILMerge, ca parte a construirii CI, pentru a combina o mulțime de contracte WCF cu granulație fină într-o singură bibliotecă. Funcționează foarte bine, dar noua combinație lib nu poate coexista cu ușurință cu bibliotecile sale componente sau cu alte libs care depind de aceste biblioteci de componente.

Dacă, într-un proiect nou, vă referiți atât la IL librăria ILM, cât și la o bibliotecă tradițională care depinde de una dintre intrările pe care le-ați dat ILMerge, veți descoperi că nu puteți trece nici un tip din lib ILmerged la orice metodă din biblioteca originală fără a face un fel de cartografiere de tip (de exemplu, automapper sau cartografiere manuală). Acest lucru se datorează faptului că odată ce totul este compilat, tipurile sunt calificate efectiv cu un nume de ansamblu.

Numele se vor ciocni, dar puteți remedia acest lucru folosind extern alias .

Sfatul meu ar fi să evitați să includeți în ansamblul dvs. fuzionat orice lib disponibil în mod public expus de unitatea mixtă (de exemplu, printr-un tip de returnare, parametru constructor, câmp, proprietate, generic ...) decât dacă știți sigur că utilizatorul adunarea dvs. fuzionată nu depinde niciodată de versiunea liberă a aceleiași biblioteci.

Note that for windows GUI programs (eg WinForms) you'll want to use the /target:winexe switch.
The /target:exe switch creates a merged console application.