Bug: network path resolving for .NET Core drivers is broken

Yves_D

Hello,

As I didn't find an official way to report a bug in the Oracle Data Provider for .NET Core, I will try through this forum.

We are using the TNS_ADMIN environment variable on our development systems and let it point to a share \\share\oracle . When trying to connect to a database, we are getting the famous "Unable to resolve ORA-12154: TNS:could not resolve the connect identifier specified". Turning on tracing, we discovered that the driver is looking for the tnsnames.ora in c:\share\oracle .

Decompiling the driver and checking the code learned us that at some point in the OracleInternal.Common.ConfigBaseClass.GetResolvedFileLocation the path stored in the TNS_ADMIN is split in its different parts based on the directory separator, thereby ignoring empty entries. Later on, in OracleInternal.Common.ConfigBaseClass.ResolveEnvVariables the entire thing is reassembled again, but of course incorrectly since information was lost during the path split.

So, in our case \\share\oracle became ['share', 'oracle'] which became 'share\oracle' and thus resolved to c:\share\oracle . And of course, that path didn't exist.

Alex Keh-Oracle

After some investigation, there is a bug whenever a metacharacter is used in a network share. This bug causes the directory to resolve to the local c:\ driver, rather than the original network share.  I've filed bug 29956349 to track this issue.

In the meantime, if you remove the metacharacter and use the full network share path in TnsAdmin (or add another call that resolves the network share path before providing it to TnsAdmin), then you can avoid this bug.

Alex Keh-Oracle

ODP.NET Core does not support the TNS_ADMIN environment variable. It supports the following:

1. Directory set in OracleConfiguration.TnsAdmin property
2. Directory of the running ODP.NET Core assembly
3. Current working directory
   

OracleConnection.TnsAdmin will be added to this list in the first ODAC 19c release, which should come out in about a month.

This info is documented here:

https://docs.oracle.com/en/database/oracle/oracle-database/19/odpnt/InstallCoreConfiguration.html#GUID-24C963AE-F20B-44B…

As a general principle, environment variables are rare for .NET Core. The model is configuration as code. That is why the TNS_ADMIN environment variable is not supported in ODP.NET Core.

With that said, much of the ODP.NET Core code does derive from managed ODP.NET. There are some managed ODP.NET artifacts you will see in ODP.NET Core, such as what you found.

Yves_D

The TNS_ADMIN environment variable is not the issue. You can reproduce the exact same buggy behavior with the OracleConfiguration.TnsAdmin property.

Example source code:

