0

I have the following in my web.config file

    <DbProviderFactories>
      <remove invariant ="Oracle.DataAccess.Client" />
      <add name="ODP.NET, Unmanaged Driver" 
          invariant="Oracle.DataAccess.Client" 
          description="Oracle Data Provider for .NET, Unmanaged Driver"   
          type="Oracle.DataAccess.Client.OracleClientFactory, 
          Oracle.DataAccess, Version=4.121.1.0, Culture=neutral, 
          PublicKeyToken=89b483f429c47342" />
    </DbProviderFactories>

My development machine is using OPD.net version 4.121.1.0 and I have added the reference to that file and specified that it should be copied locally. My deployment server has a much older client 10.2.0.100 and resides in D:\oracle\product\10.2.0\db_1\BIN. Because this application will be deployed to multiple server configurations, I don't want to have to manage each server's Oracle client. I thought that by adding

<remove invariant ="Oracle.DataAccess.Client" />

I would remove any conflicts with other versions except I'm getting...

The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception

After reading, it seems possible to be able to just use the above lines in my web.config and specify which version of ODP.net I want to use, but it isn't working for me. Is what I'm looking for possible, and is this the correct way of doing it?

Thank you. Any help is greatly appreciated.

Trebor
  • 793
  • 3
  • 11
  • 37

2 Answers2

1

I am not familiar with ODP.net or Oracle. I suppose that what you are referencing at the very end is a dll, or a bunch of dll files. The problem is that your code gets the reference from the wrong location and you want to specify it explicitly. I have done it before, with other dlls. This is usual situation when the dlls get imported in the GAC by a setup program and they are automatically found by visual studio.

You don't describe your Visual Studio solution structure but I suppose the problem is on your reference. If your reference is right, you don't have to override any web.config setting. I would have a structure like this:

solution folder
        ------> lib
        ------> project1
        ------> project2

where the lib folder would contain all my dlls not being in the .NET core. Then, I would delete and add all my project references to look at the specific folder dlls. This post could guide you with details on how to set references with explicit path (in my example the lib folder).

Hope I helped!

Pantelis Natsiavas
  • 5,293
  • 5
  • 21
  • 36
  • Pantelis, thank you. That's pretty much exactly what's happening. However, the DLL in question is placed into the /bin directory along with the executable calling it. I just tried your solution, but had the same result. Per the MSDN article, "If you use an assembly not located in the project directory you can specify its location in the Reference Paths". I just specified "bin" without any slashes. When I attempt to run the program it states "The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception" – Trebor Jan 15 '14 at 16:31
1

The "unmanaged" provider is made up of two parts: There's the managed driver- Oracle.DataAccess.dll and the unmanaged client (typically referred to as "Oracle Home"). While I'd guess there could be some mismatch, you're asking the 11g driver to talk to a 10g client and I don't think 10g even supported .net 4.0 (which is the driver you're loading). You may have no choice but to update your server if you want to use .net 4.0 and the unmanaged provider.

That said, if server dependencies are an issue, I would just use the managed provider. The unmanaged provider is a hodge-podge of managed .net assemblies sitting on top of decades old unmanged dlls (Oracle Client). The managed provider is the brand new, from scratch interface that finally abandons the old dependency on the client and truly lets you drop in just a couple of dlls and run.

Community
  • 1
  • 1
b_levitt
  • 7,059
  • 2
  • 41
  • 56
  • Thank you b_levitt. The video in the link was most helpful as well as your summary. I found that including the tnsnames.ora file in the bin directory was not sufficient though and that I needed to create a tnsnames.ora-less configuration instead. I.e. Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl)));User Id=oracle_user;Password=oracle_pwd;" as part of my connection string. I've tested on two different systems so far and both seem to work. – Trebor Jan 15 '14 at 18:51
  • 1
    Great that your moving. Interesting tidbit I just found on tnsnames: Note: The default ODAC GUI installer creates a TNS_ADMIN property in the machine.config file. This property will override usage of the tnsnames.ora file located in the application's working directory. Before continuing this OBE, we recommend you to comment out this property in the machine.config file. From: http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/appdev/dotnet/Web_version_Fully_Managed_ODPnet_OBE/odpnetmngdrv.html – b_levitt Jan 17 '14 at 04:09
  • As if Oracle wasn't complex enough, they had to add another obscure "feature". Thank you for the heads up. Fortunately, I was only using the Easy Client on my development machine which didn't require their GUI tools. – Trebor Jan 17 '14 at 20:40