0

I am trying to do a Windows app and connect to an Oracle database. For now, this is all I am trying to do. When I test this from development server (Windows 2003 Server) it works fine. I copy the content of "output" folder (where the .exe file is in) to my local machine (Windows 7) and try to run the same app and get errors. Same thing happens when I copy the code to another server running Windows 2003. The error I get is: "Could not load file or assembly 'Oracle.DataAccess, Version 2.112.3.0, culture=neutral, Public Key Token=89b483f429c47342' or one of its dependencies. An attempt was made to load a program with an incorrect format."

Since there is no Oracle.DataAccess.DLL file on either my local machine or on the server where the test failed, I thought maybe I can copy the DLL to Windows application's output folder, add a reference to this DLL and compile. But that was not the solution.

Is there any way I can fix this without expecting every machine this application (eventually, a Windows Service) is running from to have Oracle.DataAccess.DLL in GAC? Do I have to install ODAC on all the machines this application will running from (something like couple of hundred servers)?

kurast
  • 1,660
  • 3
  • 17
  • 38
NoBullMan
  • 2,032
  • 5
  • 40
  • 93
  • I resolved this by using System.Data.OracleClient instead of Oracle.DataAccess.Client. Not sure if this is the right way of approaching the issue but at least a short term solution. – NoBullMan May 15 '14 at 19:30
  • NoBullMan - That may have worked because Oracle.DataAccess.Client is provided in both x86 and x64 flavours. There may have been some additional configurations and/or installations that you would have had to do in order to get Oracle.DataAccess.Client in working order that would have been unnecessary with System.Data.OracleClient. ie. if you had an x86 dll and a x64 client, or vice versa, it wouldn't work. – S. Dixon May 26 '15 at 15:40

2 Answers2

0

If you can get away with the System.Data.OracleClient connection, than you don't have to do anything special on the servers.

If you want to use the ODAC connector, you will need to install the client on each of the servers and include the TNS names. It is a bad design on Oracle's part.

animuson
  • 53,861
  • 28
  • 137
  • 147
Patrick Wensel
  • 67
  • 10
0

Both System.Data.OracleClient and Oracle.DataAccess require you to install Oracle client software on to each server. As such, their portability leaves a lot to be desired.

A more portable way to deploy your Oracle software would be to use the managed Oracle library, Oracle.ManagedDataAccess, which is available via Nuget. It does not require an Oracle client installation.

Be aware that, since Oracle.ManagedDataAccess does not rely on the oracle client software, that you will have to adjust some configurations. You can either include the tnsnames.ora along with your deployed application, write the connection string as you would an entry in tnsnames.ora, or you can specify the exact hostname/port/oracle sid.

If you insist on using an unmanaged Oracle Client, consider the following:

System.Data.OracleClient (and System.Data.OleDb) are easier to deploy than Oracle.DataAccess since they are part of the .NET framework and are written for any CPU. However, they both have the same functionality and same limitations; System.Data.OracleClient is also a deprecated library.

On the other hand, Oracle.DataAccess offers more functionality but comes in both x64 and x86 flavours, which can make deployment a lot trickier (especially on IIS-hosted web applications).

S. Dixon
  • 842
  • 1
  • 12
  • 26