Repository navigation
Type load fails - cannot locate 'Microsoft.SqlServer.Server.SqlDataRecord' #9
Description
Describe the bug
Upon replacing System.Data.SqlClient with the latest preview of Microsoft.Data.SqlClient (version 1.0.19128.1-Preview) I get the following type load exception upon starting my .NET Framework 4.7 application;
ReflectionTypeLoadException
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
LoaderExceptions (3x the same)
Could not load type 'Microsoft.SqlServer.Server.SqlDataRecord' from assembly 'Microsoft.Data.SqlClient, Version=1.0.19128.1, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5'.
Stack Track
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.Assembly.GetTypes()
I've verified that Microsoft.Data.SqlClient.dll is present in the output folder of the build (and System.Data.SqlClient.dll is not present). I've run a dotnet clean and dotnet restore to try and fix it to no avail.
To reproduce
Upgrade a .NET framework 4.7 application using System.Data.SqlClient to Microsoft.Data.SqlClient and run it
Expected behavior
It would run successfully
Further technical details
Microsoft.Data.SqlClient version: 1.0.19128.1-Preview
.NET target: net47
SQL Server version: not relevant to issue (not getting far enough to try connecting)
Operating system: Windows 10
Activity
ErikEJ commentedon May 13, 2019
Duplicate of #4 ?
danpaul88 commentedon May 13, 2019
Potentially, this is a desktop application but it has some asp net core dependencies for a signalr client and a few other client side operations. Doesn't use aspnetcore.app though
Also I've verified that system.data.sqlclient does not appear in the output folder nor the dependency tree in visual studio - and the exception doesn't indicate a conflict, simply a failure to load
danpaul88 commentedon May 13, 2019
OK - I've done some digging and noticed that, at the point of the exception, it's trying to populate the catalog for a
System.ComponentModel.Hosting.AssemblyCatalogLooking in the object browser shows that
Microsoft.Data.SqlClientlibrary doesn't actually contain a class calledSqlDataReader(looks like its inSystem.Datainstead), so quite why the composition service has decided to look in theMicrosoft.Data.SqlClientlibrary for that type I'm not sure...danpaul88 commentedon May 13, 2019
Aha - I think I've figured it out
So, when you compile a library in netstandard2 and reference
Microsoft.Data.Server.SqlClientyou get an instance ofSqlDataRecordfrom;But when you use that same type in a net framework 4.7 application you instead get an instance of
SqlDataRecordfrom;So when you have an intermediate netstandard2 project library consuming
Microsoft.Data.SqlClientand using theMicrosoft.SqlServer.Server.SqlDataRecordand then a net47 library (or application) consuming both that library and, in turn,Microsoft.Data.SqlClient, they disagree over which library to look in for the implementation ofMicrosoft.SqlServer.Server.SqlDataRecordIt's even more obvious when you take composition out of the loop since it generates a compiler error;
I've attached a ZIP file with a repro of the above compiler error for your consideration
MsDataSqlClient_Issue9Repo.zip
David-Engel commentedon May 13, 2019
This is very related to #4. You are just seeing a different aspect of the issue. On the Framework side of M.D.SqlClient, the Microsoft.SqlServer.Server classes are not exposed publicly. You will need to keep a reference to System.Data.SqlClient to use them. The outcome of #4 will determine if you need to keep a reference to S.D.SqlClient for those classes long-term, or if they will be made available under a different namespace.
danpaul88 commentedon May 13, 2019
I did wonder if that was the case once I'd figured out the root cause.
The problem therein is that any net standard intermediate library (such as a NuGet package which happens to use M.D.SqlClient but not S.D.SqlClient) is incompatible with any net framework library or application trying to consume it since the intermediate library is compiled to expect the types which don't exist on the net framework side of the fence. This breaks the expectation that a net framework library or application can consume net standard libraries equal or lower than the version of net standard that the net framework version corresponds to.
I'll keep an eye on #4 to see what the resolution is - in the meantime I'll mark this as closed (feel free to reopen if you'd rather keep it alive to track this aspect of the issue :) )
Address PR #4336 review feedback (pipeline version computation)