Lier une DLL crée avec FORTRAN dans VB .NET

Bonjour
A ma disposition une DLL crée en FORTRAN. Je dois développer une application qui fournira des données à la DLL sous VB .NET sous Visual Studio Professional 2013.
Je reçois un message d'erreur quand je veux ajouter la DLL comme reference au module VB.

Code:

---

la reference c:\...\forDLL.dll n'a pas été ajoutée. verifiez qu'il s'agit d'un assembly ou d'un COM valide

---

Après du googling j'ai trouvé quelques idées qui marchaient sur VB 6 mais sans succés.

Je n'ai que la DLL et pas de fichier d'import(.lib) ni fichier de def(.def) et je suis à court d'idées.

Problème supplementaire: c'est ma première confrontation avec VB.

J'apprecierai des indications de votre part.
Merci d'avance et si vous avez besoin d'informations supplementaires je suis disponible

Pour ajouter une DLL, tu peux déjà aller dans "MyProject" de ton projet, puis "Référence" puis "Browse" et aller chercher ton fichier (que tu as copié dans ton dossier de projet au préalable).

Si il l'ajoute, alors normalement tu pourras y faire référence depuis un module ou une classe.

Après je ne sais pas si c'est compatible... Si ça l'est, il faudra aussi bien vérifier la compatibilité des paramètres.

Citation:

---

Envoyé par mactwist69

Pour ajouter une DLL, tu peux déjà aller dans "MyProject" de ton projet, puis "Référence" puis "Browse" et aller chercher ton fichier (que tu as copié dans ton dossier de projet au préalable)..

---

Pas du tout : ça ne marche que pour des assemblies .NET; or, je ne pense pas qu'il utilise ici le FORTRAN.NET (qui existe).

Pour des DLL non .NET exposant des fonctions, il faut les déclarer avec l'attribut DllImport : https://msdn.microsoft.com/fr-fr/lib...=vs.71%29.aspx

Bonjour

Citation:

---

Envoyé par c4ever

A ma disposition une DLL crée en FORTRAN.

---

Quel compilateur Fortran ? Si c'est du Fortran.net (FTN95) , il suffit de référencer comme pour une autre assembly .NET.
http://www.silverfrost.com/17/ftn95/...tegration.aspx

Sinon, importer les fonctions avec l'attribut DllImport.
https://msdn.microsoft.com/fr-fr/lib...=vs.71%29.aspx

Citation:

---

Envoyé par mactwist69

Pour ajouter une DLL, tu peux déjà aller dans "MyProject" de ton projet, puis "Référence" puis "Browse" et aller chercher ton fichier (que tu as copié dans ton dossier de projet au préalable).

Si il l'ajoute, alors normalement tu pourras y faire référence depuis un module ou une classe.

Après je ne sais pas si c'est compatible... Si ça l'est, il faudra aussi bien vérifier la compatibilité des paramètres.

---

Merci mactwist69 de ta reponse:
Je trouve Référence dans mon projet "mon_proj" et non pas dans MyProject.
Et quand TU dis "copier la DLL dans le dossier de projet y a-t-il un emplacement spécifique ou c'est juste dans le dossier projet "mon_proj" dans le meme repertoire où il y a le fichier solution (.sln)?
en suivant cette démarche, je reçois le meme message d'erreur.
Merci de ta patience

C'était juste pour dire de faire une copie de ta DLL dans ton projet, mais non il n'y a pas d'emplacement disponible.

Mais tu ferais mieux de suivre les conseil de François M qui à l'ai de sacoir de quoi il cause...

Citation:

---

Envoyé par François M.

Pas du tout : ça ne marche que pour des assemblies .NET; or, je ne pense pas qu'il utilise ici le FORTRAN.NET (qui existe).

Pour des DLL non .NET exposant des fonctions, il faut les déclarer avec l'attribut DllImport : https://msdn.microsoft.com/fr-fr/lib...=vs.71%29.aspx

---

Merci François, je viens vers toi car effectivement ils n'utilisent pas le FORTRAN.NET.
J'ai découvert dans un forum de FORTRAN que le VB .NET utilise comme convention d'appel __stdcall.

