What Changed
MSSqlConnectionProvider no longer uses SqlConnection and SqlCommand directly. The provider now determines the connection and command types at runtime and instantiates them via Reflection. Reflection first tries to load the connection and other types from the Microsoft.Data.SqlClient library, because this is the only way to seamlessly use the new and recommended SQL Server provider for .NET projects without any work from developers. If Microsoft.Data.SqlClient is unavailable, we fall back to the old System.Data.SqlClient library.
Reasons for Change
This change is necessary to support the new Microsoft.Data.SqlClient library.
Impact on Existing Apps and How to Revert to Previous Behavior
If you debug an app with Common Language Runtime (CLR) exceptions enabled, Visual Studio may stop at FileNotFoundException and TypeLoadException related to Microsoft.Data.SqlClient. These exceptions are correctly handled by XPO internally and should not prevent you from running an app. You can safely skip these exceptions while debugging, disable these CLR exceptions in the exception settings or run the app without debugging.
If you develop Xamarin apps for iOS or Android, you can experience the issue described in this article: XPO - Recommended Xamarin Linker Options.
If you want to revert to the previous application behavior, set the static MSSqlConnectionProvider.GlobalUseLegacySqlClient field to true.