x86 64 - Why does referencing x86 dll from a x64 compiled project work in c# Visual Studio? - Stack Overflow

I wrote a stand alone x86 app for a specific purpose, which I call (from my x64 built app/solution) by creating a new process with a text file path as an argument.

The format of the data in the text file I obviously want in only one place, so I put this in a stand alone project in the x86 app and then I (absent mindedly) referenced the x86 dll of that project directly from my x64 project.

Yet, it is working correctly. How? That is, a class that is defined (and only defined) in the x86 solution is used in my x64 code and then I write the contents to a file, and this x64 project knows the existence of this class only because I added a reference to a x86 dll. When i remove the reference, the x64 project doesn't compile.

There is no AnyCpu anywhere, everything is x86 or x64. I'm using .NET Framework 4.7.2.

I am assured by many posts on here and everywhere else that mixing x86 and x64 dlls does not work. What am I missing?

I wrote a stand alone x86 app for a specific purpose, which I call (from my x64 built app/solution) by creating a new process with a text file path as an argument.

The format of the data in the text file I obviously want in only one place, so I put this in a stand alone project in the x86 app and then I (absent mindedly) referenced the x86 dll of that project directly from my x64 project.

Yet, it is working correctly. How? That is, a class that is defined (and only defined) in the x86 solution is used in my x64 code and then I write the contents to a file, and this x64 project knows the existence of this class only because I added a reference to a x86 dll. When i remove the reference, the x64 project doesn't compile.

There is no AnyCpu anywhere, everything is x86 or x64. I'm using .NET Framework 4.7.2.

I am assured by many posts on here and everywhere else that mixing x86 and x64 dlls does not work. What am I missing?

• c#
• x86-64

Share Follow asked Jan 29 at 17:40 John MJohn M 3111 silver badge44 bronze badges 11

• 2 When you attach a debugger to the running program, can you confirm that it's actually mapping the x86 (32-bit) DLL into the process's memory? Rather than finding a 64-bit x64 DLL of the same name? A debugger should be able to show you the list of DLLs used, list of memory-mapped files, etc. – Peter Cordes Commented Jan 29 at 17:49
• 1 and also Sysinternals Process Explorer can show a list of .NET assemblies loaded by a process, where one can check if a path of a specific dll points indeed to a 32-bit dll, not to a 64-bit one – Renat Commented Jan 29 at 18:00
• 1 The traditional and very common mistake is to change the project's Platform setting. Prominently visible on the toolbar. That has no effect on a C# project, it uses a just-in-time compiler that generates code at runtime that's compatible with the machine's processor. The setting that actually matters is Project > Properties > Build > "Platform target", use it only if you need to force the kind of just-in-time compiler that will be used. Necessary only if you interop with native code. – Hans Passant Commented Jan 29 at 20:24
• 1 The "bitness" of the process being started later is not relevant, the question is how can a project set to x64 compile while referencing a x86 dll (and the answer is that it can't). – John M Commented Jan 30 at 9:31
• 1 @AlexeiLevenkov: I think they're saying they're creating a 32-bit program to use a 32-bit DLL they have, which has to run as a separate process spawned from their main 64-bit program. That is indeed the only way to use a 32-bit binary-only DLL from 64-bit code. (The IPC mechanism can be simple file, or some kind of remote procedure call stuff.) I don't see them saying that the bitness of a process will depend on the parent. – Peter Cordes Commented Jan 30 at 9:31

 |  Show 6 more comments

1 Answer 1

Sorted by: Reset to default 2

From Hans Passant in comment,

The setting that actually matters is Project > Properties > Build > "Platform target"

I said in the question there was no use of AnyCpu but this was false - when I checked this setting for the project, it was targeting AnyCpu.