开发者

Why am I able to call a 32 bit COM library from an AnyCPU .NET web application running in IIS7 in 64 bit mode?

开发者 https://www.devze.com 2023-03-21 20:27 出处:网络
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.

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.


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.


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).


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.


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号