Findet dll im Unterordner x64 nicht

Hallo,
ich möchte eine einfachen PDF-Reader Plugin mit PDFium erstellen.

Zudem PDFiumViewer hab ich was auf YoTtube gefunden:
YouTube Pdf viewer based on pdfium viewer in c# .net

Wenn ich es in einer Windows-Form-App erstelle funktioniert es.
Leider benötige ich es aber in einer Windows Forms-Steuerelementbibliothek.

hier findet er beim öffnen der PDF-Datei die dll nicht.
(in

PdfDocument pdfDocument = PdfDocument.Load(stream);

erhalte ich folgende Meldung: > Fehlermeldung:

System.DllNotFoundException: "Die DLL "pdfium.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden."

Wenn ich die dll manuell vom Unterordner X64 in den Ordner "Debug" kopiere funktionert es.

Was mache ich falsch?
Wie kann ich auf die dll im Unterorder verweisen?

Ich hoffe es kann mich jemand auf die richtige Spur bringen.

Vielen Dank

Es ist aber so, dass Du prinzipiell Dependencies mitliefern musst.
Hast Du also übergreifende Projekte, dann musst Du im konsumierenden Projekt das NuGet auch installieren.
Ansonsten _kann _die DLL im Output fehlen. Da hilft dann die DLL manuell beim Build zu kopieren.

Das verlässtigste Verhalten kann man erreichen, indem man aus der Bibliothek ein NuGet Paket macht und das wiederum eine Abhängigkeit auf das PDF Paket hat.
So wird beim Restore der Dependency Tree geladen und alles ist da; aber ja - nicht immer praktikabel.

Hast Du also übergreifende Projekte, dann musst Du im konsumierenden Projekt das NuGet auch installieren.

Wie kann ich hier die NuGet Packete in den Testcontainer beim Debuggen installieren??

Das PDF-Plugin soll später in ein WinCC Scada System eingebunden werden.

ich glaube nicht das ich hier NuGet Packete installieren kann.

Naja, wäre gut gewesen wenn Du das gleich erwähnt hättest, was Deine Umgebung ist.
Dann willst Du das Control in einer externen Anwendung und nicht in einer von Dir gesteuerten Forms Anwendung nutzen.

Du musst dafür sorgen, dass alle Abhängigkeiten, die eine DLL benötigt, mitgeliefert werden.

Ich hab nun auch mal eine Control Library erstellt, um anzuschauen, ob bei mir irgendwas - und das ist nicht der Fall.
Mein Buildprozess legt sauber alle notwendigen DLLs sowohl in den Debug, den Release und einen potentiellen Publish Folder ab.

Daher scheint da was bei Dir nicht zu stimmen.
Bist Du Dir sicher, dass Du das NuGet Paket korrekt hinzugefügt hast?
Steht bei der Pdfium Referenz in Visual Studio "Copy Local" auch auf True?

Steht bei der Pdfium Referenz in Visual Studio "Copy Local" auch auf True?

Wo finde ich die Pdfium Referenz im Visual Studio?

Solution Explorer -> References

Die "PDFium.dll" ist eine native C-DLL, also keine Assembly...

Steht auch in Pdfium.Net SDK (sowie das Einbinden ins Projekt).

Ich denke das einfachste wird sein, diese DLL im selben Verzeichnis wie die Steuerelementbibliothek zu kopieren (anstatt in einem Unterordner) (am besten sogar im selben Verzeichnis wie die auszuführende Anwendung).

Da diese DLL wohl per [DllImport] eingebunden wird, kann man nur per WinAPI-Funktion SetDllDirectory den Suchpfad ändern, s.a. How can I specify a [DllImport] path at runtime? (Wichtig ist, daß dies vor dem Aufruf der ersten Funktion aus dieser DLL passieren muß).

Hallo Th69,

Da diese DLL wohl per [DllImport] eingebunden wird, kann man nur per WinAPI-Funktion
> den Suchpfad ändern, s.a.
> (Wichtig ist, daß dies vor dem Aufruf der ersten Funktion aus dieser DLL passieren muß).

SO liefert nicht immer die besten Lösungen, v.a. wenn wir hier im Forum etwas (in der FAQ) dazu haben 😉 => 32bit/64bit unmanaged DLL "importen" - wie?

mfG Gü

Ich finde die SO-Lösung aber trotzdem besser als deine (aus der FAQ), da es bei dir passieren kann, daß eine andere DLL gleichen Namens (z.B. weil ein anderes Programm dieses genauso eingetragen hat, aber die DLL z.B. in einer anderen Version hat) genommen wird (weil du dann auch noch den Pfad ganz als letztes eingetragen hast).

Ich habe aber noch etwas nachgelesen und daher sollte statt SetDllDirectory besser AddDllLibrary (+ vorher SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_USER_DIRS)) verwendet werden (bei SetDllDirectory hat mich das "Adds a directory to the process DLL search path." verwirrt, jedoch überschreibt es vorherige Aufrufe).

Wie auch immer, am sichersten ist es die DLL aus dem Anwendungsverzeichnis zu laden.

Hallo Th69,

Wie auch immer, am sichersten ist es die DLL aus dem Anwendungsverzeichnis zu laden.

👍

Und der Vollständigkeithalber noch die Erwähnung von NativeLibrary welches mit .NET Core 3.0 Einzug gehalten hat.

mfG Gü