Last post Aug 05, 2018 02:21 PM by Lannie
Aug 02, 2018 03:36 PM|Phyxious|LINK
We are moving our applications to server 2012 R2 which has Oracle Client 184.108.40.206.0 installed both 32bit and 64bit. One of the requirements for these servers is only .NET 4.5 and above are to be installed.
What I have done is removed the reference to Oracle.DataAccess.dll from the project, then re-added it pointing to C:\Windows\Microsoft.NET\assembly\GAC_64\Oracle.DataAccess\v4.0_220.127.116.11__89b483f429c47342 or C:\Windows\Microsoft.NET\assembly\GAC_32\Oracle.DataAccess\v4.0_18.104.22.168__89b483f429c47342
I then recompile and push the changes out to the server, but when trying to run get the error message Could not load file or assembly 'Oracle.DataAccess, Version=22.214.171.124'. Only way I can figure out how to get this to work is add the <runtime> section to
the web config, forcing it to use newVersion="126.96.36.199"
Why if I removed the reference of the old DLL and add a new reference pointing to the correct version causes this failure?
Aug 05, 2018 02:21 PM|Lannie|LINK
My habit is:
put the exact Oracle Data Access dll you want to use in the /BIN folder of the application and make a LOCAL reference to it.
That avoids many issues with GAC and GAC policies and VERSIONS.
Consider using Oracle MANAGED DRIVER with the Client built into the DLL. When properly set up with the DLL in the /BIN folder along with TNSNAMES.ORA it is way more tolerant of versions, bitness, and quite portable with the application. The only GOTCHA
I ran into is when the app server has FIPS140 ENABLED the managed driver will fail in Oracle 11g since Oracle 11g is not FIPS140 compliant. They state this was fixed in Oracle 12c and 18c.