Frage

Verwenden Sie ILMerge?Verwenden Sie ILMerge, um mehrere Assemblys zusammenzuführen, um die Bereitstellung von DLLs zu vereinfachen?Haben Sie Probleme mit der Bereitstellung/Versionierung in der Produktion festgestellt, nachdem ILMerging-Assemblys zusammengeführt wurden?

Ich suche nach Ratschlägen zur Verwendung von ILMerge zur Reduzierung von Bereitstellungsproblemen, sofern dies überhaupt möglich ist.

War es hilfreich?

Lösung

Ich verwende ILMerge für fast alle meine verschiedenen Anwendungen.Ich habe es direkt in den Release-Build-Prozess integriert, sodass ich am Ende eine Exe-Datei pro Anwendung ohne zusätzliche DLLs habe.

Sie können keine C++-Assemblys mit nativem Code ILMerge durchführen.Sie können auch keine Assemblys mit ILMerge erstellen, die XAML für WPF enthalten (zumindest hatte ich damit keinen Erfolg).Es beschwert sich zur Laufzeit, dass die Ressourcen nicht gefunden werden können.

Ich habe eine ausführbare Wrapper-Datei für ILMerge geschrieben, in der ich den Start-Exe-Namen für das Projekt, das ich zusammenführen möchte, und einen Ausgabe-Exe-Namen übergebe. Anschließend spiegelt sie die abhängigen Assemblys wider und ruft ILMerge mit den entsprechenden Befehlszeilenparametern auf.Wenn ich dem Projekt neue Assemblys hinzufüge, ist es jetzt viel einfacher, ich muss nicht daran denken, das Build-Skript zu aktualisieren.

Andere Tipps

Einführung

Dieser Beitrag zeigt, wie man alles ersetzt .exe + .dll files mit einer einzigen combined .exe.Es hält auch das Debuggen aufrecht .pdb Datei intakt.

Für Konsolen-Apps

Hier ist das Grundlegende Post Build String für Visual Studio 2010 SP1 unter Verwendung von .NET 4.0.Ich erstelle eine Konsolen-EXE-Datei mit allen darin enthaltenen Sub-DLL-Dateien.

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

Grundlegende Hinweise

  • Die Ausgabe ist eine Datei „AssemblyName.all.exe", das alle Unter-DLLs in einer EXE-Datei zusammenfasst.
  • Beachten Sie die ILMerge\ Verzeichnis.Sie müssen entweder das ILMerge-Dienstprogramm in Ihr Lösungsverzeichnis kopieren (damit Sie die Quelle verteilen können, ohne sich um die Dokumentation der Installation von ILMerge kümmern zu müssen) oder den Pfad so ändern, dass er auf den Speicherort von ILMerge.exe verweist.

Erweiterte Hinweise

Wenn Sie Probleme damit haben, dass es nicht funktioniert, schalten Sie es ein Output, und wählen Sie Show output from: Build.Überprüfen Sie den genauen Befehl, den Visual Studio tatsächlich generiert hat, und suchen Sie nach Fehlern.

Beispiel-Build-Skript

Dieses Skript ersetzt alle .exe + .dll files mit einer einzigen combined .exe.Außerdem bleibt die Debugging-PDB-Datei erhalten.

Fügen Sie dies zur Verwendung in Ihr ein Post Build Schritt, unter dem Build Events Tab in einem C#-Projekt und stellen Sie sicher, dass Sie den Pfad in der ersten Zeile anpassen, auf den verwiesen werden soll 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

Wir verwenden ILMerge für die Microsoft-Anwendungsblöcke – anstelle von 12 separaten DLL-Dateien haben wir eine einzige Datei, die wir in unsere Kundenbereiche hochladen können, außerdem ist die Dateisystemstruktur viel übersichtlicher.

Nach dem Zusammenführen der Dateien musste ich die Visual Studio-Projektliste bearbeiten, die 12 separaten Baugruppen entfernen und die einzelne Datei als Referenz hinzufügen, sonst würde es sich beschweren, dass die spezifische Baugruppe nicht gefunden werden konnte.Ich bin mir allerdings nicht ganz sicher, wie das nach der Bereitstellung funktionieren würde, es könnte einen Versuch wert sein.

Ich weiß, dass dies eine alte Frage ist, aber wir verwenden ILMerge nicht nur, um die Anzahl der Abhängigkeiten zu reduzieren, sondern auch, um die „internen“ Abhängigkeiten (z. B. Automapper, Restsharp usw.) zu verinnerlichen, die vom Dienstprogramm verwendet werden.Dies bedeutet, dass sie vollständig abstrahiert sind und das Projekt, das das zusammengeführte Dienstprogramm verwendet, nichts davon wissen muss.Dadurch werden die erforderlichen Referenzen im Projekt erneut reduziert und es kann bei Bedarf eine eigene Version derselben externen Bibliothek verwendet/aktualisiert werden.

Wir verwenden ILMerge für eine ganze Reihe von Projekten.Der Webservice-Softwarefabrik, erzeugt beispielsweise etwa 8 Baugruppen als Ausgabe.Wir führen alle diese DLLs zu einer einzigen DLL zusammen, sodass der Diensthost nur auf eine DLL verweisen muss.

Es macht das Leben etwas einfacher, ist aber auch kein großes Problem.

