I've got a 3 Visual Studio solutions (ASP.Net and various console apps) that I need to migrate to 64-bit and to publish to a x64 Server. I need some advice on how to do that successfully.
The server and my dev machine (Windows 2008 and Windows 7 - both 64-bit) currently have a Universal Installer-based install of an 11g client with it's ODP.Net. Pretty sure these are 32-bit. To start my migration, my VS 2012 projects had references to the 32-bit Oracle.DataAccess DLL which was in a standalone file, so I poached the 64-bit file from the xcopy deployment of the 64-bit 11g client with ODP.Net (only to test the compile). Then I redid the project Oracle.DataAccess references to the 64-bit file and changed the project configs to build x64. Everything builds with no platform mismatch warnings.
But, of course, when I run, it can't load Oracle.DataAccess because I poached the Oracle.DataAccess.dll x64 from the xcopy zip of the Oracle client. I assumed my error was because I didn't have the native Oracle Client x64 installed and Oracle.DataAccess x64 needs it. Is that correct?
What is the best practice for adding x64 client when you already have a 32-bit laid down by OUI? I've searched out and found all sorts of different variations on doing this - with varying results. I'm really afraid of royally screwing up the boxes (which apparently is really easy to do) with multiple ORACLE_HOMEs. And the xcopy package for the 11g client explicitly says not to be used when you have an OUI install in place already, so can't use that.
Any advice would be appreciated.
Yes, you need the 64-bit Oracle Client DLLs. Oracle.DataAccess.dll represents just a small part of the binaries necessary to run ODP.NET for the unmanaged driver.
The best practice is to install 64-bit ODP.NET following the install instructions. To make sure each application can find its correct unamanged Oracle Client DLLs, I recommend setting the DllPath setting described in Chapter 2 of the ODP.NET Dev Guide. Typically, the problem people run into with multiple ODP.NET versions on the same machine is ensuring each ODP.NET version uses its correct Oracle Client version (i.e. avoiding DLL Hell). Setting DllPath is a straightforward to ensure all your ODP.NET apps will use the right dependent Oracle Client DLLs.
The xcopy package is not to be used *inside* an existing Oracle Home (from OUI), There is no problem with using the xcopy version *alongside* an Oracle Home if you use DllPath correctly.