Angenommen, ich habe ein .NET/CLR-Programm Hello.exe(oder eine DLL Hello.dll), das von verschiedenen .NET-DLLs von Drittanbietern abhängt. Ich möchte eine einzelne Datei versenden, ohne ein tatsächliches "Installationsprogramm" bereitzustellen, also suche ich nach einer Software, die alle Abhängigkeiten in die ausführbare Datei packen und sie dann laden kann, bevor irgendeiner meiner Codes ausgeführt wird.
Ich brauche es auch, um jede bereitgestellte DLL bedingungslos zu laden, nicht nur "on-demand", da auf einige der Typen in den DLLs über Reflektion zugegriffen wird und der Klassenlader daher niemals versuchen wird, die DLL explizit zu laden und somit die aufzurufen Klasse Ladehaken. Ich möchte meiner ausführbaren Datei keinen Code hinzufügen müssen, wenn dies ohne meinen eigenen Code möglich ist.
Ich verwende SharpDevelop und .NET Framework 4.0 Full Profile, aber die ideale Lösung für dieses Problem wird IDE-agnostisch sein und mit .NET 3.0 oder höher funktionieren (2.0 wäre noch besser, aber werden wir nicht gierig ...)
Wie wäre es mit ILMerge ? Es gibt es schon lange und es gibt viele Ressourcen. Hier ist zum Beispiel eine kurze Einführung . Auch Stackoverflow-Fragen haben bereits einige häufige Fallstricke behandelt, wie z. B. das Zusammenführen von DLL mit EXE .
Es ist auch unabhängig von Ihrer Build-Umgebung. Sie müssen es nur in Ihren Build-Prozess einbetten.
ILMerge ist leider nicht perfekt. Beispielsweise wird das Zusammenführen von WPF-Assemblys nicht unterstützt. Die Alternative besteht darin, die Bibliotheken als Ressourcen einzubetten und dynamisch zu laden. Siehe zum Beispiel diesen Blogbeitrag . LibZ Container, den allquixotic erwähnt hat, macht das im Grunde.
Zum LibZ-Container gibt es eine andere Alternative, die erprobt ist und über die ich ernsthaft nachdenken würde: Fody.Costura
Mono mkbundle könnte eine weitere Alternative sein, beachten Sie jedoch, dass es nativen Code erzeugt. Abhängigkeiten können statisch verknüpft werden. Unter Windows muss auch Cygwin ausgeführt werden können (siehe auch diesen Forenthread )
LibZ Container instrumentiert Ihre Hauptassembly mit Code, der gezippte Assembly-Ressourcen aus der Ressourcendatei entpackt und aus dem Speicher lädt. Es behauptet, sowohl mit Reflexionscode als auch mit starken Namen zu arbeiten, und es ändert die ursprünglichen Assemblydateien in keiner Weise, sodass Referenzen mit starken Namen gut funktionieren.
il-repack erfüllt teilweise die Kriterien der Antwort, packt aber leider die Assemblys neu, wodurch ihr starker Name zerstört wird. Wenn Sie also auf Assemblys angewiesen sind, die mit einem starken Namen signiert sind, funktioniert dies nicht. Es funktioniert auch nicht mit dem meisten Reflektionscode, bis die Assemblys in die Klasse geladen wurden.
Muh-Saft
Assembly.LoadFromfür die eigentliche Arbeit verwenden?Benutzer626528
allquixotisch