Reputation: 45
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
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
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
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