I have a .Net 2.0 application that uses COM to call a LabVIEW application (built as an .exe). The LabVIEW application calls various .Net assemblies we've written.
Normally this all works fine. I have an app.config that redirects the LabVIEW app to the right versions of the right files, and everything is happy.
Yesterday the LabVIEW application decided that it couldn't find one of my assemblies on this one PC. The Fusion log error indicated that it wanted the x86 version of the assembly, but the MSIL version had already been loaded.
Note that we had built the assembly in question with platform=x86. Also note that the same build worked just fine on 5 identical (down to the hardware) PCs.
So I figured, hey, there's no reason for me to enforce x86. I removed the platform spec from the build and built an MSIL version of the assembly.
Fusion then had the same error, but it said it wanted the MSIL version of the assembly, when the x86 version had already been loaded.
(I tried mucking around with corflags, too.)
We don't register our assemblies in the GAC, they're all local to the application, and there were no other copies of the assemblies on that PC.
Oh, and to add to the confusion: the problem went away after updating our database, of all things. It's working now, with the same build I started with.
The assembly in question is not part of our DB code at all, it's a separate class and its associated factory. It uses the DB code assemblies, but it does no direct communication with the database.
So, Dear Stack Overflow Readers, I have ~2.5 questions for you:
What makes the ProcessorArchitecture in .Net lock to x86 or MSIL?
Has this ever happened to you, and if so, what did you do to fix it?
(If the problem comes back, I'll post the exact Fusion log stuff, since the problem went away I don't have the logs available.)