[Débutant]Encore un problème de DLL

Version imprimable

Bonjour à tous,

Ca fait maintenant plus d'une semaine que je me casse les dents sur un problème d'importation de DLL. La DLL en question est fournie par une société tierce avec toute la documentation nécessaire pour l'utiliser.

Maintenant, je commence juste à développer avec Visual C++ 2005 Express et je me replonge après plusieurs années de VB dans le langage C++ et j'avoue que j'ai un peu de mal. Mais grâce à developpez.com et ses sources d'informations on s'en sort.

Jusque là ça va ...

Après plusieurs tentatives infructueuses d'importation de la DLL dans une application "Windows Forms", j'ai fait des essais avec un projet "Console Win32" et la DLL fonctionne correctement. Mais uniquement avec l'option "sans prise en charge du CLR". Dès que je sélectionne l'option "avec prise en charge du CLR (/clr)" dans les propriétés du projet et en gardant le même code. La DLL n'est plus accessible et lors de l'execution j'ai des violatons d'accès mémoire.

Et moi je voudrais bien l'importer dans une application "Windows Forms" ! Donc forcément avec l'option "avec prise en charge du CLR (/clr)". Et que ce soit en dynamique ou en statique, rien à faire, à l'execution je n'arrive pas à charger la DLL.

Voici un exemple de code d'importation que j'ai essayé dans le projet "Windows Forms" :
Code:

1 2 3 4 [DllImport("D:\\usr\\fox\\system32\\iccapi.dll", EntryPoint = "ICCopen")] __declspec(dllimport) int ICCopen(char *, int, char *); [DllImport("D:\\usr\\fox\\system32\\iccapi.dll", EntryPoint = "ICCclose")] __declspec(dllimport) int ICCclose();
Et pour l'appel des fonctions :
Code:

1 2 ICCopen("FLY010",5,"01234567890123456789"); ICCclose();
A la compilation tout ce passe bien. Mais à l'execution, lors de l'appel des fonctions, voici ce que j'obtiens dans le fichier de sortie :

Citation:

'ESSAI_ICCAPI.exe'*: Chargé 'D:\usr\fox\system32\iccapi.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'ESSAI_ICCAPI.exe'*: Chargé 'D:\usr\fox\system32\csaretrv.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'ESSAI_ICCAPI.exe'*: Chargé 'D:\usr\fox\system32\largem.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'ESSAI_ICCAPI.exe'*: Chargé 'D:\usr\fox\system32\xhi.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'ESSAI_ICCAPI.exe'*: Chargé 'D:\usr\fox\system32\fox.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'ESSAI_ICCAPI.exe'*: Chargé 'D:\usr\fox\system32\foxfdr.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
LDR: LdrRelocateImageWithBias() failed 0xc0000018
LDR: OldBase : 00A00000
LDR: NewBase : 03BE0000
LDR: Diff : 0x7c91dec20012c8bc
LDR: NextOffset : 00000000
LDR: *NextOffset : 0x0
LDR: SizeOfBlock : 0x3be0000
'ESSAI_ICCAPI.exe'*: Déchargé 'D:\usr\fox\system32\iccapi.dll'
'ESSAI_ICCAPI.exe'*: Déchargé 'D:\usr\fox\system32\csaretrv.dll'
'ESSAI_ICCAPI.exe'*: Déchargé 'D:\usr\fox\system32\largem.dll'
'ESSAI_ICCAPI.exe'*: Déchargé 'D:\usr\fox\system32\xhi.dll'
'ESSAI_ICCAPI.exe'*: Déchargé 'D:\usr\fox\system32\fox.dll'
'ESSAI_ICCAPI.exe'*: Déchargé 'D:\usr\fox\system32\foxfdr.dll'
Une exception non gérée du type 'System.DllNotFoundException' s'est produite dans ESSAI_ICCAPI.exe

Informations supplémentaires*: Impossible de charger la DLL 'D:\usr\fox\system32\iccapi.dll': Tentative d'accès à une adresse non valide. (Exception de HRESULT : 0x800701E7)

Et là ça ne va plus du tout !
Malgré toutes mes recherches je ne trouve pas d'où vient le problème.

J'ai donc plusieurs questions :

