Issue upgrading to Oracle.ManagedDataAccess.Core 2.19.100

[george-tifrea]

Hi,
I upgraded the Oracle.ManagedDataAccess.Core package from 2.19.70 to 2.19.100 in my AspNet Core application (.NET Core 3.1) and I encounter this issue:

Error Message:
System.TypeInitializationException : The type initializer for 'OracleInternal.Network.AddressResolution' threw an exception.
---- System.IO.FileNotFoundException : Could not load file or assembly 'System.DirectoryServices.Protocols, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
Stack Trace:
at OracleInternal.ConnectionPool.PoolManager3.CreateNewPR(Int32 reqCount, Boolean bForPoolPopulation, ConnectionString csWithDiffOrNewPwd, OracleConnection connRefForCriteria, String instanceName, List1 switchFailedInstNames)
at OracleInternal.ConnectionPool.OracleConnectionDispenser3.Get(ConnectionString cs, PM conPM, ConnectionString pmCS, SecureString securedPassword, SecureString securedProxyPassword, OracleConnection connRefForCriteria) at OracleInternal.ConnectionPool.PoolManager3.Get(ConnectionString csWithDiffOrNewPwd, Boolean bGetForApp, OracleConnection connRefForCriteria, String affinityInstanceName, Boolean bForceMatch)
at OracleInternal.ConnectionPool.OraclePoolManager.Get(ConnectionString csWithNewPassword, Boolean bGetForApp, OracleConnection connRefForCriteria, String affinityInstanceName, Boolean bForceMatch)
at Oracle.ManagedDataAccess.Client.OracleConnection.Open()
at OracleInternal.ConnectionPool.OracleConnectionDispenser`3.Get(ConnectionString cs, PM conPM, ConnectionString pmCS, SecureString securedPassword, SecureString securedProxyPassword, OracleConnection connRefForCriteria)
at Oracle.ManagedDataAccess.Client.OracleConnection.Open()
at Oracle.ManagedDataAccess.Client.OracleConnection.Open()
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
...
----- Inner Stack Trace -----
at OracleInternal.Network.LDAP..ctor()
at OracleInternal.Network.AddressResolution..cctor()

From what I've seen on Nuget it doesn't have System.DirectoryServices.Protocols as a dependency, however, when inspecting the DLL, it looks like the package has references to System.DirectoryServices.Protocols:

[alexkeh]

Check your sqlnet.ora NAMES.DIRECTORY_PATH setting. It may look something like this:
NAMES.DIRECTORY_PATH : (LDAP, TNSNAMES, EZCONNECT)

If you are not using LDAP, then remove LDAP. That will eliminate ODP.NET trying to use System.DirectoryServices.Protocols to resolve the LDAP configuration. I've seen this occur with another customer.

If you are using LDAP, then add the System.DirectoryServices.Protocols NuGet package to your project.

[nicoleta-scrimint]

Hi!
Installing manually the System.DirectoryServices.Protocols NuGet package seems like a workaround for fixing this issue. I think a NuGet package should install all its dependencies and use them when it is needed on runtime.

Is it possible that the Oracle team to add the System.DirectoryServices.Protocols NuGet package as a dependency on the Oracle.ManagedDataAccess.Core package which can be seen as a top level NuGet package? Thus, in NuGet Package Manager in Visual Studio, the installation of the top level NuGet package will trigger the installation of the System.DirectoryServices.Protocols NuGet package dependency.

At this moment, Oracle.ManagedDataAccess.Core package appears to not have any dependency on the NuGet website:

It would be nice that this dependency System.DirectoryServices.Protocols to be shown in NuGet website so that developers to be aware of all the package dependencies, like for this NuGet package:

[alexkeh]

Only applications that use LDAP need System.DirectoryServices.Protocols. Not all ODP.NET apps use LDAP. That is why it is not a required dependency.

In a similar vein, ODP.NET apps that use performance counters must include System.Diagnostics.PerformanceCounter. Or an ODP.NET app that uses public key cryptography must add System.Security.Cryptography.Pkcs. To make the entire universe of packages that ODP.NET could possibly need required would force all users to add to their deployment download sizes.

From a general security standpoint, app attack surface area is limited by not including unused packages from software deployments. With the growing popularity of containerization, this trend has accelerated with assembly trimming increasing in use.

[nicoleta-scrimint]

Hi,

In order to know what dependency package to install and not to find it based on trial and error, could you please point to an official Oracle documentation which states what dependency nuget packages to install based on the needed functionality, e.g. LDAP?

Thank you!

[alexkeh]

@nicoleta-scrimint

We currently document the dependency based on the subject matter. For example, in the LDAP section of the ODP.NET doc, we indicate the need for System.DirectoryServices.Protocols.

https://docs.oracle.com/en/database/oracle/oracle-data-access-components/19.3.2/odpnt/featConnecting.html#GUID-48612E90-A2BB-4766-880A-097721E564F8

However, that's a good suggestion if we document the optional packages all in one place to make it easier to determine which additional packages are needed based on functionality. Let me discuss with my team. If they are in favor, I will add this as a new section to our ODP.NET doc in Chapter 2.

Thanks for the suggestion!

[hiezust]

Hi,

Would it be a good idea to have a separate nuget package for the LDAP functionality in the ODP.NET Core? If an application would have a need for LDAP, it would use that particular nuget package.

Thank you

[alexkeh]

@hiezust It's an idea, though I don't believe any other ADO.NET data provider does this, not even Microsoft's own providers.

How Microsoft decides to break up the .NET Runtime into separate packages does not have hard and fast rules. It could change from release to release based on what MS views as the most commonly used packages.

[XtremeOwnageDotCom]

I'd argue this issue was not properly resolved.