J'ai un problème, j'ai essayé de le résoudre depuis hier mais pas de chance. J'ai une dll Delphi 32 bits que je veux importer dans une application .NET WIN. Cette application doit être construite sur tout mode CPU . Bien sûr, l'exception BadimageFormatException est lancée, ce qui signifie que les applications 64 bits ne peuvent pas charger X86 DLL. J'ai googlé et j'ai trouvé une solution, cela dit que je dois faire des enveloppes, mais ce n'était pas clair pour moi. Quelqu'un peut-il me dire comment résoudre ce problème, y a-t-il une manière possible d'importer une DLL Delphi 32 bits dans un programme construit sous une architecture de processeur (64 bits, 32 bits) ou peut-être une autre solution?
5 Réponses :
Si je comprends les choses, vous n'avez aucun moyen d'utiliser une DLL 32 bits à partir d'une application 64 bits. Cela dit, vous pouvez compiler votre demande de X86 uniquement.
La solution que vous avez trouvée peut être sur la manière d'utiliser une DLL qui existe pour les versions 32 et 64 bits dans un projet "TOUT CPU" - COMPLILLÉE, selon que l'application fonctionne dans un 32 ou 64 bits. environnement.
Pour ce faire, vous pouvez écrire deux dlls enroulées en C #, une pour 64 bits et une pour 32 bits et utiliser le wrapper respectif selon que vous exécutez sur un système d'exploitation 64 bits ou 32 bits.
Cependant, cela ne fonctionne pas quand tout ce que vous avez est une DLL 32 bits. Une application 64 bits ne peut pas utiliser de DLL 32 bits, ainsi qu'une application 32 bits ne peut pas utiliser de DLL 64 bits.
Vous devez donc compiler votre application pour 32 bits ou vous devez créer une version 64 bits de votre DLL.
À ce moment-là, je n'ai que sur la DLL (32 bits) et il n'y a aucune chance d'avoir une autre version DLL - 64 bits, quelle que soit votre application .NET doit être compilée comme une CPU (qui considère également 64 bits). SOO, n'y a-t-il aucune solution dans ce cas?
Eh bien, comme l'a suggéré Lasse V. Karlsen, vous pouvez écrire une application séparée 32 bits (pas la bibliothèque!) Que vous commencez comme un processus distinct et "parler à" à l'aide de la communication inter procédé.
Une solution Bien que un bit de désordre puisse être d'écrire une application séparée 32 bits que vous pouvez parler à partir de votre application 64 bits, telle qu'une application de console, vous envoyez des commandes à / à partir de.
Pas jolie mais peut fonctionner si vous n'avez besoin que de l'appel occasionnel.
J'ai essayé, pas exactement comme ça, j'ai écrit une bibliothèque de classe, où j'ai importé que Delphi DLL, compilé x86, puis je l'ai réfléchi à mon application principale de 64 bits, mais toujours pas de chance.
Parce que c'est le même problème, seulement avec plus de complexité. Votre application 64 bits ne peut pas utiliser une bibliothèque de classe 32 bits non plus! Mikael parlait d'une application 32 bits que vous communiquez avec des pipes nommées ou d'autres méthodes IPC.
J'ai lu que cela est possible grâce à l'IPC, mais de vous dire la vérité, ce n'était pas tout à fait clair pour moi. Y a-t-il une chance que vous avez des instructions à ce sujet ?? J'ai besoin de plus de détails, car c'est vraiment nouveau pour moi
Ce que vous avez à faire est d'écrire une application wrapper qui héberge le fichier DLL 32 bits, dans un processus 32 bits.
Votre application 64 bits doit alors parler à ce processus 32 bits, via des moyens de réseau, ou en rendant les fonctions DLL disponibles via un objet COM ou similaire.
vous ne peut pas Exécuter une DLL 32 bits à l'intérieur d'un processus 64 bits, peu importe la difficulté que vous essayez, vous devez donc l'exécuter dans un processus 32 bits.
Si la compilation de votre application pour 32 bits n'est pas une option, vous n'avez d'autre choix que de créer une application hôte.
Pouvez-vous me donner une source comment puis-je faire ça? Ou savez-vous où peut être des explications détaillées? Merci beaucoup
Je suis à peu près sûr qu'une application 64 bits ne peut également pas utiliser de composants COM 32 bits, ni je me trompe ici? J'ai eu ce problème avant d'utiliser un contrôle COM 32 bits et j'ai eu des erreurs jusqu'à ce que je puisse compiler mon projet C # sous X86.
Malheureusement, ce n'est pas une option pour moi :(
Je pense qu'ils peuvent utiliser des objets COM désactivés, mais je ne sais pas vraiment. @scatterbraiin, "Quoi" n'est pas une option pour vous?
@Lasse V. Karlsen pour compiler mon projet C # comme x86
@Lasse V. Karlsen Je pense que vous avez raison et ce que vous avez dit résoudra mon problème. Merci beaucoup
Une idée générale pourrait être d'envelopper votre DLL (non gérée) 32 bits avec une dll d'emballage 32 bits gérée et le rend visible. Cela permet aux appels de votre DLL de wrapper via son interface COM.
Vous pouvez utiliser un substrat-poste COM pour que votre COM dLL apparaisse comme un serveur COM de processus. Jetez un coup d'œil à cette question pour obtenir des informations supplémentaires sur ce sujet: Accès X86 com à partir de x64 .NET .
Compilez simplement votre application .NET comme plate-forme X86. Il fonctionnera sur des machines X64 et utilisera votre DLL 32 bits. Ne perdez pas de temps sur une enveloppe.
Pas une option si le système d'exploitation sous-jacent est 64 bits, car il avalera les exceptions qui passent à travers la couche d'exploitation et que vous ne les verrez pas!
Quelle configuration magique du système d'exploitation avez-vous rêvé où vous pouvez exécuter une application 32bit .NET sur le système d'exploitation 64 bits mais les exceptions sont "avalées" ...
Ce n'est pas un rêve, mais mes conditions de développement pendant plusieurs mois. J'ai une machine de développement de 64 bits, et si vous compilez pour la plate-forme X86, les exceptions sont avalées (des tâches parallèles et non seulement). Visual Studio montre simplement dans la fenêtre de sortie "Première chance d'exception" qui ne verra évidemment pas dans l'application client exécutée. Raison: blog.paulbetts.org/index.php/2010/07/20/...
Paul Betts Link est mort mais le cache Google fonctionne: webcache.googleusercontent.com/search?q = cache: http: // ...
Pourquoi ne pas compiler l'application .NET comme x86?
Pourquoi doit-il être compilé comme une CPU? Une application 32 bits fonctionnera sur un système d'exploitation 64 bits.
@Orgonghost parce que c'est le 21ème siècle.
@sproketboy: la réalité du XXIe siècle est que vous ne pouvez pas charger des DLL 32 bits dans une application 64 bits, et chaque fois que vous avez besoin d'une telle DLL (qui est presque toujours là où je travaille, en raison des exigences d'accès matériel ou de communication. ), vous ne pouvez tout simplement pas compiler pendant 64 bits. Et dans presque tous les cas, vous n'avez pas besoin de 64 bits de toute façon. Je ne pense pas que "c'est le 21ème siècle" est une bonne raison;)
@OREGONGHOST Nos applications Java peuvent tirer pleinement parti de 64 bits sans même avoir à recompiler quoi que ce soit.
@sproketboy: pas si vous chargez une DLL 32 bits dans votre processus. Même la JVM ne peut pas faire cela, à moins que vous n'utilisiez l'une des techniques d'emballage expliquées dans les réponses, mais c'est tout le point de cette question. Vous pouvez également faire 64 bits dans .NET sans avoir à recompiler (simplement définir une architecture cible vers n'importe quel processeur, ce qui est ce que l'OP a fait), mais vous ne pouvez toujours pas charger des dlls 32 bits. Il semble que vous manquiez cet important point avec votre obsession du 21e siècle. Les avantages de 64 bits ne sont pas aussi gros que vous pourriez penser, à moins que vous n'utilisiez votre espace d'adressage.
@OREGONGHOST Le point est en Java, vous devriez rarement à charger des dlls du tout puisqu'il s'agit de la plate-forme neutre.
@sproketboy: seulement si vous vivez dans un peu de monde pure Java et que tout ce que vous utilisez est pur Java. Nous avons de nombreux projets utilisant des DLL propriétaires pour la communication avec des périphériques qui ne sont pas disponibles en 64 bits (ou Java ou Bitness-agnostic .NET) et ne peuvent pas être remplacés / réécrit (pour une variété de raisons). Je reçois votre point, mais c'est discutable pour de nombreux développeurs; et si vous vivez dans un monde idéal, .NET fonctionne de la même manière que Java de toute façon si vous compilez tout pour tout CPU (vous ressemblez à des programmeurs Java par définition, de ne pas avoir ce problème, mais ils le font, tout comme il y a des développeurs .net qui Ne pas).
@OREGONGHOST Little? Vous voulez dire beaucoup plus grand que .net, non? La différence est que l'utilisation du code natif est l'exception et non la règle comme celle-ci est dans .NET. Mais je l'obtiens si vous avez de vieilles dlls hérités que vous ne pouvez pas réécrire.
@sproketboy: Je ne sais pas pourquoi vous pensez que l'utilisation de code natif est la règle de .NET. Ce n'est pas. C'est la règle si vous devez utiliser le code natif existant , quelle que soit la langue ou le cadre que vous utilisez. Il y a beaucoup d'applications pure .NET, mais beaucoup de choses intéressantes ne peuvent pas être faites dans Pure Java ou Pure .Net, et cela n'a rien à voir avec les bibliothèques anciennes. Vous sous-estime également combien de code .NET existe, mais ce n'était pas le point; Je pourrais aussi avoir écrit Pure Petit World .Net, le point étant que pur signifie que vous ne pouvez utiliser qu'une fraction du code.