4. "Could not load file or assembly..." beim Verwenden einer C++/CLI-dll aus dem C++ Builder

"Could not load file or assembly..." beim Verwenden einer C++/CLI-dll aus dem C++ Builder

  • A

    Ich habe eine C++/CLI-dll die ich vom C++ Code aus dem C++ Builder nutze (Die dll wird dynamisch gebunden). Funktionierte bislang (von dem ein oder anderen c-Problem abgesehen) alles, scheitert nun eine Funktion mit der Exception "'Could not load file or assambly 'System.DirectoryServices.Protocols, Version=8.0.0.0, Culture=neutral, PublicKeyToken"...

    Diese dll liegt ebenso im Verzeichnis, wie eine Reihe von anderen .net-dlls die ich nutze (und bei denen es bislang kein Problem gab). Auch ist diese dll in einer ".deps"-Datei aufgeführt.

    Hat jemand ein ähnliches Problem schon gehabt und weiß vielleicht einen Lösungsansatz?

    0

  • Evtl. hat diese Assembly noch weitere abhängige Assemblies, was du mit dem DependencyWalker.Net herausfinden kannst.

    PS: Hat dir eigentlich meine Antwort zu deinem letzten Beitrag C-Style DLL-Schnittstelle mit C++/CLI und Stringübergaben weitergeholfen?

    0
    A
     1 Antwort
  • A

    @Th69 Der Dependency-Walker funktioniert leider nicht (auch nicht die dort aufgeführte .net Core Variante, die ohnehin als Beta markiert war) [und eigentlich sollte Publish auch die Abhängigkeiten zusammensuchen]. Die Antwort zum letzten Beitrag hatte mich etwas weitergebracht, wenn ich auch die Schnittstelle komplett überarbeitet habe. Ich kann die C++/CLI-dll inzwischen nutzen, aber bin nun über diesen weiteren Fehler gestolpert.

    0

  • Welche .NET-Version benutzt du denn (noch Framework 4.x oder schon .NET 5 oder höher)?

    Bei mir, unter Windows 10, funktionieren beide DependencyWalker.Net Versionen.

    Edit: Sorry, du benutzt ja 8.0 (steht ja in der von dir geposteten Fehlermeldung).
    Ich finde diese DLL auch nur im .NET Framework, nicht in den Core-Ordnern ("Program Files\dotnet\shared") - hier nur "System.DirectoryServices.dll".
    Oder hast du die Datei "'System.DirectoryServices.Protocols.dll" aus einem NuGet-Paket heruntergeladen?

    Für die .NET Framework 4.7.2-Datei wird mir folgendes als Referenzen angezeigt:

    mscorlib
System
System.Configuration
System.Xml
System.Data.SqlXml
System.Security
System.Core
System.Numerics
System.DirectoryServices

C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Data.SqlXml/v4.0_4.0.0.0__b77a5c561934e089/System.Data.SqlXml.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Security/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Security.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll
C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.DirectoryServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.DirectoryServices.dll

    Noch ein Edit:
    NuGet-Paket gefunden: System.DirectoryServices.Protocols

    0
    A
     1 Antwort
  • A

    @Th69 Ich beziehe die meisten dlls über nuget, es ist die 8.0-Version der dll (wie auch in der Fehlermeldung sichtbar "'System.DirectoryServices.Protocols, Version=8.0.0.0").

    Auch wenn es nicht der DependencyWalker ist, habe ich es mal über Reflection versucht, dort bin ich aber auch nicht über fehlende dlls gestolpert.

    0

  • Rufst du denn direkt eine Methode aus System.DirectoryServices.Protocols auf?
    Ansonsten könntest du mal AppDomain.AssemblyResolve verwenden und schauen, welche andere Assembly diese laden möchte (s. ResolveEventArgs) und wo diese Assembly liegt (und vllt. wegen einem anderen Pfad die "System.DirectoryServices.Protocols.dll" in deinem Programmverzeichnis nicht findet).

    0
    A
     1 Antwort
  • A

    @Th69 Ich nutze direkt Klassen aus dieser dll. Ich schaue mir mal nach meinem Urlaub noch den anderen Hinweis an.

    Was ich nicht verstehe das es wiederum aus einer C#-Konsolenanwendung die intern die gleiche Implementierung (liegt in einer gemeinsam genutzten C#-dll) wie die C++/CLI-dll nutzt, es keinerlei Probleme gibt. Ebenso nicht, wenn eine andere Funktion über die Schnittstelle genutzt wird.

    Es ist jedenfalls auch genau die Version der dll, die auch in der ".deps.json" zur C++/CLI-Bibliothek aufgeführt ist.

    0

  • Laß dir mal vor dem fehlerhaften Aufruf Environment.CurrentDirectory ausgeben. Ist dieses in beiden Programmen das aktuelle Programmverzeichnis?

    0
Anmelden zum Antworten