Hallo,

bei einem C#-Programm von mir ist eine DLL (ITapi3.dll) als Verweis eingebunden.
Das Programm habe ich mit MS Visual Studio 2019 kompiliert.
Wenn ich das Programm in einer Eingabeaufforderung starte, kommt diese Fehlermeldung:

Fehler

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'ITapi3.dll' or one of its dependencies. The specified module could not be found.

Wenn gemeldet wird, dass ein module nicht gefunden werden konnte, dann sollte man meinen, dass nach einem module gesucht wurde und nicht nach irgendeinem, sondern nach einem bestimmten.
Die Fehlermeldung verrät leider nicht welches module vermisst wird.
Nebenbei gefragt: Was ist eigentlich ein module?

Meine eigentliche Frage lautet: Wie kann man herausfinden nach welchem module gesucht wurde?

Die genannte ITapi3.dll wird übrigens nicht vermisst, denn wenn die Datei nicht vorhanden ist, sagt die Fehlermeldung:

Fehler

... The system cannot find the file specified.

Ich weiß aber, dass der Fehler mit dieser DLL zusammenhängt.
Der Fehler tritt übrigens nicht auf, wenn ich das Programm auf einem Rechner starte auf dem MS Visual Studio installiert ist.

Ich erhoffe mir eine allgemeine Antwort wo und wie man dem Fehler auf die Schliche kommen kann, daher habe ich keine spezifischen Details gepostet, die dann vielleicht von der Allgemeinheit der Frage ablenken.
Falls Informationen über mein Projekt und mein System dennoch erforderlich oder hilfreich sein sollten, reiche ich gerne alles nach.

Gruß Frank

Hallo Pedant,

Zitat

Nebenbei gefragt: Was ist eigentlich ein module?

In .NET besteht eine Assembly aus einem od. mehreren Modulen. I.d.R. jedoch nur aus einem Modul, daher verinfacht (und nicht ganz korrekt): Assembly = Modul.
Weiters hat eine Assembly ein Manifest, so dass diese auch von der CLR geladen werden kann, während das Modul den "ausführbaren" Teil enthält (also Code, Resourcen, etc.).

Zitat

Wenn gemeldet wird, dass ein module nicht gefunden werden konnte, dann sollte man meinen, dass nach einem module gesucht wurde und nicht nach irgendeinem, sondern nach einem bestimmten.

Das stimmt, allerdings kann die CLR (die Laufzeitumgebung in .NET) nur managed Assemblies / Module verfolgen.
Sobald es in den unmanaged / nativen Bereich geht, kann die CLR das nicht mehr verfolgen, daher ist die Fehlermeldung nicht mehr sehr präzise.

Die ITapi3.dll ist lt. Beschreibung " C++/CLI TAPI 3.0 client .NET wrapper" als eine "mixed mode assembly". D.h. sie hat einen manged Teil (den die CLR ausführen kann) und einen nativen / unmanaged Teil. Entsprechend Fehlermeldung scheint es so, als ob eine native Abhängigkeit vermisst wird ("or one of its dependencies").
Ist die ITapi3.dll richtig installiert bzw. das naitve tapi3.dll vorhanden?
Versuch mal mit ILSpy o.ä. die Referenzen anzuschauen. Dort sind die nativen Abhängigkeiten (in erster Ebene) angeführt. Sonst ev. mit DependencyWalker* gucken was fehlt.

Edit: * den gibts jetzt sogar neu: GitHub - lucasg/Dependencies: A rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.

mfG Gü

Hallo gfoidl,

vielen Dank für Deinen ausführlichen und sehr hilfreichen Beitrag.

Zitat

Edit: * den gibts jetzt sogar neu: GitHub - lucasg/Dependencies: A rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.

Das verlinkte, installationsfreie Tool hat mir gezeigt was fehlt.
Im konkreten Fall ist es eine DLL namens ucrtbased.dll.
Sie wird wohl auch "Microsoft C Runtime Library" genannt.
Sie ist Teil des "Windows Software Development Kit" und das ist auch bei "Visual Studio" mit dabei.

Ich melde mich nochmal zum Thema, mit mehr Details, sobald ich mich mit diesem Ergebnis und dessen Auswirkungen auf mein Programm näher befasst habe.
Wie es aussieht sollte ich mich auch mal mit dem Unterschied beim Kompilieren zwischen Debug und Release befassen.
Das hat anscheinend jeweils andere Abhängigkeiten zur Folge.

Gruß und Dank
Frank

Zitat von Pedant

Sie ist Teil des "Windows Software Development Kit" und das ist auch bei "Visual Studio" mit dabei.