1) Pourquoi dans mon projet "Console Win32" le résultat de la compilation est différent entre les deux options de compilation "sans prise en charge du CLR" et "avec prise en charge du CLR (/clr)" alors que cette dernière est censée prendre en charge les deux types de code, managé et non managé ?

2) A quoi correspondent "LDR" et la fonction "LdrRelocateImageWithBias()" qui me posent apparemment problème ?

3) Est-ce qu'une âme fort charitable ou un "gourou du CLR" pourrait me venir en aide et m'indiquer des pistes à suivre pour arriver à importer cette DLL dans une application "Windows Forms" ?

Merci à tous ceux qui ont prit le temps de me lire, et merci d'avance à ceux qui pouront m'apporter de l'aide !

08/11/2006, 09h10
nico-pyright(c)

pourquoi utiliser dllimport ? tu n'as pas le .lib associé ?
08/11/2006, 16h42
patanoc
J'ai bien le .lib associé.

Quand je l'utilise sans prise en charge du CLR dans mon projet "Console Win32" tout se passe bien et la DLL fonctionne.

Mais quand je l'utilise avec prise en charge du CLR (/clr), au lancement de l'application j'ai un message d'erreur "Access Violation" et l'application se termine sur cette erreure.

Voici le code que j'utilise dans les deux cas :
Code:

1 2 3 4 extern "C" int ICCopen(char *cp_name, int security, char *user_id); extern "C" int ICCclose(void); #pragma comment (lib, "iccapi")
Et voici ce que me donne le fichier de sortie avec prise en charge du CLR :

Citation:

'essai.exe'*: Chargé 'D:\usr\fox\system32\iccapi.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\csaretrv.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\largem.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\xhi.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\fox.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\foxfdr.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\nutc.dll', Impossible de trouver ou d'ouvrir un fichier DBG requis.
'essai.exe'*: Chargé 'D:\usr\fox\system32\socket.dll', Impossible de trouver ou d'ouvrir un fichier DBG requis.
'essai.exe'*: Chargé 'D:\usr\fox\system32\X11.dll', Impossible de trouver ou d'ouvrir un fichier DBG requis.
'essai.exe'*: Chargé 'D:\usr\fox\system32\csabuild.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\ccsvr.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\spif.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.
'essai.exe'*: Chargé 'D:\usr\fox\system32\sprt.dll', Le fichier binaire n'a pas été généré avec les informations de débogage.

Exception de première chance à 0x00a20b87 dans essai.exe*: 0xC0000005: Violation d'accès lors de l'écriture à l'emplacement 0x77e78b61.
Exception de première chance à 0x77fa7412 dans essai.exe*: 0xC0000005: Access violation.
Exception non gérée à 0x77fa7412 dans essai.exe*: 0xC0000005: Access violation.

Exception de première chance à 0x77f5171c dans essai.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x00000010.
HEAP[essai.exe]: Invalid Address specified to RtlFreeHeap( 007F0000, 7A2AE474 )
Le thread 'Thread Win32' (0xfd0) s'est arrêté avec le code 0 (0x0).
Le programme '[3504] essai.exe: Natif' s'est arrêté avec le code 0 (0x0).
Le programme '[3504] essai.exe: Managé' s'est arrêté avec le code 0 (0x0).

Comme je le demandais dans le précédent message, je ne vois pas pourquoi sans changer un ligne de code, le programme ne marche pas avec l'option "/clr" alors que sans tout se passe bien ???

Si tu as une idée, je suis preneur ...
08/11/2006, 17h02
nico-pyright(c)

on peut voir l'appel à cette fonction ?

Pas de problèmes. Voir ci dessous :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
	int err;	
	char cpname[7];
	char userid[41];
 
	err = 0;
 
	strcpy_s(cpname, "FLY010");
	strcpy_s(userid, "01234567890123456789");
 
	err = ICCopen((char *)cpname, 5, (char *)userid);
	printf("retour ICCopen : %d \n",err);
 
	err = ICCclose();
	printf("retour ICCclose : %d \n",err);

08/11/2006, 22h03
Médinoc

Et ça compile, ça?
Tu as activé les version Template des fonctions de la Secure CRT, c'est ça?
Au fait: Pourquoi castes-tu tes tableaux de caractères en char* ? La conversion est implicite, normalement...
09/11/2006, 16h05
patanoc

