Win32 DLL zur Laufzeit dynamisch einbinden

Hallo,

wie kann ich in C# ein Win32 DLL dynamisch einbinden? Statisch mit DLLImport ist klar, Assemblies dynamisch laden auch, aber wie zum ... binde ich Win32 DLL's dynamisch ein?

Zu welchem Zweck. Dynamische Bindung verwendet man normalerweise, wenn die eingebundene Komponente vielleicht nicht verfügbar ist (z.B. Office). Die Win32-API ist aber auf jedem Windows-System vorhanden.

Wer will denn die Win32-API in C# nutzen? Dafür gibt es guten .NET Ersatz. Es gibt aber andere schöne Dinge wie in meinem Fall sevDTA32 das nicht jeder Kunde von uns hat/bekommt.

Wen Du DLL-Imports machst, wird erst dann die DLL geladen/angefordert,
wenn Du tatsächlich einen aufruf machst.

Wenn Du diese Aufrufe mit Try/Catch abfängst, ist doch alles in Butter.

Schau mal hier:

http://www.codeproject.com/csharp/dynamicinvokedll.asp?df=100&forumid=141359&select=1008476#xx1008476xx

Unter NET 2.0 kann man einen Wert von GetProcAdress() direkt verwenden, bzw. in einen Delegaten-Aufruf umwandeln.

Alternativ kann man das mittels einer Wrapper-DLL, die eine Pseudo-Funktion für jede Signatur enthält und ein Stück Assembler-Code, der die Einsprungadresse der Funktion auf den Stack legt und die Parameter rauf- und runterschaufelt das Problem lösen (gabs auch mal was unter CodeProject). Finde ich persönlich aber unschön, da u.U. aufwändig (viele Signatur-Funktionen) und änderungsunfreundlich. Dafür aber performant weil außer dem eigentlichen PInvoke kein zusätzlicher Code notwendig ist (Reflection o.ä.).

Das Ganze läßt sich auch sinnhaft verwenden, z.B. wenn man unmanaged Plugins verwenden muss. Die Idee ist ja ein wenig älter als .NET.

Hm, naja, wenn DLLImport sowieso dynamisch ist, ist es aber immer noch Mist, dass der Dateiname eine Konstante sein muss und ich wirklich nur per try einen Fehler verhindern kann, statt vor dem manuellen dynamischen Laden zu prüfen, ob die Datei da ist. Naja, es gibt schlimmeres. Oder ich nehme unmanaged Win32 Code um die Win32-DLL dynamisch zu laden. Das wäre wenigsten konsequent! 😉

Das sind zwei veschiedene Dinge.

DLLImport ist nur eine Vereinfachung für "statisches" Linken.

Du kannst jederzeit dynamisch die DLL aufrufen, allerdings musst
du das umständlich so machen wie in svensons link beschrieben.

Aber ändert sich der name deine DLL denn?

Nicht der Name, aber evtl. der Ort. Die sevDTA32.dll muss oft erneuert werden (die Banker scheinen den ganzen Tag BLZ's zu ändern) und ich habe nur umständlich Zugriff auf das ...\sytem32 Verzeichniss auf dem Server. Geht zwar aber naja, jeder biegt es sich gern so, wie es am bequemsten ist. Habe das jetzt einfach in eine gesonderte Assembly gepackt, die ich dann entwender mit der Anwendung mitliefere oder nicht.

Wieso system32? Du kannst alle DLLs auch mit in den Anwendungspfad ballern.

Aber ich kann aus deiner Beschreibung immer noch keine Notwendigkeit erkennen, die DLL dynamisch zu laden. Das macht wirklich nur im Falle von PlugIns oder bei großem Ressourcen-Hunger der DLL Sinn und der daraus folgernden Notwendigkeit, die DLL vor Programmende wieder aus dem Prozessraum zu entladen.

Es ist ja quasi ein Plugin unserer Anwendung. Da es eine ASP.NET-Anwendung ist, ist der Ausführungspfad eine Geschichte für sich! Naja, es geht so wie es jetzt ist.