Deploying web server that uses Oracle.DataAccess results in various assembly errors

Question

Deploying web server that uses Oracle.DataAccess results in various assembly errors

My development machine is Vista x64.

I am using WCF web services to build web services interfacing to an oracle 10g database.

When development started, I could not use VS2008's built-in WCF test tool [WCFTestClient] that launches when you press F5 [Go], on the 32-bit Oracle.DataAccess.dll, because I get System.BadImageFormatException on the Oracle object. So in my development environment I switched to the ODP.NET 64 bit version for my referenced assembly, and that works great.

I can deploy to my local IIS [7], but only if I use the 32bit Oracle.DataAccess.dll.

I am trying to deploy to a Win2003 [IIS 6] that has .NET 3.5 sp1 installed, and Oracle 10g database installed. Other web applications on this server successfully use oracle connections.

If I remove all references to Oracle.DataAccess from the web.config file , and make sure there is no Oracle.DataAccess.dll in my bin/ folder, I can bring up the default service metadata page[s], but calling the service via a SOAP client results in an error:

"Could not load file or assembly 'Oracle.DataAccess, Version=10.2.0.100, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified."

However, if I put a copy of Oracle.DataAccess.dll in my bin/ folder, I get:

"Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

when trying to load the .svc page in a web browser.

If I add an assembly reference to my web.config, I get a configuration error: "Could not load file or assembly xxx"

I guess I'm looking for help understanding the assembly cache, and someone who has experience with ODP.net who can help me navigate this treacherous territory and get this service successfully deployed.

.net

wcf

oracle

odp.net

asked on Stack Overflow Dec 10, 2009 by

user55904

3 Answers

Recently I experienced a similar issue and found that the System.BadImageFormatException was caused by referencing the 32 bit version of Oracle.DataAccess from a project that specified a target platform of Any/x64. After setting the project to target x86 and configuration IIS 7 to enable 32 bit applications (right-click on the Application Pool -> Advanced Settings... set "Enable 32-bit Applications" set to true) everything seems to be working as expected. Also, here is a link to an article explaining how to get both 32 and 64 bit versions running on different worker processes and another here explaining how to get 32 bit apps to run on 64 bit using IIS 6.

answered on Stack Overflow Jun 4, 2010 by

Brad • edited Mar 1, 2021 by

Glorfindel

Ok I've managed to [partially] resolve it, but I still need to know WHY this caused the error.

I installed ODP.NET 32 bit on my local machine, in a separate folder from the 64 bit installation. I changed the assembly reference in my VS project to the Oracle.DataAccess.dll located in odp.net/bin/2.x/ folder.

Now the SOAP message doesn't throw an error anymore.

The question now becomes: why is my choice of dll in my development environment driving the dll that must be used in the production environment? I want to be able to develop on 64 bit and deploy to a 32bit server without having to change my references every time i want to deploy.

answered on Stack Overflow Dec 10, 2009 by

user55904

My company's run into the same problem, and we've had to settle on using the 32bit dll for lack of a better solution.

From what we've been able to tell, Oracle's 64bit dlls are built exclusively for 64bit. Unlike a dll build with "Any", it doesn't include the 32bit object code as well. That would be fine, except for the additional problem that the 32bit dll seems to fail to load at all unless the project is built exclusively for 32bit.

We've tried dozens of iterations of 64/32bit dll and project settings, and we have been completely unable to get anything to work except 32bit dll/32bit project. In the end we had to move forward with the project and stop investing time into what seemed like a endless struggle.

My honest suggestion would be to evaluate alternative database solutions, if possible. My experience with Oracle has been very painful.

Otherwise, simply build in 32bit. It shouldn't cause any issues.

answered on Stack Overflow Jul 25, 2012 by

Chris Case

User contributions licensed under CC BY-SA 3.0