Citation:

Et ça compile, ça?

Eh oui ! Ca compile ça ...
La compilation est même la seule chose qui marche dans les deux cas (avec ou sans prise en charge du CLR).
Par contre, à l'execution du programme, ça marche uniquement sans prise en charge du CLR. C'est ce que je n'arrive pas à comprendre.
Pourquoi, il y a quelque chose qui te semble louche ?

Citation:

Tu as activé les version Template des fonctions de la Secure CRT, c'est ça?

Là tu viens de m'enrhumer !!!
Je ne sais même pas ce que sont les fonctions de la Secure CRT. Alors les versions Template ...
Si c'est en rapport à l'utilisation de la fonction "strcpy_s" plutôt que "strcpy", d'après ce que j'ai lu dans l'aide, il me parraissait mieux d'utiliser cette fonction. Mais c'est peut être une erreure ?
Penses tu que mes ennuis peuvent venir de là ?

Citation:

Au fait: Pourquoi castes-tu tes tableaux de caractères en char* ? La conversion est implicite, normalement...

C'était juste un essai. La conversion est normalement implicite mais comme le programme plantait, je me suis dit qu'il y avait peut être quelque chose à ce niveau. Mais non, le caste n'a rien changé.
09/11/2006, 16h13
Médinoc

Tu peux oublier ma question, elle vient du fait que j'aie mal lu l'aide de strcpy_s() et des Secure Template Overloads. Désolé de t'avoir embrouillé pour une bêtise.

Quand aux problèmes de lien avec la bibliothèque, je dirais qu'il y a peut-être tout simplement un problème de répertoire. Vérifie que le .exe est bien au même endroit dans les deux cas...

Si la DLL est à toi, tu peux aussi vérifier son code source, notamment les constructeurs de ses variables globales et sa fonction DllMain() s'il y en a une: Il est possible que le code exécuté au chargement de la DLL provoque une AccessViolation dedans...
Edit: Je viens de relire le premier post...
10/11/2006, 09h18
patanoc

J'ai vérifié que les .exe étaient bien au même endroit et c'est bien le cas.

J'ai tenté aussi de déplacer les .exe dans les répertoires du .lib ou du .dll mais rien n'y fait. Ca marche toujours en compilant sans prise en charge du CLR et ca marche jamais avec prise en charge du (/clr).

Est-ce que quelqu'un pourrais m'expliquer la différence entre ces deux options dans les propriétés du projet ?
Que font de plus ou de moins le compilateur ou l'éditeur de lien ?
10/11/2006, 09h20
nico-pyright(c)

tu as changé l'option /clr pour tout le projet ? ou uniquement pour les fichiers cpp où tu avais besoin d'utiliser le framework.net ?
10/11/2006, 09h25
patanoc

Pour tout le projet !

Je ne sais pas comment faire pour changer l'option que sur un fichier .cpp et je ne savais même pas que c'était possible.

Pourrais-tu me donner la procédure ?
Je pourrais faire un essai ...
10/11/2006, 09h28
nico-pyright(c)

c'est meme recommandé, de le faire uniquement sur les fichiers où tu en as besoin. Le résultat sera tout de meme un exe managé, mais seuls les fichiers necessaire auront été compilés en managé.
Tu désactives l'option sur tout le projet
Puis tu fais un clic droit sur chaque fichier, propriétés et tu actives dans le menu C++ l'option de compilation avec prise en charge du CLR (de tete, j'ai pas le vs sous la main, donc c'est pas forcément 100% ca :D )
10/11/2006, 09h59
patanoc

Merci pour l'info !

Je ne peux pas faire l'essai maintenant mais je te donnerais le résultat ce soir ...
13/11/2006, 10h47
patanoc

Désolé pour la réponse tardive ...

Malgré une multitude de tests dans différentes configurations, j'obtiens toujours le même résultat.

Je crois que je vais abandonner l'utilisation de cette DLL dans une application Windows Forms et essayé autre chose :
Développer une première application Console Win32 qui utilise la DLL, et une seconde application Windows Forms pour l'interface utilisateur.
Par contre je ne sais pas encore comment passer les commandes de l'une à l'autre.
Si vous avez des idées, elles sont les biens venues ...

Merci pour tout !