Deploying C# console app with Oracle.DataAccess reference

Question

I've been trying to deploy a c# console app that I made to a server. I have basically been copying the contents of the Release folder over to the server, and everything seems to work smoothly except for Oracle. On my development machine (32 bit XP) I have OracleClient 11.2, and the server (64 bit server 2008) has 11.1. The application works if I run it from on local machine.

When I deploy by just copying the Release folder and trying to run the application, I get the following error:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified.
File name: 'Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342'
   at PDV.AODGateway.StoredProcedures..ctor()
   at PDV.AODGateway.AODGateway.Export()
   at PDV.AODGateway.AODGateway.Main(String[] args)

(don't read too much into it looking for the 111.7 version. It says that because I tried specifying in app.config to look for that version. Previously it said it couldn't find 112.1)

The section of code it is failing at is where I create an OracleConnection object.

If I try to copy the dll into the deployment folder from the server, I get a similar error:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'PDV.AODGateway.StoredProcedures' threw an exception. ---> System.BadImageFormatException: Could not load file or assembly 'Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342'
   at PDV.AODGateway.StoredProcedures..cctor()

I have eventually solved the problem by copying these files from the oracleclient folder on my development machine (i.e. the machine I used to build the solution) into the directory of the application on the server:

Oracle.DataAccess.dll
oci.dll
OraOps11w.dll
oraociei11.dll

However, this seems like extremely bad practice, so do any of you have suggestions on how I could get around having to do this? Have any of you run into this issue before?

Do you have many versions of ODAC installed on your machine? Also have a look at this question which has many informations concerning ODAC deployment: http://stackoverflow.com/questions/70602/what-is-the-minimum-client-footprint-required-to-connect-c-sharp-to-an-oracle-da — Ucodia, Oct 21 '11 at 14:48
I only have 11.2 on my machine. And thanks, I'll take a look at that post and see if I can get anything from it. — Michael Holman, Oct 21 '11 at 15:13

score 7 · Accepted Answer · answered Oct 21 '11 at 15:50

I've run it similar issues with the Oracle Data Access Components before. My guess is that you built your .exe using the AnyCPU platform target in your console application's build configuration. This means that when it's run on your 32-bit development machine it will be loaded into a 32-bit process whereas on the 64-bit server it will be loaded into a 64-bit process. The problem is that the Oracle.DataAccess.dll component comes in two different flavours, a 32-bit and 64-bit version. When you copied the 32-bit version into the deployment bin directory from your development machine, at runtime the application would try to load an assembly explicitly marked as 32-bit into a 64-bit process which doesn't work and explains why you get the System.BadImageFormatException.

So perhaps the best solution would be to explicitly target the 64-bit platform in your console app's project settings for the release configuration and reference the 64-bit version of Oracle.DataAccess.dll. On the server you either need the 64-bit Oracle.DataAccess.dll to be installed in the GAC (which it might have been when the ODAC was installed) or you need to deploy the 64-bit assembly with your application.

I've found this stuff to be a pain when you need to target both platforms.

Keep in mind too the oracle client connectivity software installed on the machine running the console app must match the bit level of what the application is running. If you have the 32 bit software installed on a 64 bit server - the c# app must be 32 bit. If the oracle client software is 64 bit - the app must 64 bit. — tsells, Oct 23 '11 at 17:32

Deploying C# console app with Oracle.DataAccess reference

1 Answers1