Comment corriger l'erreur de compilation de Visual Studio, "mismatch between processor architecture" ?

Question

Je suis novice en matière de configuration de projets dans Visual Studio 2010, mais j'ai fait un peu d'expérience dans ce domaine. recherche et je n'arrive toujours pas à résoudre ce problème. J'ai une solution Visual Studio avec une DLL C++ faisant référence à la DLL C#. La DLL C# fait référence à quelques autres DLL, certaines dans mon projet et d'autres externes. Lorsque j'essaie de compiler la DLL C++, j'obtiens cet avertissement :

avertissement MSB3270 : Il y a eu un désaccord entre l'architecture du processeur du projet en cours de construction "MSIL" et l'architecture du processeur de la référence "[internal C# dll]", "x86".

Il me dit d'aller dans le Configuration Manager pour aligner mes architectures. La DLL C# est configurée avec une cible de plate-forme x86. Si j'essaie de changer cela en quelque chose d'autre, comme Any CPU, il se plaint parce que l'une des DLL externes il dépend de la plateforme cible x86.

Lorsque je regarde le Gestionnaire de configuration, la plate-forme de ma DLL C# est x86 et celle de mon projet C++ est Win32. Cela semble être la bonne configuration ; je ne veux certainement pas que la plate-forme de mon projet C++ soit définie sur x64, ce qui est la seule autre option présentée.

Qu'est-ce que je fais de mal ici ?

Answer 1

Cet avertissement semble avoir été introduit avec la nouvelle version bêta de Visual Studio 11 et .NET 4.5, bien que je suppose que cela aurait pu être possible avant.

D'abord, ce n'est vraiment qu'un avertissement. Il ne devrait rien faire si vous ne traitez que des dépendances x86. Microsoft essaie simplement de vous avertir lorsque vous déclarez que votre projet est compatible avec "Any CPU" mais que vous avez une dépendance sur un projet ou un assemblage .dll qui est soit x86 soit x64. Parce que vous avez une dépendance x86, techniquement votre projet n'est donc pas compatible avec "Any CPU". Pour que l'avertissement disparaisse, vous devez changer votre projet de "Any CPU" à "x86". C'est très facile à faire, voici les étapes.

1. Allez dans l'élément de menu Build|Configuration Manager.
2. Trouvez votre projet dans la liste, sous Plate-forme, il sera indiqué "Any CPU".
3. Sélectionnez l'option " Any CPU " dans le menu déroulant, puis sélectionnez <New..>
4. Dans cette boîte de dialogue, sélectionnez x86 dans le menu déroulant "New Platform" et assurez-vous que "Any CPU" est sélectionné dans le menu déroulant "Copy settings from".
5. Appuyez sur OK
6. Vous voudrez sélectionner x86 pour les configurations Debug et Release.

Cela fera disparaître l'avertissement et indiquera également que votre assemblage ou projet n'est plus compatible avec "Any CPU" mais qu'il est désormais spécifique au x86. Ceci est également applicable si vous construisez un projet 64 bit qui a une dépendance x64 ; vous devez simplement sélectionner x64 à la place.