using System; using Oracle.ManagedDataAccess.Client;  namespace OracleTest {     class Program     {         static void Main(string[] args)         {             // Set tracing options specifically.             OracleConfiguration.TraceOption = 1;             OracleConfiguration.TraceFileLocation = @C:\temp;                         OracleConfiguration.TraceLevel = 7;              // Point tns admin to share.             OracleConfiguration.TnsAdmin = @\\db-trfd\tns_admin$;               using (var connection = new OracleConnection("Data Source=xxxx;User ID=xxxx;Password=xxxx"))             {                 using (var command = connection.CreateCommand())                 {                     connection.Open();                      command.CommandText = "select 1 from dual";                      var reader = command.ExecuteReader();                     while (reader.Read())                     {                         Console.WriteLine(reader.GetInt32(0));                     }                     reader.Dispose();                 }             }          }     } }

Tracing:

2019-06-24 11:07:50.101542 TID:1   (CFG) (ENV)      OS Version : Microsoft Windows NT 6.1.7601 Service Pack 1

2019-06-24 11:07:50.102542 TID:1   (CFG) (ENV)      64-bit OS : True

2019-06-24 11:07:50.102542 TID:1   (CFG) (ENV)      64-bit Process : True

2019-06-24 11:07:50.102542 TID:1   (CFG) (ENV)      .NET Core Runtime Version : 2.2.2

2019-06-24 11:07:50.102542 TID:1   (CFG) (ENV)      Application Directory : C:\Users\xxxx\Source\Repos\OracleTest\bin\Debug\netcoreapp2.2

2019-06-24 11:07:50.102542 TID:1   (CFG) (VER)      Oracle Data Provider for .NET Core Driver Version : 2.0.19.1

2019-06-24 11:07:50.108542 TID:1   (CFG) (VER)      Oracle Data Provider for .NET Core Driver Informational Version : 2.0.19.1:20190510

2019-06-24 11:07:50.108542 TID:1   (CFG) (.NET)     Resolved Trace File Location: C:\temp

2019-06-24 11:07:50.160542 TID:1   (PUB) (OCFG) OracleConfiguration.TraceFileLocation() : C:\temp

2019-06-24 11:07:50.161542 TID:1   (PUB) (OCFG) OracleConfiguration.TraceLevel() : 268435463

2019-06-24 11:07:50.161542 TID:1   (PUB) (OCFG) OracleConfiguration.TraceOption() : 1

2019-06-24 11:07:50.162542 TID:1   (PUB) (OCFG) OracleConfiguration.CommandTimeout() : 0

2019-06-24 11:07:50.162542 TID:1   (PUB) (OCFG) OracleConfiguration.DbNotificationPort() : -1

2019-06-24 11:07:50.162542 TID:1   (PUB) (OCFG) OracleConfiguration.DbNotificationAddress() :

2019-06-24 11:07:50.163542 TID:1   (PUB) (OCFG) OracleConfiguration.BindByName() : False

2019-06-24 11:07:50.163542 TID:1   (PUB) (OCFG) OracleConfiguration.FetchSize() : 131072

2019-06-24 11:07:50.163542 TID:1   (PUB) (OCFG) OracleConfiguration.MaxStatementCacheSize() : -1

2019-06-24 11:07:50.164542 TID:1   (PUB) (OCFG) OracleConfiguration.SelfTuning() : True

2019-06-24 11:07:50.164542 TID:1   (PUB) (OCFG) OracleConfiguration.StatementCacheSize() : 0

2019-06-24 11:07:50.165542 TID:1   (PUB) (OCFG) OracleConfiguration.TnsAdmin() : \\db-trfd\tns_admin$

2019-06-24 11:07:50.165542 TID:1   (PUB) (OCFG) OracleConfiguration.ServiceRelocationConnectionTimeout() : 90

2019-06-24 11:07:50.166542 TID:1   (PUB) (OCFG) OracleConfiguration.HAEvents() : True

2019-06-24 11:07:50.166542 TID:1   (PUB) (OCFG) OracleConfiguration.LoadBalancing() : True

2019-06-24 11:07:50.167542 TID:1   (PUB) (OCFG) OracleConfiguration.DrcpConnectionClass() :

2019-06-24 11:07:50.167542 TID:1   (PUB) (OCFG) OracleConfiguration.DatabaseEditionName() :

2019-06-24 11:07:50.167542 TID:1   (PUB) (OCFG) OracleConfiguration.OnsConfigFile() :

2019-06-24 11:07:50.168542 TID:1   (PUB) (OCFG) OracleConfiguration.OnsMode() : Unspecified

2019-06-24 11:07:50.168542 TID:1   (PUB) (OCFG) OracleConfiguration.OnsProtocol() :

2019-06-24 11:07:50.169542 TID:1   (PUB) (OCFG) OracleConfiguration.OnsWalletLocation() :

2019-06-24 11:07:50.185542 TID:1   (PUB) (ENT) OracleConnection.Open() (conid=32854180) (state=Closed) (sessid=0) (implid=0) (pooling=T) (txnid=n/a)

2019-06-24 11:07:50.222542 TID:1   (PRI) (ENT) (CP) OracleConnectionDispenser..cctor()

2019-06-24 11:07:50.223542 TID:1   (PRI) (EXT) (CP) OracleConnectionDispenser..cctor()

2019-06-24 11:07:50.223542 TID:1   (PRI) (ENT) (CP) OracleConnectionDispenser.Get()

2019-06-24 11:07:50.229542 TID:1   (PRI) (ENT) (CP) PoolManager.ctor()

2019-06-24 11:07:50.230542 TID:1   (PRI) (EXT) (CP) PoolManager.ctor()

2019-06-24 11:07:50.236542 TID:1   (PRI) (ENT) (CP) PoolManager.Initialize() (constr=Data Source=xxxx;User ID=xxxx;)

2019-06-24 11:07:50.275542 TID:1   (CFG) (SQLNET)   FilePath : (null)

2019-06-24 11:07:50.275542 TID:1   (CFG) (TNSNAMES) FilePath : (null)

2019-06-24 11:07:50.354542 TID:1   (NET) (ENT) EZConnect.ResolveSimple()

File monitor output:

You cleary see in the file monitor output that it tries to look for the sqlnet.ora end tnsnames.ora on my local drive and not on the network share that was specified. Changing the value of the  OracleConfiguration.TnsAdmin property to a local file works as advertised.

User_XSI6X

You might want to read this thread: oledb providor for oracle, tnsnames, and tns_admin

The last post might also be the issue you have, sysinternal's procmon should help find out whats going on.

You could also try if '\\?\c:\temp' works, that way you atleast have a hint about wether UNC paths actually work or not.

Alex Keh-Oracle

After some investigation, there is a bug whenever a metacharacter is used in a network share. This bug causes the directory to resolve to the local c:\ driver, rather than the original network share.  I've filed bug 29956349 to track this issue.

In the meantime, if you remove the metacharacter and use the full network share path in TnsAdmin (or add another call that resolves the network share path before providing it to TnsAdmin), then you can avoid this bug.

Adelson_Smania

Hi Alex,

When I try to see the status of the bug 29956349 in Oracle support center, I am  receiving the following message:

Requested Bug could not be displayed. Possible reasons are:

• The bug id was entered incorrectly. Please check and try again.
• The bug id does not exist (was referenced incorrectly).
• The bug is not classified as publicly accessible ("non-public").
• The content is being updated and it is temporarily unavailable but will be made available again soon.

What is the current status of this bug?

Thanks

Alex Keh-Oracle

The bug has been fixed, but the fix missed the cutoff to make the 19.5 patch. It will likely be in the 19.6 patch.

I have published the bug for your future reference.

If you need the fix ASAP, you can request a one-off with justification why it's urgent. The typical patch process puts the fix through a more rigorous testing process. A one-off has more limited testing, but gets the patch into the hands of a customer quicker.

Adelson_Smania

Thanks for your reply Alex.

Is there a planned date for 19.6 patch?

Best regards

Alex Keh-Oracle

19.6 on Windows looks like it's scheduled to be released around mid-January.