18

I am trying to port my database application from .NET Core 3.1 to .NET Core 5.0.

When running the following code,

        public async Task<List<T>> LoadDataFromSQL<T, U>(string sql, U parameters, string connectionStringName)
        {
            using (IDbConnection connection = new OracleConnection(await GetConnectionString()))
            {
                var rows = await connection.QueryAsync<T>(sql,
                                                          parameters,
                                                          commandType: CommandType.Text);
                return rows.ToList();
            }
        } 

I get this exception:

"System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.\r\n ---> System.TypeInitializationException: The type initializer for 'OracleInternal.ServiceObjects.OracleConnectionImpl' threw an exception.\r\n ---> System.TypeInitializationException: The type initializer for 'Oracle.ManagedDataAccess.Types.TimeStamp' threw an exception.\r\n ---> System.NotSupportedException: BinaryFormatter serialization and deserialization are disabled within this application. See https://aka.ms/binaryformatter for more information.\r\n at OracleInternal.Common.OracleTimeZone.GetInstance()\r\n at Oracle.ManagedDataAccess.Types.TimeStamp..cctor()\r\n --- End of inner exception stack trace ---\r\n at Oracle.ManagedDataAccess.Types.TimeStamp.InitializelatestTZversion()\r\n at OracleInternal.ServiceObjects.OracleConnectionImpl..cctor()\r\n --- End of inner exception stack trace ---\r\n at OracleInternal.ServiceObjects.OracleConnectionImpl..ctor()\r\n --- End of inner except ion stack trace ---\r\n"

Is is possible to work around this from my application?

I am using the latest version of Oracle.ManagedDataAccess.Core 2.19.91, release on 10/22/2020. Also, I am using Dapper 2.0.35.

Wernfried Domscheit
  • 54,457
  • 9
  • 76
  • 110
Jason D
  • 1,863
  • 2
  • 16
  • 30
  • 2
    If you check the link in the error message you'll see that `The BinaryFormatter type is dangerous and is not recommended for data processing.`. Oracle shouldn't be using it at all. Obsoleting and removing that type was a target since .NET Core 1.0 [and the .NET team started disabling it in .NET 5.0](https://github.com/dotnet/designs/pull/141). You'll have to wait for Oracle to fix the vulnerability in its client. Or find a better one. ODP has always been rather fat, slow and very quirky when it comes eg to locales and codepages – Panagiotis Kanavos Nov 11 '20 at 17:02
  • There's a 19.10 update that should fix it https://medium.com/@alex.keh/announcing-odp-net-19-10-release-new-net-5-and-bulk-copy-support-be6f395155c9 – wast Nov 17 '20 at 09:44
  • 3
    Problem still the same 2.19.100 and .net 5, but works with .net Core 3.1 – stephone Nov 17 '20 at 11:43

2 Answers2

38

I discovered that Oracle is working on a fix for this which should be available soon.

In the meantime, in case anyone runs into this issue there is a workaround.

In your project file, you can add the XML statement to EnableUnsafeBinaryFormatterSerialization.

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization>
  </PropertyGroup>
Jason D
  • 1,863
  • 2
  • 16
  • 30
  • 2
    Thank you very much but it caused another exception of {"The type initializer for 'OracleInternal.Network.AddressResolution' threw an exception."} Innerexception is {"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.":"System.DirectoryServices.Protocols, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"}. Adding System.DirectoryServices.Protocols v5.0.0 resolved the issue. – Yongkee Cho Nov 12 '20 at 22:00
  • 2
    First of all, thanks Jason. @Yongkee: You just have to install via Nuget System.DirectoryServices.Protocols. – Alex Nov 18 '20 at 23:51
1

Installing Oracle.ManagedDataAccess.Core 3.21 fixes the issue completely so no need in unsafe binary serialization.

Vitaly Leskiv
  • 363
  • 3
  • 11