Having two ODP.NET (ODAC) versions in the same server

Question

Some months ago, a colleague of mine installed ODAC 11.106.21 in a server using XCOPY and then he developed many applications that use this client without problems (in test and production windows servers).

Past week, I developed an application under ODAC 11.1.07.20. When I asked him to install these new ODAC version using XCOPY in a different folder and then include my application in the test server, he answered me that I should use ODAC 11.106.21 because he could have troubles with his applications.

So I would like to know:

1) If it is really possible to have two different ODAC versions in one server.

2) If the answer is positive, how can I firmly ensure to my colleague that he will not have troubles with his applications?

3) If the answer is positive, is this necessary to do some kind of configuration in the server?

Thanks!!

Answer 1

You can have multiple versions of ODAC on the same machine, but there are several things to be aware of with regards to which version will be used by each application. This actually applies to all assemblies.

• in Visual Studio, if you set Specific Version = True on Oracle.DataAccess.dll, then that application will not use any other version and must be able to find the version it was built against.
• whether you deploy the DLL with your application or expect it to be in a certain place or in the GAC.
• there is a specific search order for finding dependent DLLs, and it's quite involved, so read this MSDN topic.

The short answer is that there are two easy ways to make sure your application uses the exact version of Oracle.DataAccess.dll you want it to (this applies in most cases where everything else is default):

1. Set Specific Version to True;
2. Deploy the DLL with your application and have it reside in the application directory, OR ensure that the DLL is in the GAC.

In your specific case, your colleague may have a valid concern: If his applications which are currently installed are getting Oracle.DataAccess.dll from the GAC, and he didn't set Specific Version to True, then when you install the new ODAC, his applications will start using it (I'm assuming the new Oracle.DataAccess.dll will be installed in the GAC too),

Answer 2

The problem here is not .NET dlls but unmanaged dlls.

I trying to make to work two ASP.NET applications on one server. One is older using ODP.NET 9.x and the new one using the latest ODP.NET. I deployed the newest ODP.NET using xcopy and added the paths to PATH environment variable for the new ODP. Now the old application doesn't work (probably tries to use new dlls). When I remove paths from PATH variable then the new app doesn't work. I found the way to make it work on one server unders IIS on Oracle pages but that didn't work. Maybe because I didn't install newest ODP.NET but just xcopied it. I will have to try it.

What Oracle says about: Link: http://www.oracle.com/technology/tech/windows/odpnet/faq.html Many Oracle applications run on Microsoft Internet Information Services (IIS). Previously, IIS was a single process application without the ability to assign a different System Path to each running web application using the same IIS instance. With IIS 6 on Windows Server 2003, IIS supports multiple processes for the same instance. Since each application has its own IIS process, each web application can be assigned a different System Path directory with its own Oracle Home.

Microsoft documentation provides information on IIS worker process isolation and application pools.

To set up multiple active Oracle Homes running concurrently on the same IIS server: 1) Run IIS 6 in worker process isolation mode on Windows Server 2003 2) Deploy one version of the Oracle Client to one application pool and the second version to another application pool. For example, you can have Oracle Client 9.2.0.2 and ODP.NET 9.2.0.2 be used by one application pool. And Oracle Client 9.2.0.4 and ODP.NET 9.2.0.4 can be employed by another application pool. You won't be able to use two active Oracle Homes in the same application pool. Each active Oracle Home must be in a different pool. 3) Set the DLL directory for each worker process to use the appropriate Oracle Home client directory. To do this, within each ASP.NET application, call SetDllDirectory(directory_name) early in the application lifecycle before any Oracle DLLs are called. The SetDllDirectory input variable is the Oracle Home bin directory of the ODP.NET version used. Note: SetDllDirectory is an unmanaged call.