tags:

views:

84

answers:

1

I have an native C++ app which needs to connect to an Oracle DB. Oracle data layers written in C#.Net so was hoping to reuse the code as a dll. I decided to try using managed C++ to bridge the gap between native C++ and C#. The managed C++ adaptor layer works fine (almost). The unmanaged C++ exe can invoke various classes and methods in the C# just fine.
Except for System.Data.OracleClient.OracleConnection which of course is the really important one.
When I call Open() on it EEMessageException is thrown. I am using Oracle 9 on Windows xp. My C# data object dll works fine when invoked from a C# exe. So I think it has some sort of issue with loading an assembly or an issue with the oracle driver into an native process hosting the CLR in a dll.

Here is the C# dll working fine in a normal C# app.
………………
'OracleTest.vshost.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'OracleTest.vshost.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\System.Transactions\2.0.0.0__b77a5c561934e089\System.Transactions.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'OracleTest.vshost.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\System.EnterpriseServices\2.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
………………

Here it is exploding in the native C++ app calling through an managed C++ layer

'QFeedTest.exe': Loaded 'C:\app\Oracle\bin\oci.dll', Binary was not built with debug information.
First-chance exception at 0x7c812afb in MyUnmanagedCPP.exe: Microsoft C++ exception: EEMessageException at memory location 0x0012d014..

Is there any project setting I can do to get the it load the Oracle driver correctly?

A: 

You can use the Fusion log viewer (fuslogvw.exe) to log what is happening when .Net tries to load an assembly. Another thing to do is to debug your application as managed code, rather than as native, you should then be able to see the actual managed exception and see what is going on. If that is not possible for some reason, you can use the debugging tools for windows and load the SOS extension - this allows you to more easily debug .Net code in WinDBG (you can also use SOS from within Visual Studio).

1800 INFORMATION