Does ODP.NET require Oracle Client installation Does ODP.NET require Oracle Client installation oracle oracle

Does ODP.NET require Oracle Client installation


Alex Keh from Oracle in aug 2013 says:

Managed ODP.NET is released. It is currently part of the Oracle DB 12c client. To use managed ODP.NET, you have to download and install the DB client. From there, you can extract just the managed ODP.NET assembly and setup files. These files are less than 10 MB and can be deployed to any target machines.

Currently, we are packaging a stand alone managed ODP.NET release and ODAC 12 release that will be much smaller. This will be released on OTN shortly.

If you can wait a couple of days, ODAC 12c will be out on OTN and you can download that version. That will be our latest and greatest managed ODP.NET version

====

We do not plan to put managed ODP.NET on NuGet. We believe that the managed ODP.NET download with ODAC will provide the same benefits of NuGet in terms of assembly isolation and download size.

There's a thread discussing whether Oracle should provide managed ODP.NET NuGet support. Once you use ODAC 12c, I would like to know your thoughts on whether NuGet support is still necessary. https://forums.oracle.com/thread/2559445

Nuget managed ODP.NET:

PM> Install-Package Oracle.ManagedDataAccess

So what is the problem anyway?
Basically up until now, ODP.NET was a .NET layer that talks to the Oracle client .dll files, a small fact that had many implications:

  • Large installation footprint (several hundreds of Mb)
  • Tough deployment to remote machines - needs to install ODP.NET on clientmachine or deploy large files
  • Challenging when working with several versions, 32bit/64bit os and applications

So what is it?

The managed driver is basically a single .dll file with a .Net native implementation of ODP.NET.
That means no Oracle Client is needed, and now native code is behind the scenes. XCopy installation can be done easily.

Major benefits:

  • Small footprint
  • Compiled as any cpu so it can work on 32bit/64bit OSand application smoothly. Easy to manage multiple versions on thesame machine
  • Can be deployed as a simple reference in the applicationbin directory.

So what's the catch?

  • Not all features are supported (although most of them are... ) youcan find out more on the documentation
  • Namespace is changed fromOracle.DataAccess.Client to Oracle.ManagedDataAccess.Client
  • Performance differences are still not clear. (The old) Native codealways perform very efficiently, but on the other hand 100% managedcode has it's performance benefits.

Please note that the Native-Code ODP.NET is still very much available. The managed version (at least for now) comes in addition to the native one.

References: http://oracleatdotnet.blogspot.com.es/2013/07/odpnet-managed-driver-beta-2.html

Differences between the ODP.NET Managed Driver and Unmanaged Driverhttp://docs.oracle.com/html/E41125_02/intro004.htm

Features of Oracle Data Provider for .NEThttp://docs.oracle.com/database/121/ODPNT/features.htm#ODPNT0007


you can get managed ODP.NET using NuGet too https://www.nuget.org/packages/odp.net.managed/

PM> Install-Package odp.net.managed 

Watch the quick start video on using ODP.NET Managed Driver! (copied from http://www.oracle.com/technetwork/topics/dotnet/whatsnew/index.html)

http://www.youtube.com/watch?feature=player_embedded&v=I1q50HnUh_w


Update:

NuGet for Official Oracle ODP.NET, Managed Driverhttps://www.nuget.org/packages/Oracle.ManagedDataAccess/

Or Package Manager Console

PM> Install-Package Oracle.ManagedDataAccess


The ODP.NET does require native OCI DLLs (~130 MB).

Probably the easiest way to get all the necessary files is to download the "Oracle Data Access Components with XCopy deployment" from oracle.com.

For your reference, the following DLLs are used by ODP.NET at run-time:

oci.dllOracle.DataAccess.dll (the managed ODP.NET assembly itself)orannzsbb11.dlloraociei11.dllOraOps11w.dll

BTW, you'll need to be careful whether you are using 32-bit or 64-bit native Oracle DLLs - you must match them with the "bitness" of your managed code. This is especially tricky if you are building for "Any CPU" so the bitness is not fixed.