How to correctly deploy Oracle.DataAccess.dll with ASP.NET app

We had some x64 / x86 trouble when we first deployed the Oracle.DataAccess.dll with our app on different servers with 64/32 bit Windows. Now that we figured out how we can get the app to reference the correct version, I still have trouble with a .dll file that is getting in the way during deployment.

Situation is as follows: I have one project in my solution that references Oracle.DataAccess. I set the "copy local" proper开发者_JAVA技巧ty to False, because on the server, I would like the app to use the .dll from the GAC or another folder (which would be the 64bit version instead of 32bit on development machine). The dll is not added to the project bin output folder, but it is copied to the web-app bin folder. When I deploy to our test-server, it uses the dll from the bin folder instead of the dll from the Oracle installation folder on the server (i.e. c:\oracle\odp.net\bin\4)

What can I do to NOT have the dll in the bin folder?

Keep in mind it only uses the dll for the reference. When the code actually calls the functions inside to connect to Oracle - .net uses the provider classes to get the usage (interface) for the Oracle client from the oracle installation directory.

That being said - in our applications - we just deploy the correct version in the bin folder based on the bit level of the OS. We have to do this since our apps support both Oracle and Sql - and the references would break for our Sql clients if the dll was not there.

One cause of this problem that we have found is when your web project does not directly reference Oracle.DataAccess.dll, but does reference another project that references it. This happens even when Copy Local is false on the referenced project.

The solution we found to work is to add the reference directly to your web project, and then set its reference to Copy Local to false.