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

[firefixmaarten]

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]

[firefixmaarten]

The extra's in EnterpriseLibrary.WindowsAzure.TransientFaultHandling does not seem to play nice with sqlclient:
for example:
sqlConnection.OpenWithRetry(DataBaseHandler.GetInstance().RetryPolicy);
Removing them fixes the issue, but how can I make sure the retryPolicy is used everytime?

[divega]

System.Data Triage: The Enterprise Library Transient Failure Handling Application Block targets .NET Framework. All the types from System.Data.Common and System.Data.SqlClient in .NET Core live in the System.Data.dll assembly in .NET Framework.

From the title, this could be more of a System.Data.SqlClient issue (the type SqlConnection is defined there) but even that area seems inappropriate as this could be a general issue with how unification works. Hence clearing up the area.

[joshfree]

@joperezr could you take a quick look?

[firefixmaarten]

I found the used library to be very old and deprecated. You can also define retries on the sqlconnection itself. I'm doing this now. No need to put resources in an old, not dotnet standard discontinued library. Thanks anyway.

[divega]

@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.

[louislewis2]

I recently faced the same issue. I installed the shim package and found the same thing that @divega found.
Any news as to when this might be fixed?

[joshfree]

@louislewis2 just to confirm, you installed https://www.nuget.org/packages/Microsoft.Windows.Compatibility 2.0.0 and still had the same SqlClient issue?

[louislewis2]

My reference is defined as

PackageReference Include="Microsoft.Windows.Compatibility" Version="2.0.0"

[KorsG]

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.

[joperezr]

@KorsG not saying that this is the cause of the issue, but just as FYI referencing a .NET 4.6.2 lib from a .NET Standard 2.0 lib is not technically supported. It might work in some cases but it is not a supported scenario. The supported scenario is when you do the other way around: You write a .NET 4.6.2 lib and reference a .NET Standard 2.0 lib.

[joperezr]

@louislewis2 could you please produce a binlog file and send it over so that we can investigate what is going on with your project? (sorry for the late reply)

In order to generate a binlog, simply build your project from a developer command prompt like: msbuild yourproject.csproj /t:rebuild /bl

[karelz]

@joperezr the issue was incorrectly in 2.1.0 milestone.
Is it actionable now? Or should we close it due to not enough information?

[joperezr]

I guess for now we can close it given that there is not enough info to investigate, and people can feel free to reopen in case they have a repro or more detailed logs of the failure.