2

I have a pure managed .NET DLL file (an assembly) which is currently being compiled with a Platform Target of x86. Since this is pure .NET code (without any unmanaged references or interops) it could/should be Any CPU, but for whatever reason it is not.

This DLL file is being referenced by an Any CPU .NET executable. Of course I get the CSC warning

MSB3270: There was a mismatch between the processor architecture of the project being built

but the executable appears to work, even on 64-bit Windows. However, I can't be confident there aren't any issues lingering around when running under 64-bit.

Does Platform Target (x86/x64/AnyCPU) for a pure-managed DLL file matter since the executable is the one dictating x86/x64 execution?

Or put in a different way: Will a running 64-bit .NET executable run into any problems loading/running a "32-bit" .NET DLL file?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
SomeWritesReserved
  • 1,075
  • 7
  • 17

4 Answers4

3

It can matter for a DLL file, because you don't know what kind of EXE file will want to reference that DLL file.

If you have an x86 target, you may find yourself on a 64-bit platform with a .NET EXE file set for Any CPU. That EXE file is going to start a 64-bit process, and either your x86 DLL file won't like it or you end up forcing the application to run in 32-bit mode when it might have done better with 64-bit mode. In the other direction, if you decide to force 64 bit, you might have an EXE file that needs to set 32 bit in order to support an unmanaged 32 bit library, and now you're still out of luck.

For EXE files there is the occasional reason to force the application into one mode or the other, but for DLL files where you don't know the EXE file, most of the time Any CPU is the right option.

Of course, if you do know the EXE file, you want to match it to what the EXE file is doing.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
1

Assemblies that aren't meant to be executed directly should be Any CPU unless they reference native code or contain unsafe code blocks that make assumptions about the processor you will be running on.

For EXE files, you can have problems if you depend on 32 bit native DLL files and don't specify the architecture.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Yaur
  • 7,333
  • 1
  • 25
  • 36
  • 1
    "... unless they reference native code". that worked well for me exept in one case where my dll used sqlite database that uses native code. – k3b Mar 13 '17 at 17:17
  • I know it should be AnyCPU, but its not. The question is if this will cause any problems at runtime if a 64-bit exe calls into this 32-bit dll. I've updated the question. – SomeWritesReserved Mar 13 '17 at 17:20
1

To complete Joel Coehoorn's answer, you will also have different behaviours for some operations, like System.Math.Exp or System.Math.Pow (and many other operations on double type) that won't give you the same results.

This is due to a different precision of the double type on each of these platforms, instructions sets and register sets have not the same size, so rounding errors may appear. It does not have much effect though, rounding errors appear after 15 digits, but it does if you work on market trading applications :)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Elias Platek
  • 1,074
  • 1
  • 9
  • 16
  • 1
    Dont have a win box at hand but i very much doubt that compiling a `dll` for either proc architecture should cause the difference. The difference should come from the proc arch of the `exe`, and not the dll. If someone could please verify. – inquisitive Mar 13 '17 at 17:29
  • Here you can get a more complete answer on this point : http://stackoverflow.com/questions/4018895/why-does-math-exp-give-different-results-between-32-bit-and-64-bit-with-same-in – Elias Platek Mar 14 '17 at 10:09
0

For a pure managed DLL file, no interop, no unmanaged/unsafe code, the processor architecture does not matter. It should ideally be set to Any CPU.

The Machine PE header is used only by the OS while launching an EXE file. When a .NET process loads a DLL file, it ignores that field. For a .NET DLL file, this flag acts only as a reminder as to how far this has been tested to work with.

If NGen is used, then the assembly may not be used in a process of different bitness.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
inquisitive
  • 3,549
  • 2
  • 21
  • 47