Impossible de charger le fichier ou l'assembly ... ou l'une de ses dépendances. Une tentative de chargement d'un programme avec un format incorrect (fichier .resx) a été effectuée

Question

Je reçois le message d'erreur suivant lors de la compilation ou de la tentative d'exécution de mon application sur Windows 7 64 bits. J'ai parcouru l'Internet et beaucoup de gens ont le même message d'erreur. Cependant, aucune des solutions de l'adresse de mon problème ou de la situation. Je suis à l'aide de Visual Studio 2010.

Message d'erreur

L'erreur 38 n'a pas Pu charger le fichier ou l'assembly 'file:///D:/Projets/Windows Projects/Weld/Components/FileAttachments/FileAttachments/FileAttachments/bin/x86/Debug/FileAttaching.dll" ou une de ses dépendances. Une tentative a été faite pour charger un programme avec un format incorrect. Ligne 1212, position 5. D:\Projects\Windows Les Projets\Soudure\Soudure\Soudure.UI\frmMain.resx 1212 5 de Soudure.L'INTERFACE utilisateur

Description

OK, donc j'ai deux projets, une INTERFACE et un FileAttachment projet. L'INTERFACE utilisateur projet a une référence à la FileAttachment projet. Quand je compile l'INTERFACE utilisateur projet "any CPU" mode, tout fonctionne bien, et il s'exécute. Je suppose que " Tout CPU fonctionnera en mode 64 bits quand je compile que c'est la plate-forme que j'utilise.

Je veux courir/compiler que les x86, j'ai donc essayer de le faire. J'ai changer la configuration de tous les projets pour x86 et vérifier que ces configurations sont compilation pour x86. Je compile et obtenez le message d'erreur indiqué ci-dessus.

Je trouve bizarre qu'il compile et fonctionne très bien en 64 bits mais pas 32-bit. Cependant, lors de la compilation et déployée pour les utilisateurs comme "any CPU", si ces utilisateurs ont x86 il travaille toujours pour eux sans aucun problème. Je ne peux pas compiler ou exécuter en tant qu'x86 sur mon PC. Encore une fois, je peux compiler comme n'Importe quel CPU et de la déployer sur un PC 32 bits sans aucun problème.

Ni les projets sont référence à 64 bits uniquement les fichiers DLL. Les deux projets sont vérifiées pour le ciblage 32-bit DLL fichiers, et .NET Framework assemblées.

J'ai besoin de le compiler et de l'exécuter localement sous le mode 32-bit. J'ai besoin de JIT modifier/continuer, entre autres choses.

Voici la ligne de code dans le fichier resx qui est à l'origine du problème:

 <data name="ImageList1.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">
....{mime data}....
 </data>

Le fichier resx est vérifié pour être généré pour .NET 2.0 et uniquement référence .NET 2.0 assemblées et pas .NET 4.0 versions.

Comment puis-je résoudre ce problème? J'ai cherché sur Internet et trouvé des centaines de personnes avec le même message d'erreur, mais d'un autre problème.

Answer 1

Cela semble être une VS 2010 bug avec les listes d'images. Voir https://connect.microsoft.com/VisualStudio/feedback/details/532584/error-when-compiling-resx-file-seems-related-to-beta2-bug-5252020?wa=wsignin1.0

J'ai été en mesure d'utiliser la solution de contournement répertoriées pour le faire fonctionner pour moi.

---

Posté par Luis Mack sur 5/12/2010 à 8:50 AM J'ai trouvé le même problème, seulement pour un projet spécifique lors de la compilation sur une machine 64 bits. Un correctif qui SEMBLE fonctionner manuellement modifier un caractère dans le flux de l'image à CHAQUE FOIS que le usercontrol ou le formulaire est édité dans le concepteur

AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luzg93cy5gb3jtcywgvmvyc2lvbj00ljaumc4w

Changement de AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luzg93cy5gb3jtcywgvmvyc2lvbj0yljaumc4w

C'est 00LjAuMC4w retour à 0yLjAuMC4w à la fin de la ligne (00 retour à 0y)

---

Jim

Answer 2

Ma solution la plus simple a été d'aller simplement dans la ligne erronée et de changer le base64 en base32

 <data name="myGUIcontrol.myObj" mimetype="application/x-microsoft.net.object.binary.base32">
... block of binary here
 

Mais je voudrais trouver un moyen d'éviter que cela ne se produise à chaque fois que je change de concepteur. Peut-être un attribut pour la classe qui oblige VS10 à en faire un base32?

Answer 3

J'ai eu le même problème avec un de mes programmes. Le problème est que, pour une raison quelconque, le Visual Studio semble être de générer 64 bits des blocs de données pour certains de l'interface graphique de contrôle de propriétés, dont il est alors impossible de charger lors de la compilation pour x86.

Dans mon cas, je suis en mesure de contourner le problème en supprimant l'problamatic des blocs de données à partir du fichier resx le long de la ligne de lignes de code dans le cs.concepteur fichier de référence de ces blocs. Je suis capable de faire ce que les lignes de code source que l'affectation d'référencé dans la propriété sont redondantes et n'est pas nécessaire. La seule chose ennuyeuse, c'est que je dois refaire les correctifs à chaque fois que je modifie en rien le designer, Visual Studio ajoute ensuite de retour dans le mauvais code.

Answer 4

Nous avons rencontré le même problème la semaine dernière et nous avons trouvé une solution de contournement intéressante.

Vous devez ouvrir le fichier .resx dans Designer et définir le modificateur d'accès de public à aucune génération de code.