Babe59
Babe59

Reputation: 45

AnyCPu vs ODP.NET

My config: Vs2015 / X64 PC / ODP.NET X86

I've wrote a few DLL on 'Any Cpu' mode and I would like to write programs that use this DLLs and that can be work on X64 and X86 machins.

But I referenced "Oracle.DataAccess.dll" in my Dlls then I've a warning 'ProcessorArchitecture=X86' on Oracle DLL.

How can I do (I can install ODP.NET X64 if necessary) ?

thks

Upvotes: 1

Views: 1598

Answers (3)

dbencs
dbencs

Reputation: 74

All the above mentioned solutions are correct, but I just feel the need to mention Oracle.ManagedDataAcces as it does not care what the bitness is.

Upvotes: 0

Wernfried Domscheit
Wernfried Domscheit

Reputation: 59456

When you compile your DLL with "x86" then also the Oracle.DataAccess.dll must be the x86 version (i.e. 32 bit version)

When you compile your DLL with "x64" then also the Oracle.DataAccess.dll must be the x64 version (i.e. 64 bit version)

For "AnyCPU" it depends, there is no "AnyCPU" version of Oracle.DataAccess.dll. If your application runs on 64-bit Windows it will run as x64 process - thus also Oracle.DataAccess.dll must be the x64 version. If your application runs on 32-bit Windows it will run as x86 process - thus also Oracle.DataAccess.dll must be the x86 version.

To cut a long story short: architecture of Oracle.DataAccess.dll must be the same as the application, i.e. your DLL.

Follow this instruction to run both in parallel: BadImageFormatException. This will occur when running in 64 bit mode with the 32 bit Oracle client components installed

Update

In your *.csproj, resp. *.vbproj edit your reference to ODP.NET like this:

<Reference Include="Oracle.DataAccess">
  <SpecificVersion>False</SpecificVersion>
  <Private>False</Private>
</Reference>

Attributes like Version=... or processorArchitecture=... are not required. Your application will load the correct Oracle.DataAccess.dll depending on selected architecture and target .NET framework (provided that it is installed properly)

Upvotes: 1

Justin
Justin

Reputation: 86729

The easiest solution would be to target x86 - a 64-bit operating system can still load and run 32-bit applications, and so this would mean your app can run on both x86 and x64 machines.

The downside is that your app must run as a 32-bit processes, i.e. your process will have a 4GB maximum address space and cannot load 64-bit assemblies. If you try to load your dll in a 64-bit process (e.g. because IIS hasn't been configured to use a 32-bit app pool) you will get a BadImageFormatException.

If thats not acceptable to you then you could try detecting the process version and dynamically loading the correct assembly as per this Stack Overflow answer

Upvotes: 0

Related Questions