Problem with Oracle.ManagedDataAccess dll versions on Windows Server 2012

Question

I have an issue with connecting my .NET web service to Oracle 19c database. My web service works with Oracle 11. After upgrading the database to Oracle 19c we needed to update the Oracle.ManagedDataAccess and Oracle.ManagedDataAccess.EntityFramework versions to match the database version. The project target framework is .NET 4.5. The service is working locally, but when I install it on Windows Server 2012 I get the following error:

Server error: System.IO.FileLoadException: Could not load file or assembly 'Oracle.ManagedDataAccess.EntityFramework, Version=6.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The Web.config

  <configSections>
    <section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
  </configSections>

<providers>
  <provider invariantName="Oracle.ManagedDataAccess.Client" type="Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices, Oracle.ManagedDataAccess.EntityFramework, Version=6.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" /> </providers>

Whenever I change the Version to 6.122.1.0 the error calls for 6.121.2.0. And to my surprise when I change to the previusly requested version 6.121.2.0. it requires 6.122.1.0 again. So I feel I am going round in circles...

I have no idea where the dll version is taken from, I checked the application "/bin" folder, Web.config and the machine.config on the server.

Answer 1

According Client / Server Interoperability Support Matrix for Different Oracle Versions you can connect to an Oracle 19c database with a Oracle 11.2 client:

Regarding your main question: "I have no idea where the dll version is taken from", there are two answers.

• Simplified answer: The application loads the DLL from GAC (Global Assembly Cache). If the DLL is not found there, then it searches the folder of the currently running binary. This answer should be sufficient in 90% of all cases.

• Complete answer: Have a look at How the Runtime Locates Assemblies, it is a bit longer than just two sentences.