Does ODP.NET require Oracle Client installation

Question

I have to connect Oracle 11g DB from .NET code. For that purpose I installed ODP.NET bur after reading some forum posts I recognized that I need Oracle Client installation too.

Is that true? I see that the Oracle Client has a size of ca. 2GB!!! Do I really need to install such a huge client only to be able to connect Oracle DBs?

Solution 1

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 client machine 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 OS and application smoothly. Easy to manage multiple versions on the same machine
• Can be deployed as a simple reference in the application bin directory.

So what's the catch?

• Not all features are supported (although most of them are... ) you can find out more on the documentation
• Namespace is changed from Oracle.DataAccess.Client to Oracle.ManagedDataAccess.Client
• Performance differences are still not clear. (The old) Native code always perform very efficiently, but on the other hand 100% managed code 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 Driver http://docs.oracle.com/html/E41125_02/intro004.htm

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

Solution 2

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 Driver https://www.nuget.org/packages/Oracle.ManagedDataAccess/

Or Package Manager Console

PM> Install-Package Oracle.ManagedDataAccess

Solution 3

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.dll
Oracle.DataAccess.dll (the managed ODP.NET assembly itself)
orannzsbb11.dll
oraociei11.dll
OraOps11w.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.

Solution 4

The latest ODAC releases ship with Oracle instant client so you don't need to install the full client.

(32 bit release)

(64 bit release)

Solution 5

I am leaving this answer because with the release ODP.net managed driver, old answers are a bit obsolete now.

ODP.net managed driver is released now.

• 64-bit Oracle Data Access Components (ODAC)

  Important: The 32-bit Oracle Developer Tools for Visual Studio download is required for Entity Framework design-time features. The downloads that support Entity Framework deployment below do not contain design-time tools, only run-time support.

• 32-bit Oracle Data Access Components (ODAC) with Oracle Developer Tools for Visual Studio

Currently available version ODAC 12cR2 is backwards compatible with Oracle 10gR2 or later. See the System Requirements section of ODAC 12cR2 Installation Instructions. ODAC 12cR2 requires/supports .Net frameworks from version 4 to 4.5.1.

Previous version ODAC 12cR1 too is backwards compatible with Oracle 10gR2 or later according to it's installation instructions.

View more solutions

Comments

[Kiquenet]

Alex Keh says: 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.

[Kiquenet]

Alex Keh says: "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. forums.oracle.com/thread/2559445"

[MensSana]

By the way, the client is no longer beta... Download both 32-bit and 64-bit here : oracle.com/technetwork/database/windows/downloads/… ODP.NET_Managed121012.zip

[Luminous]

So let me make this clear. The managed version allows you to reference the assembly in your app and allow you to NOT have the client machine download anything where as the un-managed version does? Right? Also here's a link saying what classes and methods are not supported in the managed version you may want to include in your answer: docs.oracle.com/html/E41125_02/intro004.htm)

[Jay Sullivan]

@Luminous: Right. With "Managed ODP.NET", you have a single 6MB dll, called Oracle.ManagedDataAccess.dll, that allows you to connect to an Oracle database without any other software installed. In fact, you don't even need to "install" Managed ODP.NET, you just need the dll, and you can safely deploy it to servers with no software installed.

[ThomasDC]

Remark: Oracle removed the odp.net.managed nuget as of october 2015. Use the official nuget Oracle.ManagedDataAccess instead. Also check this post.

[jpmc26]

Managed driver does not work with Oracle 11 and lower when running under FIPS mode, sadly.

[Nick.McDermaid]

This is the best answer to the "real" question, which is "how can I get Oracle connectvitiy in .Net without bloatware". Just FYI I've installed just this version into SSIS Azure runtime and can run Oracle SSIS packages.

[Wernfried Domscheit]

When I trace an ODP.NET application with Process Monitor then it loads 39 different DLL's from Oracle bin folder (not just these four you listed) - I don't think it is a smart way to copy the DLL's manually. Better install the InstantClient or the ODP.NET Managed driver.

[Branko Dimitrijevic]

@WernfriedDomscheit Managed ODP.NET is definitely a better option, but this answer was written before its time. As to these "extra" DLLs you noticed - again it's possible something changed in the meantime, or that you are just seeing "unnecessary" localization DLLs. Whatever it is, the answer describes a solution that was tested and worked quite well in practice, at that time.