4

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" property 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?

Niels Ziegler
  • 466
  • 2
  • 6
  • 15

2 Answers2

2

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.

tsells
  • 2,751
  • 1
  • 18
  • 20
  • 1
    It's not only for reference, when the dll is in the bin folder after deployment, it uses this 32bit dll and crashes. What I need to do is to always delete the file after web-publishing. I don't understand why it gets copied there in the first place. – Niels Ziegler Aug 25 '11 at 11:50
  • It is used for reference. All required dependencies are output to the bin folder by default unless you specify otherwise. This is under the reference's --> properties Copy Local property. Set this to false to keep it from being copied out during the build. – tsells Aug 25 '11 at 16:58
  • Remember that when assemblies are compiled (first launched, ngen, etc) that it attempts to build all relationships when converting the code to IL. – tsells Aug 25 '11 at 16:58
1

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.

Chris R. Donnelly
  • 3,086
  • 3
  • 28
  • 28