Fremd-DLLs in eigene DLL einbetten

Hallo Zusammen,

ich erstelle gerade eine DLL die zwingend zwei fremde DLL's (eine C# und eine C++) benötigt.
Ich möchte nun vermeiden, alle drei mitzugeben sonder dachte mir, dass ich die fremd-Dll's auch in meine einbetten kann.
In Visual-Studio rein technisch kein Problem, meine DLL wächst im Platzbedarf auch um die zwei fremden, doch leider findet meine DLL die fremden nicht. D.h. ich muss sie trotzdem explizit als Datei zur Verfügung stellen.

Gibt es hierfür eine Lösung?

Zweite Frage nebenbei:
Warum beschwert sich Visual Studio (express edition) wenn ich System.Windows.Forms nutzen möchte? Es sagt mir System.Windows wäre nicht Teil des Namespaces. Gibt es für DLL's Randbedingungen, die ich zu beachten habe?

Vielen Dank
Christof

Hallo christof.k,

ich kann Dir leider nur zu Deiner 2. Frage spontan antworten:

wahrscheinlich fehlt Dir die Referenz "System.Windows.Form.dll", die Du unbedingt für Deine Dll mit angeben musst. Ohne die gibts auch keine Forms 😉

Gruß
Norman-Timo

Zur 1. Frage: Zumindest gibt es keine Lösung, die Out-Of-The-Bpx funktioniert. Theoretisch kann man zwar Assemblies direkt aus dem Speicher (bzw. Resource) laden, aber das erfordert eine Interface-bassierte Architektur.

In der Praxis steht der Aufwand im Vergleich zum Nutzen (den ich nicht sehe) wohl in keinem Verhäntnis. Besser du findest dich mit der Tatsache ab, dass die Zeiten vorbei sind, bei denen eine Anwendung aus nur einer EXE (ggf. mit einer DLL...) bestand. Dem User ist das meiner Erfahrung nach fast immer Wurscht (ich höre solche Wünsche eher von noch relativ unerfahrenen Entwicklern oder von Chefs die in den 80ern selbst mal Entwickler waren und nicht gemerkt haben, dass die Zeiten sich verändert haben). Wichtiger ist eher mögliches XCopy-Deployment bzw. -Backup/Restore.

@svenson: Im Prinzip stimm ich Dir zu, das heisst aber nicht, dass es nicht einfach möglich wäre:
Die Dll's einfach als Ressource mit in die Assembly packen, dann zur Laufzeit den Stream daraus holen und die Assembly aus diesem Stream laden...

Bart Simpson

Genau das meinte ich ja. Nur: Wie rufst du jetzt dort eine Methode auf? Die Klasse war ja zur Compile-Time des Basismoduls nicht bekannt. Also musst du dynamisch aufrufen, bzw. du musst Interfacemethoden aufrufen (Interface wäre Basismodul im Basismodul definiert. Kreuzreferenzen entstehen durch das dynamsiche Laden ja nicht).

Das meinte ich mit Interface-basierter Architektur.

Das ganze wäre fast zu 100% ein PlugIn-Konzept, nur dass das PlugIn als Resource in der Exe vorliegt.

Man kann also nicht einfach eine Compiler-Option oder sowas setzen (das meinte ich mit Out-Of-The-Box), sondern muss bereits die Architektur auf das Verfahren auslegen.

Original von svenson
Das ganze wäre fast zu 100% ein PlugIn-Konzept, nur dass das PlugIn als Resource in der Exe vorliegt.

Man kann also nicht einfach eine Compiler-Option oder sowas setzen (das meinte ich mit Out-Of-The-Box), sondern muss bereits die Architektur auf das Verfahren auslegen. 100% ACK! Hatte Dich wohl beim ersten Mal nicht richtig verstanden... Im Prinzip hab ich genau über das Gleiche gequatscht 😁

