views:

1315

answers:

2

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.

+2  A: 

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.

+3  A: 

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.

Brad