How to install ODP.NET 2.111 and ODP.NET 4.112 in the same machine side-by-side while both point to the same database server

Question

The question is how to install ODP.NET 2.111 and ODP.NET 4.112 in the same machine side-by-side while both point to the same database server using tnsnames.ora

I need to support a legacy system based on Oracle 11.1.0. The system is using ODP.NET 2.111 to connect to oracle. There are two clients installed at:

C:\oracle\product\11.1.0\client_1

C:\oracle\product\11.1.0\client_2

The tnsnames.ora for both is something like this:

xxxx1_SERVICE=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = xxxx2)(PORT = xxx3))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = xxx4)
    )
  )

yyyy1_SERVICE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = yyyy2 )(PORT = yyyy3))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = yyyy4)
    )
  )

kkkk1_SERVICE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = kkkkk2 )(PORT = kkkk3))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = kkk4)
    )
  )

pppp1_SERVICE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ppppp2 )(PORT = pppp3))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = pppp4)
    )
  )

oooo1_SERVICE = (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ooooo2 )(PORT = oooo3))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = oooo4)
    )
  )

The system is up and running using the above settings. I need to develop a new system based on EntityFramework which requires me to use a newer version of Oracle.DataAccess.Dll (4.112).

I was wondering that how I could install the new client without hurting the functionality of the legacy system so both can work side by side:

Note: I did try to install the new ODP.NET over the previous client and was able to connect to database using the following connection string:

DATA SOURCE=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=zzzzz1)(PORT=zzzzz2)))(CONNECT_DATA=(SERVICE_NAME=zzz3_SERVICE)));User ID=\"zzzz4\";Password=\"zzzz5\";

Thats is not desirable because 1- It breaks the legacy system because it no longer can connect to Oracle due to the upgrade in ODP.NET 2- The connection string is very strange looking

I would appreciate any help,

Thanks, Aidin

Answer 1

The short answer:

Note: I did try to install the new ODP.NET over the previous client and was able to connect to database using the following connection string...

This indicates that your new install does not have a tnsnames.ora and sqlnet.ora in /Network/Admin. If you're OK with the old client using the new ODP.net install, than you can either copy them from the old installation or you can specify a global location for all instances with the TNS_ADMIN environment variable, ie TNS_ADMIN=C:\MyOracleFilesDir

The long answer:

When you installed the new client it most likely also installed publisher policy files into the GAC that redirect references to the old Oracle.DataAccess.dll to the new version during the assembly resolution process. Oracle.DataAccess then locates the client via a parameter (DllPath) in the registry. You can override this location by setting the dllPath in your .config file:

<configuration>
  <oracle.dataaccess.client>
    <add key="DllPath"            value="C:\yourotherpath"/>
  </oracle.dataaccess.client>
</configuration>

This is generally what I do, but as I understand this more, I realize that I'm forcing a newer dll against an older client. If your goal is to leave the old client untouched, a better option may be to delete the publisher policies from the GAC (I don't think they are even installed with the full ODAC install, only ODP.net):

If you need to reinstall them they are generally found at oraclepath\odp.net\PublisherPolicy.

Another, and maybe a better long term option, is to configure the old clients to ignore the publisher policy: http://msdn.microsoft.com/en-us/library/cf9025zt%28v=vs.80%29.aspx

Finally, I'm pretty sure the .net components for the 2.0 vs. 4.0 frameworks are separate install options during the ODP.net installation. I think you might be able to avoid this issue simply by not installing the 2.0 components. On that note you could do a similar work around by developing your new project against the 64 bit odp.net instead. Like v2.0 and v4.0, 32 bit and 64 bit also do not have any awareness of each other.