How to change assembely reference to Oracle.DataAccess in prod

Question

Ok -
In development I installed "ODAC Entity Framework and LINQ Beta (11.2.0.2.30)" so that we could have a 32 bit version of Oracle.DataAccess for ODP.Net.
In Visual Studio 2010 (on Windows Server 2008 R2) I made a reference to:
C:\Oracle\odp.net\bin\4\Oracle.DataAccess.dll.
This adds:
<add assembly="Oracle.DataAccess, Version=4.112.2.30, Culture=neutral, PublicKeyToken=89B483F429C47342" />
to the assembly in the web.config.
We set the AppPool to Enable 32 bit applications and everything works great.
For anyone who doesn't know the story here, we do this because Visual Studio 2010 runs in 32 bit so you need the 32 bit ODAC/ODP.net components to get a development environment running.
I then publish the files and move to a 64 bit machine.
I downloaded the "ODAC112021Xcopy_x64.zip"
Then ran:
install.bat odp.net4 c:\oracle odac and I can see the Oracle.DataAccess.dll file at:
C:\Oracle\odp.net\bin\4\Oracle.DataAccess.dll.
Then added c:\oracle;c:\oracle\bin\;c:\oracle\bin\4 to the System Path.
At this point I would think I just replace the version and PulbicKeyToken in:
<add assembly="Oracle.DataAccess, Version=4.112.2.30, Culture=neutral, PublicKeyToken=89B483F429C47342" />
on production to the versioin installed on prod.
So first thing I do is just remove that line on production to see what error I will get.
And I still get the same error:
System.IO.FileLoadException: Could not load file or assembly 'Oracle.DataAccess, Version=4.112.2.30, 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)
Actually this is if I move the new dll into the applicaitons bin directory.
If I remove the dll from the directory I get:
Could not load file or assembly 'Oracle.DataAccess, Version=4.112.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified.
So I put the line back in.
I right click on on the new Oracle.DataAccess.dll and click properties.
In the details tab I see verion is 4.112.2.0.
That makes sense. The 64 bit XCopy version is an earlier build then the 32 bit Beta that comes with Entity Framework and LINQ(Version=4.112.2.30).
So on production I change the Version attribute to: 4.112.2.0.
But now I get the same error:
System.IO.FileLoadException: Could not load file or assembly 'Oracle.DataAccess, Version=4.112.2.30, 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)
(This is with the new dll back in the web app's bin directory as is the rest of the thread).
It's still looking for the same version of the assembly. Why is it doing that?
The web.config has a connection string with the ODP.Net provider type (Oracle.DataAccess.Client).
Which would take from the assembly reference.
It should not care what the version number is.
Could there be something in code somewhere that is specifically looking for the old dev box version?
Just what is the way to make it use the new assembly?
I would think the system would just know where to find the new dll.
Just as in development the add reference dialog knew that the dll was in c:\oracle\... rather then c:\program files(x86)... like out-of-the-box Microsoft assemblies. Because the system knows, right?
Edited by: 842453 on Mar 7, 2011 1:17 PM

Answer 1

Hi,
The .NET runtime will always attempt to load the exact version of the ODP assembly that the application was compiled with unless you have some sort of binding redirection in place. We do provide forward redirection in the way of publisher policy files but we do not provide backward redirect, you would have to add this binding redirect to your app.config file. We generally do not recommend you redirect to use an older version although I dotn see any real reason why it shudl not work as long as you are not using any 4.112.3.0 specific features. Loading the assembly that the application was compiled with is a security thing and is the way it works.
The only thing you are doing by adding that reference to the configuration file for 4.112.2.0 is to have that preloaded by the runtime, your application is still compiled with 4.112.3.0 and expects to find that exact version unless you tell it otherwise because we only provide forward redirection when ODP gets installed.
HTH
Jenny