为什么我能够从 64 位模式下在 IIS7 中运行的 AnyCPU .NET Web 应用程序调用 32 位 COM 库？
在不使用 COM+ 代理服务的情况下，我很高兴能够使用来自 .NET 应用程序的 32 位 COM 互操作库中的类，该应用程序是使用目标 AnyCPU 编译的，在 64 位 w3wp 进程中运行。
我成功地在 64 位 .NET 进程中实例化了 32 位 COM 互操作库中的类。
w3wp 在 64 位模式下运行，并且 IIS 配置设置为不允许 32 位应用程序。最重要的是，有一个专门的 x64 编译和注册的 .NET 程序集。
我只是想知道，这怎么可能？
有趣的是，如果代码是使用 Visual Studio 2008（针对 3.5 框架）编译的，那么它的工作效果会非常好。如果使用针对 3.5 框架的 Visual Studio 2010 编译相同的代码，则应用程序在尝试加载 32 位 COM 互操作库时会严重失败。正如它应该的那样。
Without using a COM+ proxy service, I'm quite happily able to use classes from a 32 bit COM interop library from a .NET application compiled with target AnyCPU, running in a 64 bit w3wp process.
I'm successfully instantiating classes from a 32 bit COM interop library in a 64 bit .NET process.
w3wp is running in 64 bit mode, and the IIS configuration is set to not allow 32 bit applications. Ontop of that is the fact that there's a specifically x64 compiled and registered .NET assembly down the line.
I'm just wondering, how is this at all possible?
Of interest is that this works just beautifully if the code is compiled with Visual Studio 2008, targeting the 3.5 framework. If the same code is compiled with Visual Studio 2010, targeting the 3.5 framework, the application fails spectacularly when it tries to load the 32 bit COM interop library. As it should.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果它正在运行，它将以 32 位模式运行，你不能在 64 位进程中拥有 32 位的东西，反之亦然。过程完全是其中之一或另一个。
这与在 64 位主机上运行 32 位进程不同，显然，这是可行的。
另一种选择是第三方的东西实际上提供了 64 位参考，而您运行 32 位的结论是不正确的。
It will be running in 32-bit mode if it is running at all, you cannot have 32bit stuff in a 64bit process and vice versa. A process is entirely one or the other.
That is not the same as running a 32bit process on a 64bit host, obviously, that works.
The other alternative is that the third party stuff is actually providing a 64bit reference, and your conclusion of it running 32bit is incorrect.
你。是。不是。
观点。
将 Web 应用程序设置为 32 位模式。这实际上是他们应该按照 MS IIS 指南（大多数人从来不去阅读）运行的方式。
You. Are. Not.
Point.
Put the web application to 32 bit mode. This is actually how they SHOULD run per MS IIS guidelines (that most people never bother to read).
w3wp 进程可以在 32 位模式下运行，因此可以处理 32 位程序集。查看您的 IIS 服务是否以 32 位模式运行。
The w3wp process can run in 32-bit mode and thus can handle 32bit assemblies. See whether your IIS service is running in 32-bit mode.
我将其归因于该解决方案包含的大量代码和项目的复杂性。删除有问题的库为 64 位的要求已经解决了问题，但自然不能回答问题。它只会让它变得过时。
I'll chalk this up to some complexity in the tonnes of code and projects that the solution consists of. Removing the requirements of the offending library to be 64 bits has solved the issue, but naturally doesn't answer the question. It just makes it obsolete.
它通过 DllSurrogate 机制工作，当您尝试加载错误位数的 com-dll 时，该机制会自动创建 DllHost 进程。在这些情况下，您将获得隐式进程间通信。只需看一下 main 即可。
It works through the DllSurrogate mechanism which automatically creates a DllHost process when you try to load a com-dll of the wrong bitness. In those cases you get implicit interprocess communication. Just take a look at main.