C# C++/CLI C DLL Système.IO.FileNotFoundException
Je suis System.IO.FileNotFoundException: The specified module could not be found lors de l'exécution de code C# qui appelle un C++/CLI assemblée qui appelle à son tour une pure C DLL. Il se produit dès qu'un objet est instancié qui appelle la pure C fonctions de la DLL.
BackingStore est de la pure C.
CPPDemoViewModel est le C++/CLI appel BackingStore il a une référence à BackingStore.
J'ai essayé le plus simple possible cas - ajouter un nouveau C# test de l'unité projet qui tente de créer un objet défini dans CPPDemoViewModel . J'ai ajouté une référence du projet C# pour CPPDemoViewModel .
C++/CLI projet de test fonctionne très bien avec juste l'ajout ref à CPPDemoViewModel c'est donc quelque chose au sujet de passer entre les langues.
Je suis à l'aide de Visual Studio 2008 SP1 .Net 3.5 SP1. Je suis en train de construire sur Vista x64, mais ont pris soin de m'assurer que ma Plate-forme cible est définie sur x86.
Cela se sent comme quelque chose de stupide, et je suis évidemment absent, mais il serait encore plus stupide de me faire perdre du temps à essayer de le résoudre en privé donc je suis ici à être ridicule!
Ceci est un test pour un projet de portage d'une énorme quantité de l'héritage de code C qui je vais garder dans une DLL avec un ViewModel implémenté en C++/CLI.
modifier
Après vérification des répertoires, je peux confirmer que le BackingStore.dll n'a pas été copié.
J'ai le standard unique des dossiers de projet créé avec un typique multi-projet de solution.
WPFViewModelInCPP BackingStore CPPViewModel CPPViewModelTestInCS bin Debug Debug
Au plus haut niveau de Debug semble être un bon dossier utilisé par le C et le C++/CLI projets, à ma grande surprise.
WPFViewModelInCPP\Debug contient BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll et de leurs associés .ilk et .fichiers pdb
WPFViewModelInCPP\CPPViewModelTestInCS\bin\Debug contient CPPDemoViewModel et CPPViewModelTestInCS .dll et .fichiers pdb mais pas BackingStore. Toutefois, la copie manuelle BackingStore dans ce répertoire n'a pas corrigé l'erreur.
CPPDemoViewModel a la propriété Copie Locale ensemble ce qui je suppose est responsable de copier DLL lorsque s'est référencé. Je ne peux pas ajouter une référence à partir d'un projet C# pour un pur DLL C - il dit seulement Une Référence à la mémoire de Sauvegarde n'a pas pu être ajouté.
Je ne suis pas sûr si j'ai juste un problème ou deux.
Je peux utiliser une ancienne copie étape de génération de copier le BackingStore.dll en tout C# répertoires du projet, bien que je l'avais espéré que le nouveau .net modèle n'a pas exigé que.
DependencyWalker me dit que le fichier est manquant GPSVC.dll qui a été suggéré indique le paramètre de sécurité de questions. Je suppose que c'est un leurre.
edit2
Avec une copie manuelle de BackingStore.dll à côté de l'exécutable, l'interface graphique fonctionne maintenant très bien. Le C# du Projet de Test a encore des problèmes qui je pense est en raison de l'environnement d'exécution d'un projet de test, mais je peux vivre sans, pour l'instant.
OriginalL'auteur Andy Dent | 2009-03-15
Vous devez vous connecter pour publier un commentaire.
Sont le C et le C++ Dll dans le même répertoire que le C# assemblée de l'exécution?
Vous pouvez avoir à modifier votre projet, les paramètres de sortie de sorte que le C# de l'assemblée et les autres Dll tous dans le même dossier.
J'ai souvent utilisé le Dependency Walker dans des cas comme ça, c'est un test de cohérence qui montre que toutes les dépendances peuvent effectivement être trouvé.
Une fois que votre application est en cours d'exécution, vous pouvez également essayer de sortir Le Moniteur De Processus sur le code en cours d'exécution, pour voir quelles Dll sont référencés, et où ils sont situés.
Je n'avais pas pensé à utiliser la bonne vieille depends.exe sur .Net des trucs (je suis un vieux de la vieille école Win32/MFC et autres C++ guy). Bon point. Il a confirmé la DLL manquante.
Eh bien, c'est bon ;] Depends.exe ftw!
+1 encore une fois, a juste allons proposer Dependency Walker.
OriginalL'auteur Daniel LeCheminant
La réponse de l'interface utilisateur, autre que de changer les paramètres de sortie, a été l'ajout d'une Pré-Étape de génération
La réponse, pour les projets de Test était d'ajouter les DLL manquantes de l'onglet Déploiement de la testrunconfig. Vous pouvez le faire en modifiant directement la valeur par défaut LocalTestRun.testrunconfig (apparaît dans la Solution en vertu de la Solution Éléments) ou cliquez-droit sur la Solution et Ajouter un nouveau test de config, qui s'affiche sous le menu Test.
Merci pour les réponses sur cette SORTE de question sur des configurations de test pour me mener à la réponse.
Andy, vous devriez toujours vérifier les points que j'ai soulevés, j'ai eu le sentiment que votre chance avec l'ordre d'initialisation du moment, et peuvent devenir des nations unies-la chance dans l'avenir, w/o une prise ferme sur ce point.
OriginalL'auteur Andy Dent
La raison pour laquelle cela se produit est parce que vous êtes chargement DLLMAIN de code managé, devant la CRT a l'occasion d'être initialisé. Vous ne pouvez pas avoir tout le code managé, être exécuté DIRECTEMENT ou INDERECTLY à partir d'un effet de DllMain notifications. (Voir: Expert C++/CLI: .Net pour Visual C++ Programmeurs, chapitre 11++).
Ou vous n'avez pas natif point d'entrée défini wahtsoever, mais vous avez lié à MSVCRT. Le CLR est initialisée automatiquement pour vous /clr, ce détail provoque beaucoup de confusion et doit être pris en compte. Un mode mixte DLL en fait retard charges le CLR grâce à l'utilisation de hot-appliquer des correctifs sur tous les point d'entrée géré vtables dans vos classes.
Un certain nombre de classe de l'initialisation de questions entourent ce sujet, verrou du chargeur et de retarder le chargement de CLR sont un peu trickey parfois. Essayer de déclarer mondiale est statique et ne pas utiliser de #pragma sites gérés et non gérés, isoler votre code avec /clr de fichier par fichier.
Si vous ne pouvez pas isoler de votre code dans le code managé, et de la difficulté, (après la prise de certains de ces étapes), vous pouvez également regarder vers l'hébergement de la CLR vous-même et passe peut-être par la création d'un gestionnaire de domaine, qui permettrait d'assurer pleinement "dans la boucle" des événements de l'exécution et de l'amorce.
C'est exactally pourquoi, il a nothting todo avec votre chemin de recherche, ou de l'initialisation. Malheureusement, la Fusion de la visionneuse du journal ne sert pas beaucoup (ce qui est habituellement un lieu .NET CLR assemblée de liaison des questions non dependency walker).
Lier statiquement n'a rien todo avec ce soit. Vous pouvez PAS lien statique en C++/CLI demande qui est le mode mixte.
Bonne chance, vérifiez aussi que le livre c'est du très bon.
Point 2 sur les pas de réglage /CLR m'a aidé. Merci.
OriginalL'auteur RandomNickName42
C'est un dilemme intéressant. Je n'ai jamais entendu parler d'un problème de chargement de la maternelle .Dll à partir de C++/CLI, après un appel à partir de C# avant. Je ne peux que supposer le problème est que @Daniel L suggéré, et que votre .DLL n'est tout simplement pas dans un chemin à l'assemblée chargeur peut trouver.
Si Daniel suggestion ne fonctionne pas, je vous suggère d'essayer la liaison statique de l'natif de code C pour le C++/CLI programme, si vous le pouvez. Ce serait certainement résoudre le problème, comme l' .DLL serait alors entièrement absorbé dans le C++/CLI .DLL.
Ah, bien. Bonne chose que Daniel était à droite, puis, hein?
OriginalL'auteur Randolpho
Assurez-vous que le système cible a le bon MS Visual C runtime, et que vous n'êtes pas accidentellement la construction de la dll C avec une version de débogage de l'exécution.
Est-ce dire que le natif de DLL C++ ne devrait pas être construit avec la cible de Débogage? Exactement ce qui suis-je pour être sûr? J'ai une situation très semblable (C# appel de C++/CLI d'appel de DLL C++ natif DLL pour intégrer du code legacy) & j'aimerais éviter de tout ce piège est identifié ici.
IIRC, la dépendance est sur msvcrtd.dll. Depends.exe devrait confirmer.
OriginalL'auteur leppie
Eu le même problème de commutation pour Vista 64 bits. Notre application a été d'appeler Win32 Dll qui est source de confusion la cible de construire pour l'application. Pour le résoudre, nous avons fait la suivante:
Quand je re-couru à l'application, il a travaillé.
OriginalL'auteur