runtime: Reference to type 'SqlConnection' claims it is defined in 'System.Data', but it could not be found.

dotnet --version: 2.1.4 uname -a: Linux firefixmaarten 4.15.3-300.fc27.x86_64 dotnet/corefx#1 SMP Tue Feb 13 17:02:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Also tested on windows 10:

<ItemGroup>
    <PackageReference Include="EnterpriseLibrary.WindowsAzure.TransientFaultHandling" Version="5.1.1212.0" />
    <PackageReference Include="log4net" Version="2.0.8" />
    <PackageReference Include="Lz4.Net" Version="1.0.98" />
    <PackageReference Include="MongoDB.Driver" Version="2.5.0" />
    <PackageReference Include="Newtonsoft.Json" Version="11.0.1" />
    <PackageReference Include="Newtonsoft.Json.Schema" Version="3.0.6" />
    <PackageReference Include="ServiceStack.Text" Version="5.0.2" />
    <PackageReference Include="System.Data.SqlClient" Version="4.4.2" />
    <PackageReference Include="WindowsAzure.ServiceBus" Version="4.1.7" />
    <PackageReference Include="WindowsAzure.Storage" Version="9.0.0" />
</ItemGroup>

Getting this error everywhere: Reference to type ‘SqlConnection’ claims it is defined in ‘System.Data’, but it could not be found [commonlib]

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 23 (13 by maintainers)

Most upvoted comments

I just ran into the same issue.

Steps to reproduce:

Create a new .NET 4.6.2 lib.
- Create a static method which returns a System.Data.SqlClient.SqlConnection.
Create a new .NET Standard 2.0 lib.
- Reference the .NET 4.6.2 lib.
- Call the method which returns the SqlConnection.
= Error is reported by VS (2017 15.7.6)

It does not help to install the “Microsoft.Windows.Compatibility” package to the .NET Standard lib. I have .NET Core SDK 2.1.302 installed.

KorsG on Aug 9, 2018

@firefixmaarten FWIW, I talked to @terrajobst about this issue and he re-explained to me the way an old library that was compiled against .NET Framework (where SqlConnection used to live in System.Data.dll), should still be able to work in .NET Core (where SqlConnection was moved somewhere else).

The solution is a compatibility shim, which is basically a version of System.Data.dll that contains type redirects to the new locations. It is actually expected that you have to install this compatibility shim in the application in order to make an old library like this work.

Currently the Microsoft.Windows.Compatilbity package comes with a compatibly shim for System.Data.dll. If you still want to use EnterpriseLibrary.WindowsAzure.TransientFaultHandling, you could try installing that package as a workaround. Although I understand that you probably already moved on.

@terrajobst I was able to find the System.Data compatibility shim in Microsoft.Windows.Compatiblity, but nothing in the System.Data.SqlClient package. Perhaps it is buried in some deep dependency but I wonder if this is a bug.

divega on Mar 1, 2018