是什么导致 ProcessorArchitecture 锁定到 x86 或 MSIL？
我有一个.Net 2.0应用程序，它使用COM调用LabVIEW应用程序（构建为.exe）。 LabVIEW 应用程序调用我们编写的各种.Net 程序集。
通常这一切都工作正常。 我有一个app.config，可以将LabVIEW应用程序重定向到正确文件的正确版本，一切都很顺利。
昨天，LabVIEW 应用程序发现它在这台 PC 上找不到我的程序集之一。 Fusion 日志错误表明它需要 x86 版本的程序集，但 MSIL 版本已经加载。
请注意，我们使用 platform=x86 构建了相关程序集。 另请注意，相同的构建在 5 台相同（具体到硬件）的 PC 上运行得很好。
所以我想，嘿，我没有理由强制执行 x86。 我从构建中删除了平台规范，并构建了程序集的 MSIL 版本。
Fusion 然后出现了相同的错误，但它表示需要 MSIL 版本的程序集，而 x86 版本已经加载。
（我也尝试过使用 corflags。）
我们不在 GAC 中注册我们的程序集，它们都是应用程序的本地程序集，并且该 PC 上没有程序集的其他副本。
哦，更令人困惑的是：更新数据库后问题就消失了。 现在它正在工作，与我开始时的构建相同。
有问题的程序集根本不是我们的数据库代码的一部分，它是一个单独的类及其关联的工厂。 它使用数据库代码程序集，但不与数据库直接通信。
是什么让 .Net 中的 ProcessorArchitecture 锁定到 x86 或 MSIL？
您是否遇到过这种情况？如果有，您采取了什么措施来解决它？
（如果问题再次出现，我将发布确切的 Fusion 日志内容，因为问题消失了，我没有可用的日志。）
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.
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.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所以！ 事实证明，问题与数据库更新有关。 有一个表需要一些尚未设置的静态数据。
对于任何能告诉我为什么从数据库查询返回 null 会扰乱已加载的 ProcessorArchitecture 的人来说，这是一个虚拟的笑声......
So! It turns out the problem was related to the DB update. There was a table that needed some static data that wasn't getting set up.
A virtual snickerdoodle to anybody who can tell me why getting a null back from a DB query would mess with the ProcessorArchitecture that got loaded...