Beim Lesen Deines Beitrags ist mir aber dann folgendes eingefallen (nicht getestet, und nicht belegt, ich meine aber mich an die wesentlichen Eckpunkte in MSDN Beiträgen zu erinnern!):
Theoretisch sollte folgendes Szenario machbar sein (korrigiert micht, wenn ich mich irre):
1.) Die nötigen DLL's werden ganz normal referenziert.
-> Der Complier schmeisst sie mit ins bin Verzeichniss
2.) Die DLL's werden zusätzlich als Ressource eingebunden, somit stehen Sie für das in meinem vorigen Beitrag skizzierte Handling zur Verfügung
3.) [Der Knackpunkt] Wenn ich mich recht entsinne, lädt das .net Framework die benötigten Assemblies erst dann, wenn es sie wirklich braucht.
-> Wenn direkt beim Start der Exe dafür gesorgt wird, dass die DLL's "da sind", dann sollte es der Loader quasi gar nicht mitkriegen, dass Sie ursprünglich nicht da waren.
-> Es müsste genügen die Exe zu verteilen und die DLL's dynamisch zu erzeugen (respektive zu laden).

Bart Simspon

Müßte gehen. Mit dem AppDomain.AssemblyResolveEvent kann man dann die fehlende Referenz auflösen.

Für die C#-Assembly ist genau das mittels IlMerge ohne weiteres möglich (Einsatz im kommerziellen Umfeld soweit ich weiß jedoch untersagt). Siehe auch: http://research.microsoft.com/~mbarnett/ILMerge.aspx

Was die C++ Windows DLL angeht wird IlMerge allerdings nicht funktionieren. Dafür musst du dir also noch eine andere Lösung suchen.

Dann nur noch eine Frage zur Compile-Option "Embedded Resource":

Was heißt das für meine DLL, wenn ich diese einbette? Sie ist dann ja Teil meiner EXE.
Aber da Ihr diese Lösung nicht erwähnt habt wird dies hier wohl nicht funktionieren.
Interessier mich nur, was dabei passiert....

bis bald
Christof

Genau diesen Fall haben wir die ganze Zeit diskutiert. Die DLL als embedded Resource, dann als Stream in ein Byte-Array laden und dann in die AppDomain laden.

Übrigens: Mit einer C++-DLL funktioniert das nicht...

_Original von svenson_Übrigens: Mit einer C++-DLL funktioniert das nicht...

Warum nicht? Genau bei "Nicht-.net-DLL's" (aka PINVOKE) hab ich den "Trick" schon angewandt... das klappt perfekt weil die DLL erst dann geladen wird, wenn tatsächlich eine Funktion aus ihr aufgerufen wird...

Bart Simpson

Thema war "DLL als embedded resource". Da wirds dann schwierig. LoadLibrary() verlangt einen Filenamen. Man könnte natürlich die DLL aus der Resource auf die Platte schreiben. Aber dann kann man sie wohl gleich mit ausliefern...

_Original von svenson_Man könnte natürlich die DLL aus der Resource auf die Platte schreiben. Aber dann kann man sie wohl gleich mit ausliefern...

Jap... aber wer wird denn gleich so kritisch sein 😉
Spass beiseite - das kann trotzdem seine Berechtigung haben. Z.B. in Bezug auf vereinfachtes Deployment. Und aus meiner Sicht war die Frage ja auch nur "ob's geht" - und das tut es 😁

Bart Simpson

Und da schliesst sich der Kreis: Was sind die konkreten Vorteile, wenn das Projekt nur aus einer Datei besteht? Ist weniger automatisch mehr? Ich bin ja auch ein großer Fan von XCopy-Funktionalität, aber ob ich nun ein Verzeichnis kopiere oder eine Datei spielt nun wirklich keine Rolle, oder doch?

Ich hab noch keine schlüssige Begründung für sowas gehört außer: "Mein Chef/Kunde will es so." Das ist zwar beruflich ein Thema, allerdings eben nicht fachlich.

Völlig korrekt. Das einzige fachliche Argument, das mir einfiele ist das, womit ich hier zuhauf konfrontiert bin: DAU-Sicherheit - Sprich: "Wie verhindere ich von vornherein Fehler durch idiotisches Verhalten..."
Aber ansonsten kann ich wirklich keine Vorteile erkennen - zumal man normalerweise einfach einen Installer liefert und dann klappts auch.

Bart Simpson