Die DLL sollte schon Teil von Windows 10 sein, seit irgendeinem Upgrade (als Teil von Universal CRT).
Windows SDK kommt nur mit VS mit, wenn Du es bei der Installation explizit mit auswählst.

Hallo,

irgendwoher hatte ich eine ITapi3.dll als kompiliertes Binary und nutzte sie bisher.
Die Datei war von 2010.
Der Sourcecode ist noch verfügbar:
GitHub - markjulmar/itapi3: C++/CLI TAPI 3.0 client .NET wrapper

Das alte Binary gab es nur als 32-Bit-Variante.
Der Sourcecode war zwar für Visual Studio 2008, er ließ sich aber irgendwie in VS 2019 öffnen und kompilieren.
So erhielt ich eine 32- und eine 64-Bit-DLL.
Die funktionierten aber nicht überall und gaben dann mit der Eingangs beschriebenen Fehlermeldung aus, dass sie irgendetwas vermissten.

Die Hauptursache für mein Problem war wohl meine Unkenntnis von den Unterschieden zwischen Debug und Release.

Es ist wohl so, dass es von einigen DLL-Dateien spezielle Debug-Varianten gibt, die bei Windows zunächst nicht mit dabei sind.
Diese DLL tragen ein zusätzliches d am Ende des Dateinamens, zumindest trifft es auf diese beiden Dateien, die mein Programm mit der neuen ITapi3.dll benötigt.

VCRUNTIME140D.DLL
ucrtbased.dll

Die "normalen" Dateien sind ohne das d benannt.

VCRUNTIME140.DLL
ucrtbase.dll

Zitat von Abt

Die DLL sollte schon Teil von Windows 10 sein, seit irgendeinem Upgrade (als Teil von Universal CRT).

Danke, das trifft dann aber auf die Datei ohne das d zu.

Ich hatte mein Programm und die ITapi3.dll mit der Einstellung "Debug" statt "Release" kompiliert.
Das führte dazu, dass als Änhängigkeiten, die DLL mit d gesucht und genutzt wurden.
Auf meinen Entwicklungsrechnern waren diese *d.dll vorhanden, auf normalen Windows10-Rechnern aber nicht.
Auf den normalen Windows10-Rechnern startete mein Programm daher nicht.

Ich habe jetzt alles auf "Release" kompliert und weiß jetzt auch, dass ich das so beibehalten sollte.
Es ist schon schlimm, wenn man nicht weiß was man tut.

Ohne gfoidl Tipp Dependencies zu nutzen, hätte ich das Problem wahrscheinlich nie beheben können.

Nochmal vielen Dank Euch beiden
Gruß Frank

Hallo Pedant,

auch dir ein Danke für die ausführliche Rückmeldung und weiteren Infos.
So soll ein Forenbetrieb funktionieren :-)

Zitat

Auf meinen Entwicklungsrechnern waren diese *d.dll vorhanden, auf normalen Windows10-Rechnern aber nicht. Auf den normalen Windows10-Rechnern startete mein Programm daher nicht.

Daher als Tipp:

• probier die Anwendung "immer" auf einem frisch aufgesetzten Rechner aus -- am einfachsten mit einer virtuellen Maschine
• verwende CI (continuous integration) mit anschließenden automatischen Tests (im Idealfall mit automatischen Deploy --> CI/CD)

So kann das Problem "läuft auf meinem Rechner, woanders nicht" eliminiert bzw. eingedämmt werden.

mfG Gü

Hallo gfoidl,

Zitat von gfoidl

So soll ein Forenbetrieb funktionieren

Jetzt wollte ich besonders artig sein und meinen Thread als [gelöst] markieren, so wie es hier angeregt wird:
myCSharp.de - Wie poste ich richtig?

Zitat

ihr könnt anderen myCSharp-Benutzern das Leben und die Forumssuche erleichtern, wenn ihr eure Threads durch ein vorangestelltes [erledigt] im Titel als erledigt kennzeichnet, sobald das der Fall ist. Dazu einfach im ersten Beitrag des Threads auf 'Beitrag editieren' klicken, bei 'Thema:' das [erledigt] eintragen und den 'Beitrag speichern'. Statt [erledigt] könnt ihr natürlich auch [gelöst] verwenden, wenn das die Sache besser trifft, also insbesondere, wenn eine funktionierende und für andere nachvollziehbare Lösung des Problems auch wirklich explizit im Thread angegeben wurde.

Es scheitert aber daran, dass ich den ersten Beitrag im Thread nicht oder nicht mehr bearbeiten kann.

Falls ein Moderator das lesen und Langeweile haben sollte, kann er gerne dem Threadtitel ein [gelöst] voranstellen.

Gruß Frank

Habs hinzugefügt und den Hinweis mal rausgenommen, bis wir den neuen Gelöst-Button haben.