Zusammenfassung
Ich möchte den Erstellungsprozess einer 2-Assembly-Lösung ändern, sodass ein Aufruf von ILMerge aufgerufen wird und der Build zu einer einzelnen Assembly führt. Weiter möchte ich in der Lage sein, in die resultierende Baugruppe zu debuggen.
Vorbereitung - Ein einfaches Beispiel
Sie haben jetzt eine 2 Assembly-App, die "Hello World" an die Konsole ausgibt.
Also was als nächstes ...?
Ich möchte den Build der Console-App ändern, um einen Post-Build-Schritt zu integrieren, der ILMerge verwendet, um die ClassLibrary-Assembly in die Console-Assembly einzufügen.
Nach diesem Schritt sollte ich in der Lage sein:
Begrenzter Erfolg
Ich las diesen Blogpost und schaffte es, die Zusammenführung, die ich suchte, mit einem zu erreichen Nachbaubefehl von ...
%Vor%... und eine ILMerge.bat-Datei, die ...
liest %Vor%Dies funktioniert ziemlich gut und erzeugt tatsächlich eine exe, die außerhalb der VS-Umgebung wie erforderlich ausgeführt wird. Es scheint jedoch keine Symbole (.pdb-Datei) zu erzeugen, die VS verwenden kann, um in den Code zu debuggen.
Ich denke, das ist das letzte Puzzleteil.
Weiß jemand, wie ich das schaffen kann?
FWIW Ich starte VS2010 auf einem x64 Win7 x64 Rechner.
Update: Warum möchte ich das tun?
Es wurde gefragt: "Muss ich wirklich ILMerge während des Debug-Szenarios?"
Die Assemblies meiner Lösung müssen in demselben Ordner existieren wie die anderen Lösungen (von denen ich wahrscheinlich einige entwickeln werde)
Einige dieser Lösungen teilen Abhängigkeiten von verschiedenen Versionen einiger Assemblys.
Solution1 könnte also aus Console1 und ClassLibrary1.dll (v1) bestehen und Solution2 könnte aus Console2 und Classlibrary1.dll (v2) bestehen.
Anstatt alles im GAC zu registrieren, dachte ich, ich könnte die korrekte Version einer Abhängigkeit in die primäre Assembly der Lösung einfügen, um eine Kollision zu vermeiden.
Dies macht es jedoch momentan unmöglich, die Lösung zu debuggen, was ich in Verbindung mit den anderen vorhandenen Lösungen machen muss.
Klingt das kompliziert? Das ist, weil es .. ist: D
Es tut mir leid, dass Sie Probleme haben. Ich habe Ihre genauen Schritte nicht ausgeführt, aber ich habe eine Konsolenanwendung namens A..exe erstellt, die eine Methode in einer DLL namens B.dll aufgerufen hat. Ich baute beide Assemblies im Debug-Modus (so dass sie PDB-Dateien hatten). Ich habe sie dann so zusammengeführt:
ilmerge /out:foo.exe A.exe B.dll
(Eigentlich waren A und B in einem anderen Verzeichnis, daher war meine Befehlszeile ein wenig komplizierter, aber das sollte keinen Unterschied machen.) Nachdem ILMerge abgeschlossen war, befanden sich im aktuellen Verzeichnis zwei Dateien: foo.exe und foo .pdb. Ich tippte dann:
devenv foo.exe
Dies öffnete Visual Studio und dann drückte ich "F10", um den Debugger zu starten. Ich konnte in der ausführbaren Datei in die Main-Methode wechseln und dann mit "F11" die Methode aufrufen, die ursprünglich in B.dll enthalten war. Das Debugging war genauso wie in der ursprünglichen Visual Studio-Lösung mit den beiden Assemblies.
Wenn Sie immer noch Probleme haben, können Sie Ihre gesamte Lösung in eine Zip-Datei packen und an mich senden (mbarnett unter Microsoft dot com) und ich kann es ausprobieren.
Ich würde vorschlagen, dass Sie nur ILerge Release-Builds Ihrer Assemblys erstellen. Ich kann mir keinen Nutzen vorstellen, den Sie durch das Zusammenführen von Debug-Assemblys erhalten würden.
Ich habe versucht, so etwas zu tun und festgestellt, dass nichts umbenennen sollte, weder vor noch nach der Zusammenführung. Das Verschieben von Daten in ein separates Verzeichnis ist in Ordnung. Wenn Sie nichts umbenennen, funktioniert es.
Ich glaube nicht, dass ILMerge das kann. OTOH Smartassembly von Red-Gate (nicht frei) kann es tun, zumindest so, wie es bei Funktionen
Und ich stimme Mike zu, ILMerge nur für Release-Versionen zu verwenden.
Tags und Links visual-studio-2010 debugging symbols ilmerge