Why doesn't ODP.NET 11 xcopy deployment work o

Question

I have an app that uses a local version of ODAC 11 below the directory that the .exe file is in. The idea is that we want our app to use the local ODAC 11 regardless of what else the user has installed on her machine.

Oracle.DataAccess.dll is in the same directory as the .exe.

It works fine when the client machine has no Oracle client installed, but I get an error when starting it on a machine with Oracle Database 10.2.0.something installed:

The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception.

[Stack Trace]

The provider is not compatible with the version of Oracle client
OracleException
   at Oracle.DataAccess.Client.OracleInit.Initialize()
   at Oracle.DataAccess.Client.OracleConnection..cctor()

I'm guessing that this has something to do with the runtime binding policy, but a search for "Oracle/ODAC/ODP.NET runtime binding policy" on Google has not turned up anything useful.

Does anyone know how to resolve the issue?

If not this specific issue, can someone point me towards an overview of how to do what I want to do: make sure that my application uses the ODAC 11 no matter what?

Answer 1

An article titled "Deploying ODP.NET with Oracle Instant Client" found at http://alderprogs.blogspot.com/2009/04/deploying-odpnet-with-oracle-instant.html gave what was for me about the best explanation of how to deliver a stripped down xcopy type deployment with your application. Only 5 Oracle DLLs required for support.

That said the answers by ObiWanKenobi and Josh Kodroff provides important additional info which matches with my experience.

Add to that: http://www.brothersincode.com/post/Oracle-ODPnet-xcopy-deployment-for-aspnet.aspx

Answer 2

You want to force your ODP.NET drivers to use the copy of oci.dll that is in your local folder, instead of the one already installed.

You can force this by either

• setting the PATH variable so the system finds your copy of of oci.dll first (as in the answer by Josh Kodroff)

or

• you can use ODP.NET configuration section in app.config (or web.config) to explicitly set the value of "DllPath".

For details, see http://ora-00001.blogspot.com/2010/01/odpnet-minimal-non-intrusive-install.html and http://database.in2p3.fr/doc/oracle/Oracle_Database_11_Release_1_(11.1)_Documentation/win.111/e10927/featConfig.htm

Answer 3

If you're using oracle client 10.2.0.1 or 10.2.0.2, Oracle Note 215255.1 indicates that if you apply patchset 10.2.0.3 it fixes the issue. Get the 10.2.0.3 database patch (852MB) and patch the client home. Yes, it's the full database server patchset, but it applies to the client as well.

Answer 4

So as I understand it, the issue was that while Oracle.DataAccess.dll was in the same directory as the app, it could not find its lower-level homies (oci, et al), hence the compatibility error.

Turns out that if you want an application to work with ODAC 11 xcopy deployment regardless of what else the user may have installed on her machine, you need to do 2 things:

1. Set the PATH environment variable for the process. (I was already doing this.)

2. Set the ORACLE_HOME environment variable for the process. (I was not doing this.)

   Environment.SetEnvironmentVariable("PATH", Environment.CurrentDirectory + "\\oracle\\11.1\\odac;" + Environment.CurrentDirectory + "\\oracle\\11.1\\odac\\bin;", EnvironmentVariableTarget.Process);
   Environment.SetEnvironmentVariable("ORACLE_HOME", Environment.CurrentDirectory + "\\oracle\\11.1\\odac", EnvironmentVariableTarget.Process);
   

EDIT: It's also important to note that Oracle will throw this error not just for environmental issues, but also if one of the files is missing on the target machine. I got this same error on other machines despite the Environment settings because I had Subversion set to ignore directories called "bin", so the OraOps DLL was not being copied to the client.