Une autre remarque, les projets peuvent être compatibles avec "n'importe quelle unité centrale" s'il s'agit de projets purement .NET. Ce problème ne se pose que si vous introduisez une dépendance (dll d'un tiers ou votre propre projet géré en C++) qui cible une architecture de processeur spécifique.

Answer 2

Il s'agit d'un avertissement très tenace et, bien qu'il s'agisse d'un avertissement valide, il existe des cas où il ne peut être résolu en raison de l'utilisation de composants tiers et d'autres raisons. J'ai un problème similaire, sauf que l'avertissement est dû au fait que la plateforme de mon projet est AnyCPU et que je fais référence à une bibliothèque MS construite pour AMD64. Ce problème se pose dans Visual Studio 2010 et semble avoir été introduit par l'installation de VS2012 et de .Net 4.5.

Puisque je ne peux pas modifier la bibliothèque MS à laquelle je fais référence, et puisque je sais que mon environnement de déploiement cible ne sera jamais que 64 bits, je peux ignorer ce problème sans risque.

Et l'avertissement ? Microsoft a posté en réponse à un rapport Connect qu'une option consiste à désactiver cet avertissement. Vous ne devez le faire que si vous êtes très conscient de l'architecture de votre solution, que vous comprenez parfaitement votre cible de déploiement et que vous savez que ce n'est pas vraiment un problème en dehors de l'environnement de développement.

Vous pouvez modifier votre fichier de projet et ajouter ce groupe de propriétés et ce paramètre pour désactiver l'avertissement :

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

Answer 3

Une bonne règle de base est "DLLs ouvertes, EXEs fermés", c'est-à-dire :

• EXE cible le système d'exploitation, en spécifiant x86 ou x64.
• DLLs sont laissés ouverts (c'est-à-dire AnyCPU) afin qu'ils puissent être instanciés dans un processus 32 bits ou 64 bits.

Lorsque vous construisez un EXE en tant que AnyCPU, tout ce que vous faites est de reporter la décision sur le bitness du processus à utiliser au système d'exploitation, qui va JIT l'EXE à son goût. En d'autres termes, un système d'exploitation x64 créera un processus 64 bits, un système d'exploitation x86 créera un processus 32 bits.

Construire les DLL en tant que AnyCPU les rend compatibles avec les deux processus.

Pour en savoir plus sur les subtilités du chargement des assemblages, voir ici . Le résumé se lit comme suit :

• AnyCPU - se charge en tant qu'assemblage x64 ou x86, selon le processus qui l'invoque.
• x86 - se charge en tant qu'assemblage x86 ; ne se charge pas à partir d'un processus x64
• x64 - se charge en tant qu'assemblage x64 ; ne se charge pas à partir d'un processus x86

Answer 4

La DLL C# est configurée avec une plateforme cible x86.

C'est en quelque sorte le problème, une DLL n'a pas vraiment le droit de choisir ce que sera le bitness du processus. C'est entièrement déterminé par le projet EXE, c'est le premier assemblage qui est chargé donc sa cible Platform est celle qui compte et définit le bitness pour le processus.

Les DLL n'ont pas le choix, elles doivent être compatibles avec le débit binaire du processus. Si elles ne le sont pas, vous obtiendrez un grand Kaboom avec une BadImageFormatException lorsque votre code essaiera de les utiliser.

Une bonne sélection pour les DLLs est donc AnyCPU afin qu'elles fonctionnent dans les deux cas. Cela a beaucoup de sens pour les DLLs C#, elles faire travailler dans les deux sens. Mais bien sûr, pas votre DLL C++/CLI en mode mixte, elle contient du code non géré qui ne peut fonctionner correctement que lorsque le processus s'exécute en mode 32 bits. Vous peut pour que le système de construction génère des avertissements à ce sujet. C'est exactement ce que vous avez obtenu. Juste des avertissements, ça se construit toujours correctement.

Il suffit d'évacuer le problème. Définissez la cible Platform du projet EXE sur x86, cela ne fonctionnera pas avec un autre paramètre. Et gardez tous les projets DLL à AnyCPU.

Answer 5

Pour les projets C#, la cible de x86 fait ce à quoi elle ressemble. Elle indique que cet assemblage ne prend en charge que les architectures x86. De même pour x64. D'un autre côté, n'importe quelle unité centrale indique que je ne me soucie pas de l'architecture, je supporte les deux. Donc, les 2 questions suivantes sont (1) quelle est la configuration de l'exécutable qui utilise ces dlls ? et (2) quelle est la cible de x86 ? bitness de votre OS/ordinateur ? La raison pour laquelle je pose la question est que si votre exécutable est compilé pour fonctionner en 64 bits, alors il a BESOIN que toutes les dépendances soient également capables de fonctionner en mode 64 bits. Votre assemblage Any CPU devrait pouvoir être chargé, mais peut-être fait-il référence à une autre dépendance qui ne peut fonctionner qu'en configuration x86. Vérifiez toutes les dépendances et les dépendances des dépendances pour vous assurer que tout est soit "Any CPU" soit "x64" si vous prévoyez d'exécuter l'exécutable en mode 64 bits. Sinon, vous aurez des problèmes.

À bien des égards, Visual Studio ne facilite pas la compilation d'un mélange d'assemblages dépendant de n'importe quel CPU et de diverses architectures. C'est faisable, mais cela nécessite souvent qu'un assemblage qui serait autrement "Any CPU" doive être compilé séparément pour x86 et x64 parce qu'une certaine dépendance d'une dépendance quelque part a deux versions.