Wir hatten das gleiche Problem mit der Kombination von WPF-Abhängigkeiten ...ILMerge scheint sich damit nicht zu befassen.Costura.Fody hat für uns jedoch perfekt funktioniert und es dauerte etwa 5 Minuten, bis es losging ...eine sehr gute Erfahrung.

Installieren Sie einfach mit Nuget (wählen Sie das richtige Standardprojekt in der Paket-Manager-Konsole aus).Es führt sich in das Zielprojekt ein und die Standardeinstellungen funktionierten bei uns sofort.

Es führt alle mit „Copy Local“ = true gekennzeichneten DLLs zusammen und erzeugt eine zusammengeführte .EXE-Datei (neben der Standardausgabe), die schön komprimiert ist (viel kleiner als die Gesamtausgabegröße).

Die Lizenz ist MIT, sodass Sie sie nach Bedarf ändern/verteilen können.

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

Beachten Sie, dass Sie für Windows-GUI-Programme (z. B. WinForms) /target verwenden sollten:winexe schalten.
Das Ziel:exe Schalter erstellt eine Zusammenführung Konsole Anwendung.

Beim Zusammenführen von DLLs, die Ressourcen im selben Namespace haben, sind Probleme aufgetreten.Während des Zusammenführungsprozesses wurde einer der Ressourcen-Namespaces umbenannt und daher konnten die Ressourcen nicht gefunden werden.Vielleicht machen wir dort einfach etwas falsch und untersuchen das Problem noch.

Wir haben gerade damit begonnen, ILMerge in unseren Lösungen zu verwenden, die in unseren anderen Projekten weitergegeben und verwendet werden, und bisher ist alles gut.Alles scheint in Ordnung zu sein.Wir haben sogar die verpackte Baugruppe direkt verschleiert.

Wir erwägen, dasselbe mit den MS Enterprise Library-Assemblys zu tun.

Das einzige wirkliche Problem, das ich dabei sehe, ist die Versionierung einzelner Assemblys aus dem Paket.

Ich hatte kürzlich ein Problem, bei dem ich Assembly in der Assembly zusammengeführt hatte. Ich hatte einige Klassen, die über Reflection im OpenSource-CMS Umbraco aufgerufen wurden.

Die Informationen zum Durchführen des Aufrufs über Reflektion wurden der Datenbanktabelle entnommen, die den Assemblynamen und den Namespace der implementierten Klasse und die Schnittstelle enthielt.Das Problem bestand darin, dass der Reflection-Aufruf fehlschlug, wenn die DLL zusammengeführt wurde. Wenn die DLL jedoch getrennt war, funktionierte alles einwandfrei.Ich denke, das Problem könnte dem ähneln, das Longeasy hat?

Ich fange gerade erst damit an, ILMerge als Teil meines CI-Builds zu verwenden, um viele feinkörnige WCF-Verträge in einer einzigen Bibliothek zu kombinieren.Es funktioniert sehr gut, allerdings kann die neue zusammengeführte Bibliothek nicht problemlos mit ihren Komponentenbibliotheken oder anderen Bibliotheken, die von diesen Komponentenbibliotheken abhängen, koexistieren.

Wenn Sie in einem neuen Projekt sowohl auf Ihre ILMerged-Bibliothek als auch auf eine Legacy-Bibliothek verweisen, die von einer der Eingaben abhängt, die Sie an ILMerge gegeben haben, werden Sie feststellen, dass Sie keinen Typ aus der ILMerged-Bibliothek an irgendeine Methode in übergeben können die Legacy-Bibliothek, ohne irgendeine Art von Typzuordnung durchzuführen (z. B.Automapper oder manuelles Mapping).Dies liegt daran, dass die Typen, sobald alles kompiliert ist, effektiv mit einem Assemblynamen qualifiziert werden.

Die Namen werden ebenfalls kollidieren, aber Sie können das mit beheben Externer Alias.

Mein Rat wäre, zu vermeiden, in Ihre zusammengeführte Assembly öffentlich verfügbare Bibliotheken aufzunehmen, die Ihre zusammengeführte Assembly verfügbar macht (z. B.über einen Rückgabetyp, einen Methoden-/Konstruktorparameter, ein Feld, eine Eigenschaft, generisch usw.), es sei denn, Sie wissen sicher, dass der Benutzer Ihrer zusammengeführten Assembly nicht auf die freistehende Version derselben Bibliothek angewiesen ist und dies auch nie tun wird.

Es scheint mir, dass die beste Best Practice für ILMerge darin besteht, ILMerge nicht zu verwenden.Verwenden Sie stattdessen SmartAssembly.Ein Grund dafür ist, dass die zweitbeste ILMerge-Best Practice darin besteht, PEVerify immer nach der Durchführung eines ILMerge auszuführen, da ILMerge nicht garantiert, dass Assemblys korrekt in eine gültige ausführbare Datei zusammengeführt werden.

Weitere Nachteile von ILMerge:

  • Beim Zusammenführen werden XML-Kommentare entfernt (wenn mich das interessieren würde, würde ich ein Verschleierungstool verwenden)
  • Die Erstellung einer entsprechenden .pdb-Datei wird nicht ordnungsgemäß durchgeführt

Ein weiteres Tool, das es wert ist, beachtet zu werden, sind Mono.Cecil und das Tool Mono.Linker [2].

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

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top