Wie wirkt sich das .NET-Zielframework auf das Laden von DLLs von Drittanbietern aus?

Ich entwickle eine Anwendung (C# winforms), die auf einer Hersteller-DLL, die mit Hardware kommuniziert, beruht.Wie wirkt sich das .NET-Zielframework auf das Laden von DLLs von Drittanbietern aus?

Wenn ich ein Ziel Rahmen von .NET 4 (oder etwas höher) wählen, erhalte ich die folgende Meldung beim Versuch, eine Methode in der referenzierten DLL aufzurufen:

DllNotFoundException: Kann nicht somelibrary‘DLL laden .dll ': Ungültiger Zugriff auf den Speicherort. (Ausnahme von HRESULT: 0x800703E6)

Wenn ich ein Zielframework von .NET 2.0 oder 3.0 auswähle, tritt der Fehler nicht auf.

Ich vermute, dass es eine Inkompatibilität oder dass die Bibliothek älter als .NET 3.0 ist.

Es liegt wahrscheinlich daran, dass die .DLL eine ausführbare Datei startet, die als Kommunikationshandler zwischen der Anwendung und einem seriellen Port fungiert. Ich habe versucht, diese Anwendung einzustellen, um verschiedene Kompatibilitätsmodi zu verwenden und als Administrator ohne Erfolg auszuführen.

Was kann ich tun, um diesen Fehler zu vermeiden und eine modernere .NET-Plattform wie 4.5 oder höher anzusprechen? (Oder bin ich unbedingt wegen der Verwendung einer möglicherweise ziemlich alten DLL stecken?)

Das Ziel der Anwendungsplattform ist x86 und ich bin auf Win7 x64 mit UAC auf Standardeinstellungen entwickeln.

Quelle

2017-08-08 JYelton

Ist es eine .net-Assembly, die Sie versuchen zu laden? Haben Sie versucht, es mit 'ildasm.exe' zu öffnen? Gibt es zusätzliche Informationen von 'fuslogwv.exe'? – ironstone13

@ ironstone13 Ich werde weiter mit den Tools, die Sie vorgeschlagen haben, untersuchen. Ich bin mir nicht sicher über die Art der Montage. – JYelton

Ich sage nicht, das ist 100% richtige Lösung, aber hier ist die Idee, glaube ich, gültig.

Dieser Fehler tritt normalerweise auf, wenn die Abhängigkeit fehlt. In Ihrem Fall Abhängigkeit für Ihre somelibrary.dll. In FW2.0 wurden die meisten Dateien in einigen Program files (x86)\Reference Assemblies... gespeichert. Wir wissen, dass sich einige Dinge in FW4 + geändert haben und einige Klassen verschoben wurden und Assemblies nicht mehr in Program Files sondern über Nuget heruntergeladen wurden. Was [höchstwahrscheinlich] passiert, wenn Sie FW4.0 + als Ziel haben, beginnt Ihre App nach Abhängigkeiten für v4.0 zu suchen. Ich würde etwas Disassembler wie freies dotPeek verwenden, um zu schauen, welche Hinweise Sie in der betreffenden DLL haben. Und dann würde ich versuchen, diese auf der Maschine zu finden und zu sehen, wenn Sie keine Versionskonflikte in Bezug auf Namespaces haben

Quelle

2017-08-08 20:21:23

Danke für die Antwort/Vorschlag. Ich bin mit dotPeek nicht vertraut, also werde ich nachforschen und sehen, ob es einen Einblick gibt. – JYelton

@JYelton Einfach google JetBrains dotPeek. JetBrains ist eine seriöse Firma, die eine Reihe von wichtigen Tools für .net hat, wie "Resharper". Laden Sie es herunter, installieren Sie es und öffnen Sie die DLL mit diesem Programm. Oder Sie können etwas wie 'NDepend' verwenden. Sicherlich gibt es viele Werkzeuge, die es tun werden. Aber dotPeek ist auch ein Reflektor. Sie können den Code darin sehen. Es sei denn, DLL, die Sie haben, ist verschleiert. Dann hilft dotPeek wenig. Aber ich weiß nicht, ob Abhängigkeitsbetrachter Referenzen in verschleierten DLLs sehen können –

Wie wirkt sich das .NET-Zielframework auf das Laden von DLLs von Drittanbietern aus?

Antwort

Verwandte Themen