Qu'est-ce qui provoque le verrouillage de ProcessorArchitecture sur x86 ou MSIL?

Question

J'ai une application .Net 2.0 qui utilise COM pour appeler une application LabVIEW (construite en .exe). L'application LabVIEW appelle divers assemblys .Net que nous avons écrits.

Normalement tout cela fonctionne très bien. J'ai un app.config qui redirige l'application LabVIEW vers les bonnes versions des bons fichiers, et tout est heureux.

Hier, l'application LabVIEW a décidé de ne pas trouver l'un de mes assemblages sur ce PC. L'erreur du journal Fusion indique qu'elle souhaite la version x86 de l'assembly, mais la version MSIL a déjà été chargée.

Notez que nous avons construit l'assembly en question avec platform = x86. Notez également que la même version a très bien fonctionné sur 5 PC identiques (jusqu'au matériel).

Alors j'ai pensé, hé, il n'y a aucune raison pour moi d'appliquer x86. J'ai supprimé la spécification de plate-forme de la construction et construit une version MSIL de l'assemblage. La fusion a ensuite eu la même erreur, mais elle a indiqué qu'elle souhaitait la version MSIL de l'assembly, lorsque la version x86 avait déjà été chargée.

(I Tried bidouiller avec corflags, aussi.)

Nous ne répertorions nos assemblées dans le GAC, ils sont tous locaux à l'application, et il n'y avait pas d'autres copies des assemblées à cette PC

Oh, et pour ajouter à la confusion: le problème est parti après la mise à jour de notre base de données, de toutes choses. Cela fonctionne maintenant, avec la même construction que j'ai commencé avec.

L'assemblage en question ne fait pas partie de notre code DB, c'est une classe distincte et son usine associée. Il utilise les assemblys de code DB, mais il ne communique pas directement avec la base de données.

Qu'est-ce qui fait que ProcessorArchitecture est .Net verrouillé sur x86 ou MSIL?

Est-ce que cela vous est déjà arrivé, et si oui, qu'avez-vous fait pour le réparer?

(Si le problème revient, je vais poster le truc du journal de fusion exacte, puisque le problème a disparu, je n'ai pas les journaux disponibles.)

Answer 1

Alors! Il s'avère que le problème était lié à la mise à jour de la base de données. Il y avait une table qui nécessitait des données statiques qui n'étaient pas configurées.

Un Snickerdoodle virtuel à quelqu'un qui peut me dire pourquoi obtenir un nul retour à partir d'une requête DB serait mess avec le ProcessorArchitecture qui a obtenu chargé ...