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.

[louislewis2]

@joperezr Sorry for the delay, I was on leave a bit. I have the binlog where can I send it too?

[joperezr]

you can attach it here so that I can take a look and see what is going on.

[louislewis2]

@joperezr done. Let me know if you need anything else.

msbuild.zip

[joperezr]

@louislewis2 Looks like the file you attached is from a successful build. In order to diagnose the issue, we need a binlog of a unsuccessful build with the issue so that we can see what is going on.

[louislewis2]

@joperezr I asure you it was the same outcome as this image, when I made the last one.

msbuild.zip

[joperezr]

Ok, so looks like the issue you are getting here is because I assume that Pastel.Evolution.dll must be targeting .NET Framework. Do note that this is not a supported scenario, even though it might work in some cases. .NET Standard assemblies can be consumed by .NET Framework, but that is not always true for the other way around. In this particular case, you require a System.Data shim that type-forwards SqlConnection to the System.Data.SqlClient.dll library. Our shim doesn't have this type-forward, as we decided that our shims would only type forward into netstandard.dll, and nothing else. Since this type is not in netstandard.dll, we don't have the forwarder. Given this is a not supported scenario, I wouldn't consider this a bug, but a by-design thing. That said, if you want to get this issue tracked and to further the discussion, you should open a bug on the http://github.com/dotnet/standard repo, which is where the fix would be.

[ogix]

@joperezr could you please provide some guide on how to make a System.Data shim? Do I need to build a custom System.Data assembly?

[joperezr]

Hello @ogix, we actually are the ones that build System.Data shim as part of our build here in the dotnet/runtime repo. That said, as I explained on the other comment, this System.Data shim will only contain type-forwards for types that are part of netstandard.dll, so you would need to have whichever type you are interested in to be includded in netstandard.dll so that we will emit the right type forward on our System.Data shim.

[ogix]

Understood. Thanks.

[joperezr]

@ogix Actually I just re-checked and it seems like with System.Data.dll shim we do it a bit special. Here what we do is that we will create a shim that will look for the .NET Framework 4.7.2 System.Data surface area, and create type-forwards to all of those types that also exist in .NET Core app and ignore all of the missing ones. That means that if the type you want the System.Data shim to forward to already exists in .NET Core App, then the shim should already have a type forward to it so if you are hitting any issues with this please let us know.