un exemple d'implementation en C++ de la presente DLL montre l'utilisation de RUNTIME DYNAMIC LINKING avec GetProcAddress, ceci vaudrait il dire qu'ils ont exporté les fonctions de leur DLL avec __cdecl?

L'usage de DllImport sous-entends l'usage de DllExport dans la declaration des fonctions de la DLL en mentionnant la convention d'appel (__cdecl ou __stdcall), dans notre cas pour VB ça sera __stdcall, et en publiant toutes les fonctions exportées pour que je puisse les appeler en utilisant le DllImport avec le externe "C" si je ne me trompe pas.

Mon problème c'est le manque de documentation concernant cette DLL. Tout ce que je sais c'est que dans la DLL il n'y a qu'une seule fonction prévue pour certains traitements.
Ce sont des gens de la recherche qui peut etre ne s'encombrent pas trop avec les détails :roll:

Citation:

---

Envoyé par c4ever

un exemple d'implementation en C++ de la presente DLL montre l'utilisation de RUNTIME DYNAMIC LINKING avec GetProcAddress, ceci vaudrait il dire qu'ils ont exporté les fonctions de leur DLL avec __cdecl?

---

Non, non : __cdecl et __stdcall n'ont aucune influcence sur l'aspect dynamique ou statique du lien mais se différencie essentiellement par :

- l'ordre des paramétres
- la responsabilité du dépilage au retour.
.NET supporte l'appel de fonction externe aussi bien __stdcall (dite "convention d'appel pascal") que __cdecl (convention C,mais on note qu'une DLL C exporte habituellement en convention pascal, plus agnostique au langage client).

Citation:

---

L'usage de DllImport sous-entends l'usage de DllExport dans la declaration des fonctions de la DLL en mentionnant la convention d'appel (__cdecl ou __stdcall), dans notre cas pour VB ça sera __stdcall, et en publiant toutes les fonctions exportées pour que je puisse les appeler en utilisant le DllImport avec le externe "C" si je ne me trompe pas.

---

Oui.

Citation:

---

Mon problème c'est le manque de documentation concernant cette DLL. Tout ce que je sais c'est que dans la DLL il n'y a qu'une seule fonction prévue pour certains traitements.
Ce sont des gens de la recherche qui peut etre ne s'encombrent pas trop avec les détails :roll:

---

Si tu as la signature de la fonction, cela ne devrait pas poser de gros problèmes.
Tu la déclare comme une méthode VB avec l'attribut DllImport.
en fonction du type de paramétres, il est possible d'avoir à préciser certains détails concernant le "marshalling" des paramètres.

Citation:

---

Envoyé par François M.

la responsabilité du dépilage au retour.

---

Je suppose que tu parles de la décoration des noms utilisé par le compilateur.

Citation:

---

Envoyé par François M.

Si tu as la signature de la fonction, cela ne devrait pas poser de gros problèmes.
Tu la déclare comme une méthode VB avec l'attribut DllImport.
en fonction du type de paramétres, il est possible d'avoir à préciser certains détails concernant le "marshalling" des paramètres.

---

Oui j'ai la signature. Maintenant j'essaye de comprendre le marshaling des types structurés.
https://msdn.microsoft.com/fr-fr/lib...=vs.71%29.aspx.
Je reviendrais vers toi, si encore je me heurte à des zones d'ombre :?
Merci François, ta patience est appréciée.

Citation:

---

Envoyé par c4ever

Je suppose que tu parles de la décoration des noms utilisé par le compilateur.

---

Non, pas du tout, je ne l'avais pas abordé cette question de décoration car assez secondaire.
Je parle de la gestion de la stack :

en __cdecl, c'est la fonction appelante qui nettoie la pile d'appel au retour. (restauration du registre SP)
en __stdcall, c'est de la responsabilité de la fonction appelée. (ce point rend impossible avec __stdcall l'utilisation/l'exportation de fonctions dont le nombre de paramètres est déterminé uniquement au moment de l'appel - exemple : "printf" du C).

Citation:

---

Envoyé par c4ever

Oui j'ai la signature. Maintenant j'essaye de comprendre le marshaling des types structurés..

---

Si tu as des difficultés, poste la signature de la fonction qu'on puisse t'aider.