11
votes

Créez une DLL C # qui peut être importée dans une application Delphi à l'aide de StdCall - possible?

J'ai un programme que j'ai besoin de créer une DLL, espérons-le en C #. Le programme est écrit à Delphi et j'ai un fichier d'interface pour coder. L'interface utilise la convention d'appel STDCALL.

est-il possible de créer une DLL C # qui est conforme à l'interface et peut être utilisée dans l'application DELPHI?

Y a-t-il un certain code de code qui démontre comment coder la DLL C # à une méthode d'interface STDCALL?


0 commentaires

9 Réponses :


3
votes

Jetez un coup d'œil à Hydra


0 commentaires

1
votes

Je suis sûr que cela ne peut pas être fait directement. Vous devrez écrire un calque en C ++ / CLI ou exposer le code C # sous forme d'interface ActiveX. Mais cette deuxième option peut ne pas répondre à votre interface.


0 commentaires

1
votes

Ce n'est pas directement possible. C # est le code géré. Cela signifie qu'il nécessite un environnement d'exécution très spécifique pour fonctionner, un environnement que Delphi ne pouvait pas y fournir directement. Ce n'est pas comme C où vous trouvez simplement l'adresse et appelez la convention de la fonction et appelez-la.

Cependant, il est possible d'héberger l'exécution de la langue commune à l'intérieur d'une application Delphi (ou de toute autre application Windows). Je n'ai aucune idée comment faire ça. Je sais juste que c'est possible. (Il est fort probable que ce "hydre" que Steve a mentionné fera.)


0 commentaires

2
votes

Vous devez faire l'assemblage (= C # DLL) accessible à COM, appelé Interop.

Voir les articles MSDN assemblage de la conversion de bibliothèque de type et Emballage d'un assemblage pour COM qui décrit le fond technique et les utilitaires pour effectuer la Opérations requises.


0 commentaires

7
votes

Ce n'est pas possible dans pure c #, mais Il s'agit d'un article qui montre comment ajouter une table d'exportation non gérée de votre bibliothèque C #, qui peut ensuite être utilisée dans une autre langue. Notez que les hordes des références à Blitz ne doivent pas vous libérer - ils se rapportent au propre contexte de l'auteur et n'ont rien à voir avec le concept de base et son fonctionnement.

Il y a aussi une section de Brian Long's One Confery Paper . Dans une torsion que vous pouviez voir comme un peu ironique, Delphi.net a effectivement soutenu des exportations non gérées directement malgré C # ne le faisant pas. Je ne sais pas si cela est vrai de Delphi Prism.


0 commentaires

3
votes

Hors de curiosité, pourquoi espérez-vous écrire un fichier .dll destiné à être utilisé à partir d'une application native en C #?

Géré C ++, Delphi pour .NET et maintenant Delphi Prism Soutenez ceci hors de la boîte à l'aide des exportations non gérées. Par design, c # et vb.net ne le font pas. Pas certain de pourquoi. Mais comme cobus mentionné, vous pouvez en quelque sorte pirater cela. Faites-le à vos risques et périls.

En plus de Hydra de Remobjects, Atozed est introduit crostabling .


0 commentaires

3
votes

J'ai trouvé un Poste de Robert Giesecke sur les groupes de discussion Prism de Delphes. En cela, il annonce un projet que vous pouvez ajouter à une solution qui vous permet d'exporter des fonctions arbitraires d'une DLL .NET simplement en ajoutant l'attribut dllexport . Il prend en charge le marshaling comme dllimport . Il le montre avec un projet de prisme, mais j'imagine que cela fonctionnerait également sur les classes C #. Le poste a été réalisé en mars, donc je ne sais pas si l'attachement sera toujours disponible. La libération de prisme de mai évite un tel outil puisqu'il soutient les exportations non gérées par lui-même.


0 commentaires

6
votes

Je suis au-delà de cette route avant. La solution que j'ai choisie était de créer un nouvel assembly neuf C # (j'ai ensuite porté cela au prisme) qui exposé via com interoppent la fonctionnalité que je devais atteindre. Je trouvais par la boxe noire L'API appelle à quelque chose de plus simple, j'ai pu réduire le nombre de classes que j'ai dû faire face à travers la barrière interopt.

J'ai regardé Hydra, mais c'était surchargé pour ce que j'essayais de faire ... qui a été accédé à un SDK 3ème partie qui a été présenté dans les assemblées .NET pour traiter les données. Si vous envisagez d'intégrer la fonctionnalité (objets d'interface graphique, ECT) dans votre application, vous devriez donner une attention à Hydra.

J'ai utilisé géré.vcl pour une version très précoce du système, mais la plus tard elle l'a abandonnée pour l'approche proportionnelle de prisme / C # Com, plus simple à déployer et plus stable.


0 commentaires

2
votes

Je suppose ici que l'application DELPHI n'est pas une application .NET basée. Vous devez donc héberger l'exécution .NET dans un processus Win32.


0 commentaires