How to build x64 and x86 projects that reference s

Question

I have three projects, ProjectA (exe), ProjectB (exe) and ProjectD (class library)

Project A references the System.Data.OracleClient.dll and ProjectD. Project B just references ProjectD. The 32-bit client version of oracle is installed and therefore ProjectA has to be a 32-bit application. Project B can be built as a 64-bit application.

Project A build settings:

Platform: Active (x86)

Platform target: x86

Project B build settings:

Platform: Active (Any CPU)

Platform target: Any CPU

My questions are what should the build settings be for ProjectD (the class library) and when ProjectA and ProjectB get built does it build ProjectD differently? A deeper explanation of the CLR would be great in terms of communications of the projects.

ProjectA and ProjectB are to be used on 64-bit Windows Server 2008. No installation, just standalone exe's.

Answer 1

My questions are what should the build settings be for ProjectD (the class library) and when ProjectA and ProjectB get built does it build ProjectD differently? A deeper explanation of the CLR would be great in terms of communications of the projects.

Just use Any CPU for your lib. It'll build a unique assembly that can be executed in both 32-bit en 64-bit environments.

Technically, the just in time compilation with either produce 32-bit code or 64-bit code at runtime.

Answer 2

Only the Platform target setting for the EXE project matters. That's the assembly that gets loaded first and determines the bitness of the entire process.

A DLL doesn't get a choice, it must be compatible with whatever was selected by the EXE project. Picking AnyCPU for a DLL project is therefore almost always the correct selection.

There are just a few cases where you'd use an explicit setting. You'd only do so if you know that the class library has a dependency on some kind of native code, like the Oracle provider, and that trying to run that native code in the wrong bitness produces a completely inscrutable exception. You can avoid that exception and get a (slightly) better one by picking the Platform target for the DLL, the program will fail with a BadImageFormatException early when it tries to load the assembly. Albeit that this exception isn't exactly a very informative one either. Some odds that an admin is going to try to reinstall the DLL a couple of times before deciding that the real problem is elsewhere.

So basic ground rules: pick x86 for the EXE project, AnyCPU for all other class library projects, a nastygram to Oracle for doing nothing to make this easy.