2009-08-07 7 views
25

Donc j'utilise un SDK pour un générateur de nombres aléatoires matériel qui fournit un dll appelé PsyREG.dll pour interagir avec lui, ainsi que certains C# source pour utiliser les méthodes de la DLL.DllNotFoundException, mais DLL est là

Cela a fonctionné dans le passé, mais de toute façon il a cessé de fonctionner. Mes mains sont un peu liées car je n'ai pas accès à l'appareil en question pour le moment, donc je ne peux pas essayer beaucoup de choses ...

Cependant, voici la chose étrange. La DLL est là, le même endroit que ça a toujours été. Ahd en fait, File.Exists ("PsyREG.dll") renvoie true, et j'ai vérifié deux fois et c'est exactement la même manière que la source C# fournie l'importe, par ex. [DllImport ("PsyREG.dll")].

Des idées?

Répondre

34

Il est probable que cette DLL a quelques dépendances qu'ils ne sont pas enregistrés ou ne sont pas dans le même dossier de votre application.

+0

Merci, c'était. Il y avait d'autres choses qui étaient nécessaires, mais pour quelques raisons, je ne pensais pas à vérifier cela (y compris le fait qu'il a dit qu'il ne pouvait pas charger PsyREG.dll, pas un fichier différent) – Asmor

+1

Des moments comme ça sont quand je éclater Réflecteur. Il peut vous montrer les dépendances. En particulier, il peut vous montrer ceux qui ne sont pas trouvés. –

+0

Vraiment? Reflector trouve-t-il des dépendances non gérées? Où est cette option? – erikkallen

1

Vous devriez peut-être vérifier si vous attendez une version de produit spécifique de la DLL, et assurez-vous que les versions du produit correspondent toujours correctement.

4

Ouvrir DLL sur le système problématique dans http://www.dependencywalker.com/

+0

Cette application a fait le travail pour moi. –

+0

cool ... cet outil m'a aidé à résoudre beaucoup de problèmes d'installation lors du déploiement. – cbuteau

0

je traitais la même exception en ce qui concerne l'un de mes DLL (appelons-le A). C# plantait parce qu'il prétendait qu'il ne pouvait pas trouver cette DLL (A) (alors qu'il était là dans le même dossier que l'exécutable).

Il s'est avéré que le problème a été causé par A ayant une dépendance sur une autre DLL (appelez-le B). B n'était pas dans le chemin, donc A ne pouvait pas le charger quand il le fallait. Puisque B avait besoin de tout un tas d'autres DLL, la solution consistait à ajouter le répertoire B à la variable d'environnement PATH.

Il est intéressant de voir comment les accidents C# avec l'erreur en disant que A ne se trouve pas, alors qu'en fait B n'a pas été trouvé ...

+0

Pouvez-vous expliquer «la solution consistait à ajouter un peu le répertoire de B à la variable d'environnement path»? Je suis actuellement aux prises avec presque le même problème, seule la différence est que ma DLL veut des fichiers * .so au lieu d'autres DLL. – Stefan

+0

@Stefan Je crois au terminal Linux que vous feriez 'exporter PATH = $ PATH: VOTRE-SO-FILE-PATH' pour ajouter le répertoire' YOUR-SO-FILE-PATH' à votre variable d'environnement PATH. De cette façon, lorsque votre fichier 'so 'doit être chargé, le chemin spécifié par PATH sera recherché pour trouver ce fichier' so'. – M2X

+0

Merci, j'ai essayé comme ça mais ça n'a pas vraiment marché. J'ai lu quelque part ailleurs pour déplacer ma DLL dans le répertoire '/ usr/lib' (oui, c'est en effet un système Linux) et cela a fonctionné sans autre configuration – Stefan

0

je suis tombé sur ce problème et résolu ce qui suit:

Il y a une dépendance sur msvcr90.dll si vous compilez sous/MD. Essayez plutôt de compiler le code avec/MT.

Project properties>C/C++>Code Generation>Runtime Library: /MT

Questions connexes