How do I get an older version of OracleClient to work locally with .NET?
When I create a new .NET app with Oracle.DataAccess.dll, it works fine. However, I need to edit an existing web application with an older version of Oracle.DataAccess.dll installed, and when I try to run it locally, it throws our old friend, the "The provider is not compatible with the version of Oracle client" exception.
The existing version on the app is 18.104.22.168. I have two versions available; 22.214.171.124 and 126.96.36.199. (The apps I create that work use 188.8.131.52.) The "obvious" answer would be to use the 184.108.40.206 version in my app, but the app calls a DLL I can't change that also uses 220.127.116.11.
How do I get the app to connect to Oracle correctly without having to change the underlying DLL? Note that I am using 11gR2 and Visual Studio 2013.
Attributes like Version=... or processorArchitecture=... are not required. Your application will load the correct Oracle.DataAccess.dll depending on selected architecture and target .NET framework (provided that it is installed properly)
However, you refer to OracleClient.dll which is the deprecated Microsoft Data Provider (Oracle and ADO.NET) but then you write version 18.104.22.168 and 22.214.171.124 which is the Oracle Data Provider (ODP.NET, Oracle.DataAccess.dll). Somewhere you mix it up.
What is the target Framework version you selected? When you set 4.0 or 4.5 or 4.5.1 then it will try to load Oracle dll version 4.x. In order to use version 2.x you must set target framework 2.0, 3.0 or 3.5
If I were you I'd ditch the regular Oracle.DataAccess.dll and replace it with the managed driver. The problem with the pre-managed drivers that you were bound to the unmanaged dll's in the oracle client bin directory. i've build many a system that copied the specific dll's (~130 MB) into the application's bin directory to decouple the oracle install from my app. The other issue is that the unmanaged driver is 32/64bit specific. So things can also get messed up depending on where you deploy your application.
The managed driver fixes these issues and also shrinks the file size down to under 10mb. and you can manage the reference with NuGet.
Copy the Oracle.DataAccess.dll from the server (or out of the gac) and reference THAT dll in your project to compile. Leave specific version=true.
Then make sure you install the publisher policies that come with odp.net. I believe they are located at oraclehome\odp.net\PublisherPolicy. This will redirect bindings to the referenced server version to your newer version at runtime on your dev machine while still allowing it to work on the server.
First, it's important to note that the 2.x.x.x versions of ODP.net are for .net framework versions 2/3.5. The 4.x.x.x version is for .net 4.x.
So if you're compiling a 2.0/3.5 app, you need at least some version of the 2.x.x.x version.
I do second upgrading to the managed driver, but again, i think that is only an option for .net 4.x and that might be more of a change than you're willing to make.
When I used the unmanaged driver, this is what I did.
I always copy assemblies that I need to reference to the project itself and reference that file, even if the file is in the GAC. That way, the app can always be compiled regardless of what is installed on my machine.
I set the specific version setting on the reference to be true. I was never comfortable of the idea of executing code that may not have been deemed compatible by the manufacturer. It's always worried me that I'd get some strange and difficult to debug behavior.
Instead I relied on the publisher policies included in the odp.net install (I think they are placed at oraclehome\odp.net\PublisherPolicy). These allow requests for an assembly in the GAC to be redirected to a different version. You can see a screenshot of policies in the GAC on this answer:
I have an older app with this same issue. What I did is create a folder in my project (example) RefDLL. Then I put a copy of the older Oracle DLL in that folder, and reference that DLL in my VS Studio project for compiles. Then pushing out the code to the server (where to OLD DLL is in the GAC) the site works fine.
Asked in February 2016Viewed 2,919 timesVoted 13Answered 4 times