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