Incapable de charger DLL (Le module est introuvable. HRESULT: 0x8007007E)
J'ai une bibliothèque DLL avec le code API C++ non géré que je dois utiliser dans mon application .NET 4.0. Mais chaque méthode que j'essaie de charger ma dll, je reçois une erreur:
Impossible de charger DLL 'MyOwn.dll': le module spécifié est introuvable. (Exception de HRESULT: 0x8007007E)
J'ai lu et essayé plusieurs solutions que j'ai trouvées sur Internet. Rien ne fonctionne..
J'ai essayé d'utiliser les méthodes suivantes:
[DllImport("MyOwn.dll", CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs((UnmanagedType.I4))]
public static extern Int32 MyProIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
Quand j'ai essayé de suivre cet article et quand je lance cet exemple (à partir du code téléchargé), il s'exécute sans problème (la dll utilisée se trouve dans le dossier bin/debug)
J'ai copié ma dll (avec tous les fichiers, cela dépend dans mon dossier bin).
J'ai aussi essayé cette approche mais j'ai eu la même erreur:
[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
[return: MarshalAs(UnmanagedType.I4)]
public static extern int MyproIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
Aucune suggestion?
D'après ce que je me souviens de Windows, l'ordre de recherche d'une DLL est le suivant:
- Répertoire actuel
- Dossier système,
C:\windows\system32 or c:\windows\SysWOW64(pour les processus 32 bits sur une boîte 64 bits). - Lecture de la variable d'environnement
Path
En outre, je vérifierais les dépendances de la DLL. Le gestionnaire de dépendances fourni avec Visual Studio peut vous aider. Il peut également être téléchargé gratuitement: http://www.dependencywalker.com
Vous pouvez utiliser l'outil dumpbin pour rechercher les dépendances requises DLL:
dumpbin /DEPENDENTS my.dll
Cela vous indiquera les DLL que votre DLL doit charger. Faites particulièrement attention à MSVCR * .dll. J'ai vu votre code d'erreur se produire lorsque le correct Visual C++ Redistributable n'est pas installé.
Vous pouvez obtenir les "Packages redistribuables Visual C++ pour Visual Studio 2013" sur le site Web de Microsoft. Il installe c:\windows\system32\MSVCR120.dll
Dans le nom du fichier, 120 = 12.0 = Visual Studio 2013.
Veillez à disposer de la bonne architecture (x64 ou x86) de la version de Visual Studio (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013 ...) adaptée à la plate-forme cible de votre DLL. débogage construit. La version de débogage d'une DLL dépend de MSVCR120d.dll, qui est une version de débogage de la bibliothèque, installée avec Visual Studio mais pas par le package redistribuable.
La DLL doit être dans le dossier bin.
Dans Visual Studio, j'ajoute la dll à mon projet (PAS dans les références, mais "Ajouter un fichier existant"). Définissez ensuite la propriété "Copier dans le répertoire de sortie" pour la dll sur "Copier si plus récent".
Essayez d'entrer le chemin complet de la DLL . Si cela ne fonctionne pas, essayez de copier la DLL dans le dossier system32.
Assurez-vous que toutes les dépendances de votre propre dll sont présentes près de la dll ou dans System32.
Ceci est un 'kludge' mais vous pouvez au moins l'utiliser pour tester honnêtement: Essayez de coder en dur le chemin d'accès à la DLL dans votre code
[DllImport(@"C:\\mycompany\\MyDLL.dll")]
Ayant dit cela; dans mon cas, exécuter dumpbin /DEPENDENTS comme suggéré par @ anthony-hayward et copier les versions 32-bit des DLL répertoriées dans mon répertoire de travail ont résolu ce problème.
Le message est juste un peu trompeur, car ce n'est pas "ma" dll qui ne peut pas être chargée - ce sont les dépendances
Il y a une chose très amusante (et qui a une pertinence technique) qui pourrait vous faire perdre des heures, alors pensez à la partager ici -
J'ai créé un projet d'application console ConsoleApplication1 et un projet de bibliothèque de classes ClassLibrary1.
Tout le code qui faisait le p/invoke était présent dans ClassLibrary1.dll. Ainsi, avant de déboguer l'application depuis visual studio, j'ai simplement copié l'assembly non géré C++ (myUnmanagedFunctions.dll) dans le répertoire \bin\debug\ du projet ClassLibrary1 afin qu'il puisse être chargé à l'exécution par le CLR.
Je continuais à obtenir le
Impossible de charger la DLL
erreur pendant des heures. Plus tard, j'ai réalisé que tous ces assemblages non gérés à charger devaient être copiés dans le répertoire \bin\debug du projet de démarrage ConsoleApplication1, qui est généralement un formulaire gagnant, une console ou une application Web.
Alors, soyez prudent, le Current Directory dans la réponse acceptée signifie en fait Current Directory du fichier exécutable principal à partir duquel le processus de candidature commence. Cela semble une chose évidente, mais peut-être pas parfois.
Leçon apprise - Placez toujours les dll unamanaged dans le même répertoire que l'exécutable de démarrage afin de vous en assurer.
Allumez la journalisation de fusion, voir cette question pour de nombreux conseils sur la façon de procéder. Le débogage des problèmes de chargement des applications en mode mixte peut être une douleur royale. La journalisation par fusion peut être d'une grande aide.
J'ai eu le même problème lorsque j'ai déployé mon application pour tester un PC. Le problème était que le PC de développement avait msvcp110d.dll et msvcr110d.dll mais pas le PC de test.
J'ai ajouté le module de fusion "Visual Studio C++ 11.0 DebugCRT (x86)" dans InstalledSheild et cela a fonctionné. J'espère que cela sera utile pour quelqu'un d'autre.
Si les projets DLL et .NET se trouvent dans la même solution et que vous souhaitez les compiler et les exécuter à chaque fois, vous pouvez cliquer avec le bouton droit de la souris sur les propriétés du projet .NET, Construire des événements, puis ajouter le code suivant Ligne de commande de l’événement post-build:
copy $(SolutionDir)Debug\MyOwn.dll .
Il s’agit essentiellement d’une ligne DOS, et vous pouvez modifier l’ordre en fonction de la construction de votre DLL.
Assurez-vous de définir la cible de plate-forme de construction sur x86 ou x64 afin qu'elle soit compatible avec votre DLL - qui peut être compilée pour une plate-forme 32 bits.
Setup: Windows 7 32 bits
Contexte: un pilote PCI-GPIB a été installé et j’ai été incapable de communiquer en raison du problème susmentionné.
Réponse courte: réinstallez le pilote.
Réponse longue: J'ai aussi utilisé Dependency Walker , qui a identifié plusieurs modules de dépendance manquants. Immédiatement, j'ai pensé qu'il devait s'agir d'une installation de pilote bâclée. Je ne voulais pas vérifier et restaurer chaque fichier manquant.
Le fait que je n'ai pas pu trouver le programme de désinstallation sous Programmes et fonctionnalités du Panneau de configuration est un autre indicateur d'une mauvaise installation. J'ai dû supprimer manuellement quelques fichiers * .dll dans\system32 et des clés de registre pour permettre la réinstallation du pilote.
Problème résolu.
La partie inattendue était que tous les modules de dépendance n'étaient pas résolus. Néanmoins, le * .dll d'intérêt peut maintenant être référencé.
J'ai rencontré le même problème, dans mon cas j'avais deux PC 32 bits. Un avec .NET4.5 installé et un autre était un nouveau PC.
ma dll cpp 32 bits (version en mode édition) fonctionnait correctement avec le PC installé .NET mais pas avec le nouveau PC où j'ai eu l'erreur ci-dessous
Impossible de charger DLL 'PrinterSettings.dll': le module spécifié ne peut pas être a trouvé. (Exception de HRESULT: 0x8007007E)
enfin,
Je viens de construire mon projet dans Mode débogage configuration et cette fois, mon cpp dll fonctionnait bien.
Dans mon cas, une dll non gérée dépendait d'une autre qui manquait. Dans ce cas, l'erreur pointera sur la DLL existante au lieu de celle manquante, ce qui peut être très déroutant.
C'est exactement ce qui s'était passé dans mon cas. J'espère que ceci aide quelqu'un d'autre.
Je pense que votre bibliothèque non gérée a besoin d'un manifeste.
Voici comment l’ajouter à votre binaire. et ici est pourquoi.
En résumé, plusieurs versions de librairies redistribuables peuvent être installées dans votre boîte mais une seule d'entre elles devrait satisfaire votre appli. Ce n'est peut-être pas la valeur par défaut. Vous devez donc indiquer au système la version dont votre librairie a besoin, c'est pourquoi le manifeste.
Nous avons également rencontré le même problème lors de l’utilisation du fichier dll non géré c/c ++ dans un environnement c #.
1.Vérifié la compatibilité des DLL avec les processeurs 32 bits ou 64 bits.
2.Vérifiez les chemins corrects du dossier DLL .bin, system32/sysWOW64 ou du chemin indiqué.
3.Vérifié s'il manque des fichiers PDB (Program Database). Ce vidéo vous donne le meilleur comprendre les fichiers pdb.
Lorsque vous exécutez du code binaire C/C++ 32 bits dans un système 64 bits, cela peut être dû à une incompatibilité de plate-forme. Vous pouvez le changer depuis Build> Configuration Manager.