Target an 64 bit Dll not x86

[G_Waddell]

Hi,

I'm writing code to connect to Oracle through ODP so I added a reference to the Oracle.DataAccess dll on my machine.

Trouble is I'm writing a 64 bit app and I appear to have both x86 and 64 bit versions of this dll on my machine. No matter which I try, the x86 version seams to get added.

I've even browsed to C:\Windows\assembly\GAC_64\Oracle.DataAccess\2.111.7.20__89b483f429c47342\oracle.dataaccess.dll but I still get issues saying it is a x86 assembly.

How do I lock it down so I'm only referencing the 64 bit one?

[rubberman]

Assuming you are running a 64-bit version of Windows, then remove the 32bit version of the Oracle data access libraries. On Linux, this would not be a problem, but Windows is much more restrictive.

[sknake]

G_Waddell:

Short answer: You are using the wrong build type. My guess: you are running on a 64-bit version of windows and have your compiler output settings to "Any CPU prefer 32-bit", or "x86".

See configuration options for solution:

Long answer: The problem is build output on your application. You have 5 output scenarios, depending on framework and visual studio versions:
1. x64-only - only run as 64-bit
2. x86-only - only run as 32-bit
3. Any CPU - run as either 32-bit or 64-bit. The native OS architecture decides (ie x86/x64 versions of windows)
4. Any CPU prefer x86 - Same as #3, except when run on ARM platforms IL is compiled to ARM.
5. Itanium - Deprecated. Don't concern yourself with this.

Once the above is determined by the runtime your application launches. Use the task manager to determine if it is running as 32 or 64 bit versions. I suspect it will be 32bit (x86).

Now when your application loads an assembly fusion will decide which assembly to load. Per this article:
https://msdn.microsoft.com/en-us/library/k8xx4k69(v=vs.110).aspx
"The runtime does not consider the file name when determining an assembly's identity. The assembly identity, which consists of the assembly name, version, culture, and strong name, must be clear to the runtime."

Meaning that despite you explicitly defining an exact assembly, the runtime will determine the assembly to load. The path you posted shows the assembly resides in the GAC so the runtime will choose the assembly matching your process architecture.

You can use corflags to determine how the assembly was compiled (x86, x64, any cpu, etc):

C:\>"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\corflags.exe" "C:\Users\scottie2\Documents\visual studio 2013\Projects\am\am\oracle\x86\System.Data.OracleClient.dll"
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.33440

Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 0x18
ILONLY    : 0
32BITREQ  : 0
32BITPREF : 0
Signed    : 1

Google corflags for output interpretation.

Bottom line: change your assembly to be a 64-bit (x64) only assembly. See attached screenshot.

rubberman:
No. This would not solve his issue. You are promoting your affinity to linux and disdain for Microsoft without answering the question.

[JOSheaIV]

This is a rather weird one, becuase if your application is running in 64-bit, then it should be pulling up the 64-bit libraries. Oracle is a stickler for this, and must have identical matchups.

Either that, or the 32-bit libraries are not setup correctly on the system you are working on. We have two products in our office, one that runs 64-bit, and one that runs 32-bit, and when it comes to the Oracle drivers, we had to go through extra work to make sure both were on the system and the applications grabbed the correct architecture (or more they were able to acquire it)