J'ai beaucoup de difficulté à obtenir un scénario de base pour travailler sur Windows Mobile 5.0 Emulator. J'ai une application WinForms qui appelle éventuellement un code natif. Le déploiement fonctionne bien et toutes les DLL natives sont copiées dans le même dossier que les Winforms .exe. J'ai également vérifié que c'est le cas avec l'outil de visualiseur de fichiers distant.
Cependant, lorsque je lance mon application, il échoue toujours avec "Impossible de trouver Pinvoke DLL - System.MissingMethodException" (lorsque le moment est venu d'appeler dans un code natif, l'attribut Dllimport est rendu inutile). Je savez que la DLL natif se trouve dans le même dossier que l'exécutable. Que dois-je faire de plus?
J'utilise vs 2008.
4 Réponses :
Compte tenu du message d'erreur, il existe généralement l'un des 2 problèmes
__ DeclSpec (dllexport)
En outre, la vérification de la santé mentale est de vous assurer que le nom de la DLL est orthographié correctement et manquant du suffixe .dll.
Salut Jared Merci pour la réponse. 1) Je suis mort certaine que la DLL natif se trouve dans le même répertoire que l'application d'exécution. En fait, il y a 2 DLL natives. J'ai commenté les appels étant faits en un et l'autre lance le chèque même EXCEPTION 2) - j'ai le même codeBase compilé pour la plate-forme Win32 et cela fonctionne aussi bien que le nom de la DLL est orthographié. Correctement et il fait le suffixe .dll (n'est-ce pas ce que vous vouliez dire?)
Savez-vous également d'arriver à savoir pourquoi je ne peux pas la configurer correctement: blogs.msdn.com/netcfletam/archive/2005/07/24/442609. ASPX J'ai utilisé l'Éditeur de registre distant pour mettre dans toutes les touches REQD et que le fichier journal n'est toujours pas créé. Aujourd'hui doit être tout-mudane-choses-goûter jour!
FYI, cela fonctionnera bien avec ou sans le suffixe "DLL", bien que vous devriez être cohérent dans la chaîne exacte que vous passez (j'utilise un const): DanielMoth.com/blog/2007/12/be-consistance-with-dllimports.ht ml
Tous les conseils sont donc de savoir ce que j'ai utilisé pour résoudre ceux-ci dans le passé. J'ai deux choses à essayer cependant. 1. Pour activer la journalisation .NETCF, essayez de définir une valeur DWORD sous la dernière touche et la valeur de la clé également. J'oublie quelle combinaison a fonctionné pour moi, mais je me suis rappelé, il me confondais, par exemple [hklm \ logiciel \ microsoft \ .netcompactframework \ diagnostics \ lo ging] "activé" = 1. 2. Essayez d'utiliser une version compilée de votre libération de votre dlls natifs. Nous avons eu quelques dlls qui ont refusé de p / invoquer leurs constructions de débogage. Jamais résolu, probablement un commutateur de construction.
Pour étendre la réponse de Jared, quatre raisons supplémentaires d'obtenir une méthodexception manquante, tandis que p / invoquant dans les CF:
Avez-vous vérifié que les points d'entrée DLL sont non décorés avec quelque chose comme Dumbin ?
De plus, si vous attendez que la DLL natif soit dans le même répertoire que l'exe appelant, assurez-vous que l'EXE est réellement déployé dans le même répertoire.
La DLL Ce que vous utilisez n'a pas de définition pour la méthode de ce que vous appelez. Donc, l'exception se produit .. Il compile bien .. Seulement le problème du temps d'exécution se produit .. La solution est que vous devez vous assurer que la définition est présente dans la DLL ou non, sinon vous devez utiliser une autre DLL.
la méthode ne peut pas être exposée à l'exportation
Votre problème est dû au fait que la gestion de la mémoire WM5 est la merde. Les DLL sont chargées du haut de la fente en bas pendant que des applications sont chargées de bas en haut. Si vous n'avez pas assez d'espace entre votre application et votre DLL, vous recevrez une erreur «Impossible de Pinvoke».
WM5 alloue 32 emplacements de 32 Mo pour les applications.
Chaque fois que WM5 alloue la mémoire de la DLL, il utilise un minimum de bloc de 64 Ko, donc si votre DLL est de 32k, il faudra 64k, si votre DLL prend 68k, WM5 allouera 2x64kb - 128kb.
Lorsque Wm5 charge la DLL requise, il sera toujours chargé à l'adresse inférieure de l'application Previsouly chargé, c'est-à-dire si l'application 1 a chargé 2 × 30kb dlls, la première sera chargée à l'adresse 0 à 64k, la seconde de 64 à 128, alors votre application chargera ses DLL de 128 Ko, pas 0, même si vos applications s'inscrivent dans une fente séparée.
Pour que les choses fonctionnent, vous devrez charger votre application plus tôt ou supprimer des applications non nécessaires depuis le dossier Starup Windows.
Vrai, mais pas vrai. Vrai pour les DLL natifs, mais pas vrai pour cette question. Cette question est marquée "Compact-Framework" et des DLL gérées ne sont pas chargées dans ce modèle de mémoire. Ils sont chargés de fichiers mappés de mémoire et ne prennent pas le bloc de mémoire virtuel 64K. MSDN a une très bonne diffusion Web sur la manière dont le cadre compact utilise la mémoire que vous pourriez intéresser.
2 Commentaires rapides: 1) La première fois que je n'avais aucune des DLL natives dans le dossier de l'EXE. Donc, cette exception a au moins un sens alors. Maintenant que cela s'est assuré que tout est déployé, comment puis-je rencontrer à nouveau dans la même ? 2) J'ai essayé de configurer la journalisation comme décrit dans cet article: Blogs .msdn.com / NetCfletam / Archive / 2005/07/24 / 442609.aspx J'ai utilisé dans l'éditeur de registre distant pour le faire, mais sans être en vain. Aucun fichier de journalisation n'est créé du tout! Comment tant de choses de base peuvent-elles mal tourner?