Geek Answers Handbook

How to deploy Oracle.DataAccess.dll correctly using an ASP.NET application

We had a problem with x64 / x86 when we first deployed Oracle.DataAccess.dll with our application on different servers with 64/32 bit Windows. Now that we have figured out how we can get the application to reference the correct version, I still have problems with the dll file that interferes with the deployment.

The situation is this: 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 application to use .dll from the GAC or another folder (it would be a 64-bit version instead of 32bit on the development machine). The DLL is not added to the bin output folder of the project, but is copied to the bin folder for the web application. 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 a DLL in the bin folder?

+4
source share
2 answers

Keep in mind that only dlls are used for reference. When the code actually calls the functions inside to connect to Oracle -.net uses the provider classes to get the use (interface) for the Oracle client from the oracle installation directory.

As they say - in our applications we just deploy the correct version in the bin folder based on the bit level of the OS. We must do this because our applications support Oracle and Sql - and the links will be broken into our Sql clients if the DLL was not there.

+2
source

One of the causes of this problem that we discovered is when your web project does not directly reference Oracle.DataAccess.dll, but refers to another project that refers to it. This happens even when Copy Local is false in the specified project.

The solution that seemed to work was to add the link directly to your web project, and then set the link Copy local to false.

0
source

More articles:


All Articles