TypeInitializationException in Mono starting in 3.2.16 with MS SQL Server

[arhughes]

Describe the bug
Starting in version 3.2.16, running any migrations on Mono against MS SQL Server fail with the error:

!!! The type initializer for 'Microsoft.Data.SqlClient.InOutOfProcHelper' threw an exception.
!!! +- GetModuleHandle assembly:<unknown assembly> type:<unknown type> member:(null)

This appears to be caused #1436, which moved to Microsoft.Data.SqlClient and apparently does not support Mono.

To Reproduce
Try to run any migration with a SqlServer provider under Mono. An example showing that Microsoft.Data.SqlClient is not supported under Mono is shown here: https://gist.github.com/arhughes/8b15d7ee88da250cc4492814cac6db52 and produces the same error with a full stack trace:

System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.InOutOfProcHelper' threw an exception. ---> System.EntryPointNotFoundException: GetModuleHandle assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) Microsoft.Data.Common.SafeNativeMethods.GetModuleHandle(string)
  at Microsoft.Data.SqlClient.InOutOfProcHelper..ctor () [0x00006] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.SqlClient.InOutOfProcHelper..cctor () [0x00000] in <c06d3e27a7d34019afc743cdbb48887b>:0
   --- End of inner exception stack trace ---
  at Microsoft.Data.SqlClient.SqlConnectionString..ctor (System.String connectionString) [0x0000d] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.SqlClient.SqlConnectionFactory.CreateConnectionOptions (System.String connectionString, Microsoft.Data.Common.DbConnectionOptions previous) [0x00000] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.ProviderBase.DbConnectionFactory.GetConnectionPoolGroup (Microsoft.Data.Common.DbConnectionPoolKey key, Microsoft.Data.ProviderBase.DbConnectionPoolGroupOptions poolOptions, Microsoft.Data.Common.DbConnectionOptions& userConnectionOptions) [0x0003e] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.SqlClient.SqlConnection.ConnectionString_Set (Microsoft.Data.Common.DbConnectionPoolKey key) [0x00008] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.SqlClient.SqlConnection.set_ConnectionString (System.String value) [0x000b1] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.SqlClient.SqlConnection..ctor (System.String connectionString, Microsoft.Data.SqlClient.SqlCredential credential) [0x00006] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at Microsoft.Data.SqlClient.SqlConnection..ctor (System.String connectionString) [0x00000] in <c06d3e27a7d34019afc743cdbb48887b>:0
  at (wrapper remoting-invoke-with-check) Microsoft.Data.SqlClient.SqlConnection..ctor(string)
  at Test.MainClass.Main (System.String[] args) [0x00002] in <14d249bf82924f15973816f6fb184b28>:0

Expected behavior
Migrations can be run with a SqlServer provider under Mono.

Information:

• OS: Docker Mono image
• Platform: Mono (at least versions 5.20, 6.6, and 6.12)
• FluentMigrator version: 3.2.16
• FluentMigrator runner: FluentMigrator.Console
• Database Management System: Microsoft SQL Server
• Database Management System Version: Seems like any, but tested against SQL Server 2017 (microsoft/mssql-server-linux:2017-latest)

Additional context
Add any other context about the problem here.

[jzabroski]

Thanks. It looks like our tests should cover Mono somehow. There was another report in #1486 of a similar issue with a different stack trace, but I'm not sure if they were using Mono.

[jzabroski]

Microsoft.Data.SqlClient 4.0.0 fixes this, but introduces another error, where only setting Encrypt=false avoids.

dotnet/SqlClient#1263 (comment)

[jzabroski]

The crux of the problem is using net461 (or legacy .NET Framework) with Mono on Linux.

[jzabroski]

@arhughes The maintainer of Microsoft.Data.SqlClient wrote back that Microsoft.Data.SqlClient netfx implementation relies on system calls unavailable on Linux. He suggested if you need to use SQL Server on Linux, you use System.Data.SqlClient (I believe, but am not positive, that is what he meant by saying "use the correct platform implementation assembly").

I suppose the short-term fix here would be to have a processorId mssql-linux. However, given .NET Framework is now a decade old technology, I'm not interested in spending the time to fix this. I'm open to taking PRs, but otherwise the complexity just doesn't interest me.

[jzabroski]

The latest update here comes from @lillo42 who troubleshot this awhile ago: dotnet/SqlClient#1263, in particular see: dotnet/SqlClient#1263 (comment)

The netfx implementation requires an unmanaged component to implement network connectivity. That implementaion is closed source non-portable and not provided for non-windows platforms. In the cases above people are restoring the netfx implementation and trying to use it on linux and that won't work. If you want to run the code on linux you need to use the correct platform implementation assembly.

However, if you search their repository, you will see as of last month that monoandroid still doesn't work correctly.

Referring back to my message two years ago, I think the right path forward is to add a special DI syntax to hook-in the older package (database driver library System.Data.SqlClient). @lillo42 Any thoughts? @arhughes You are free to add our own thoughts if you know any better, as well. I don't use mono so I am not an expert here.