4

I want to deploy a client application that uses Oracle's ODP.net but I don't want to install ODP.net on every machine. Rather I'd like to copy the managed dll oracle.dataaccess.dll on every machine and have the native dlls on which it depends available, on a shared disk.

By decompiling the oracle.dataaccess.dll code I have seen that it calls a method that gets the location of the native dlls from the registry. So, in addition to copying the oracle.dataaccess.dll on every machine I would have to add the registry keys that would point to the native dlls on the shared disk.

My question: does one foresee any problem arising from that technique of odp.net deployment?

mnrtyrpt123
  • 143
  • 2
  • 10

3 Answers3

3

The only files you need from the latest client are: Oracle.DataAccess.dll oci.dll oraociicus11.dll OraOps11w.dll

Just make sure they get copied to the output directory and everything will work. Nothing needs to be registered anywhere. You will however need to make separate x86 and x64 builds with the respective architecture's DLLs since an Any CPU .NET application will run in 32-bit mode on a 32-bit OS and in 64-bit mode on a 64-bit OS.

Monstieur
  • 7,992
  • 10
  • 51
  • 77
1

1) ODP.NET is currently a mixture of managed and unmanaged DLL's. It also relies on lower level unmanaged DLLs from the Oracle client - eg for networking, etc.

2) You will need all these required ODP.NET and client DLLs on each machine you deploy to.

3) One potential solution to make this easier on you is to look into the "XCOPY" deployment package. See the ODP.NET download page. This is a smaller install and allows you to write your own custom installer. You can include these XCOPY files as part of your own install.

4) Oracle will be doing a beta of a fully managed provider in 2012 which will make this situation much better (and the total size will be a couple megabytes only).

Christian Shay

Oracle

Christian Shay
  • 2,570
  • 14
  • 24
0

Since they're unmanaged I'd assume that they'd be ok on a network path, though that should be easy enough to test. However I'd suggest that rather than changing the registry setting, you might be better off changing the DllPath config setting as described here.

Hans Olsson
  • 54,199
  • 15
  • 94
  • 116