This content has been marked as final. Show 10 replies
Does your PATH statement have the x64 bit directories BEFORE the x32 bit directories?
Something like this: Path=C:\Oracle\ODAC112030x64;C:\Oracle\ODAC112030x64\bin;C:\Oracle\orabase\product\11.2.0\client_1;C:\Oracle\orabase\product\11.2.0\client_1\bin;C:\Windows\system32;C:\Windows;.....
Edited by: djonio on Dec 6, 2012 10:35 AM
No I do not see any 32 bit or 64 bit folders in PATH environment variable on my machine. I was able to uninstall the 32 bit installation. Now when I try to use the 64 bit installation as described in ReadMe: "install.bat all c:\oracle odac" all I get in another folder structure under "C:\oracle" but when I try to add Oracle.DataAccess.dll I still get the same error from my project build: "Processor architecture mismatch". I still don't have a clue what's going wrong, please help.
I would uninstall both ODACfor VS and the 64 bit Xcopy.
Make sure all of the Oracle directories are cleaned-up/deleted along with the registry entries.
Install ODACforVS. Test it and make that work first! (If memory servers my ODACforVS install placed the two directories in the PATH variable along with its registry entries)
Got that working? Ok...
Now do the x64Xcopy install.
example: install.bat all c:\Oracle\ODAC112030x64 ODAC112030x64
Change PATH variable to: PATH = c:\Oracle\ODAC112030x64;c:\Oracle\ODAC112030x64\bin;%PATH%
You should be good to go....
Well I figured it now, I has to use the 32 bit install setup to uninstall it as well... No ReadMe or uninstall tools provided for the 32 bit installation. Now when I try to use the DLL from the 64bit installation Visual Studio .NET gives me the following error:
"There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Oracle.DataAccess, Version=184.108.40.206, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=AMD64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project."
this made me think I was still pointed to the old one but the issue is really with my .NET project. If I target it specifically for 64 bit no issues, but when I point it to ANY CPU I get this error. Any idea on this?
Yes I think the install issues are over. I could have my dev machine as anything 32-bit or 64-bit but when I go to host my application I want it to run on any platform without thinking about the changes I need to make, recompile and deploy.
I could have this if I could add references to 2 dlls, 32-bit and 64-bit and the right one would take up the job depending on the machine architecture. However this is not possible, so I am looking for other ideas.
Sorry my installation issues have not gone away. As suggested in the ReadMe I selected the c:\oracle folder for installation and expected everything to go smoothly. Now I remember I add reference to my .NET project on the 32-bit machine, I find the Oracle.DataAccess listed among the other dlls in the .NET tab. For the 64-bit machine I do not see it listed there but I still see the dll in the GAC_64 folder. I don't know what's going on but I am sure .NET is not able to resolve the reference at runtime too.
Hence I am getting this error: "Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format."
It also says that the assembly had a partial bind and it could not find its version, culture and other such information. Please suggest what I can do to get it working as expected.
The error about loading with an incorrect format usually means there's a "bit-ness" issue. If you have the project building as AnyCPU (the default), in x64 it'll build as a 64 bit program, wihch means it needs a 64 bit Oracle.DataAccess.
Now, it sounds like you created it in 32 bit originally. If your reference was created with Copy Local = True in the reference settings, your program has an Oracle.DataAccess from that build in it's \bin folder, which is probably an x86 one. That isn't going to work properly, so you'll want to remove that and set Copy Local = False so it uses the GAC version instead.
A second potential issue is if you have the compile settings set to x86, it'll be building a 32 bit version even on x64 and you'll need the 32 bit Oracle client installed in order to use it.