問題描述
為什麼我可以從在 IIS7 中以 64 位模式運行的 AnyCPU .NET Web 應用程序調用 32 位 COM 庫？ (Why am I able to call a 32 bit COM library from an AnyCPU .NET web application running in IIS7 in 64 bit mode?)
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.
參考解法
方法 1:
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.
方法 2:
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).
方法 3:
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.
方法 4:
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.
方法 5:
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.
(by J. Steen、Adam Houldsworth、TomTom、Kangkan、J. Steen、tobias.loew)