1

Just like the title says, If I change the target cpu of a vb.net assembly, will it break binary compatibility?

Alex
  • 343
  • 1
  • 5
  • 13

1 Answers1

1

"Binary compatibility" was a VB6 term, it was relevant to generating a COM dll that used the same Guids for the interfaces and classes so you could update an existing dll and not fear that your update would break the existing program. The rules are completely different for .NET code, the jitter helps a lot.

Nor is the Platform target setting for a DLL project very relevant. Only the setting on the EXE project matters, it determines the bitness of the process. You could consider forcing your DLL to x86 if it has a dependency on legacy 32-bit code. That will make the program crash quicker on the BadImageFormatException instead of getting an obscure COM exception.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • We actually have the other way around, a 32-bit executable that uses this assembly. Now, in an x86 environment this is not a problem, but in an x64 environment this does become a problem (and the BadImageFormatException you mentioned ensues) What I'm trying to figure out is whether or not changing the platform target will cause the updated dll to not break our existing program ("Binary Comparability" may still be relevant as the calling application is VB6?) – Alex Apr 06 '11 at 15:38
  • DLL assemblies should always be compiled with the Platform target set to AnyCPU. So they'll work properly either way. It isn't otherwise clear to me how you could get that exception if you know for a fact that the EXE is running as a 32-bit process. They get their own view of the registry, they would not be able to find nor load a 64-bit COM server. Different exception. Do triple-check your assumption that the EXE is executing in 32-bit mode. You'd see *32 in the Processes tab of TaskMgr.exe for example. – Hans Passant Apr 06 '11 at 15:47
  • Yes, the calling application is indeed running in 32-bit mode (it has the *32 in the process list). – Alex Apr 06 '11 at 16:08
  • If you have no clue at all what DLL is causing this exception then use SysInternals' ProcMon utility. You'll see the EXE searching and opening the .dll files. Last one before the exception is the problem one. – Hans Passant Apr 06 '11 at 16:12