2

I have a pure managed .NET dll (an assembly) which is currently being compiled with a Platform Target of x86. Since this is pure .NET code (no unmanaged references or interops) it could/should be AnyCPU but for whatever reason it is not.

This dll is being referenced by an AnyCPU .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 issue lingering around when running under 64-bit.

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

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

SomeWritesReserved
  • 1,075
  • 7
  • 17

4 Answers4

3

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

If you have an x86 target, you may find yourself on a 64bit platform with a .Net exe set for AnyCPU. That exe is gonna start a 64bit process, and either your x86 dll won't like it or you end up forcing the app to run in 32bit 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 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's there is the occasional reason to force the app into one mode or the other, but for dlls where you don't know the exe, most of the time AnyCPU is the right option.

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

Joel Coehoorn
  • 380,066
  • 110
  • 546
  • 781
1

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

For EXEs you can have problems if you depend on 32 bit native DLLS and don't specify the architecture.

Yaur
  • 7,195
  • 1
  • 24
  • 35
  • 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

In completion to Joel Coehoorn 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 apps :)

Elias Platek
  • 1,071
  • 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, no interop, no unmanaged/unsafe code, the processor archirecture does not matter. It should ideally be set to AnyCpu.

The Machine PE header is used only by the OS while launching an exe. When a dot net process loads a dll, it ignores that field. For a dotnet dll, 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.

inquisitive
  • 3,469
  • 2
  • 19
  • 46