Reference to System.Data.SqlClient causes breakage on .NET 8 #84
Description
When testing with .NET 8 RC2, I found that some code broke with this exception:
---- System.Reflection.ReflectionTypeLoadException : Unable to load one or more of the requested types.
Could not load type 'SqlGuidCaster' from assembly 'System.Data.SqlClient, Version=4.6.1.5, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.
This is a known issue in SqlClient, raised in Feb 23 at dotnet/SqlClient#1930
SqlClient have fixed the issue in their PR#1934 (this specific commit) and the fix is available in Microsoft.Data.SqlClient v5.2.0-preview3 or greater.
There is no current fix for the older System.Data.SqlClient. I'm guessing this is because it appears to have been superseded by Microsoft.Data.SqlClient
This is relevant for Conventional because conventional pulls in System.Data.SqlClient and can trigger the error in codebases that don't use any of the Sql functionality.
Logically, if codebases aren't using the Sql functionality then they shouldn't cause an assembly load on SqlClient, however this codebase happened to be doing reflection-based assembly scanning which caused the assembly load. Unfortunately we're not able to stop the assembly scanning as it is done by another third party library (in this case, Nuke)
Beware upgrading the SqlClient reference:
Right now, if conventional changes to reference Microsoft.Data.SqlClient , the latest release is 5.1 which is broken on .NET 8. It needs a preview of 5.2 which isn't ready yet.
If conventional references this, it may cause people to unknowingly pull the assembly into their test suites, which may break when they go to .NET 8.
They'll need to edit their csproj's and add an explicit reference to 5.2 to force an upgrade.
If they're using the Database stuff this seems fair and reasonable (They'll already have their own SqlClient references that they can change), but if someone isn't using the Database parts of Conventional, then needing to manually bump an invisible SqlClient version seems like a pretty indirect and non-obvious fix.
It may be a good idea to wait until a non-preview version 5.2 of Microsoft.Data.SqlClient is available before moving forward with this, and consider any other effects that may have (e.g. older .NET version compatibility)