SqlClient: Microsoft.SqlServer.Server conflicts between S.D.SqlClient and M.D.SqlClient

As soon as I reference this package from a 2.2 project with a reference to “Microsoft.AspNetCore.App” I get the following error:

CS0433	The type 'SqlDataRecord' exists in both 'Microsoft.Data.SqlClient, Version=1.0.19128.1, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5' and 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Repro:

Create a new project
Reference both the Microsoft.AspNetCore.App package and the Microsoft.Data.SqlClient package
Use a type from the package

using Microsoft.SqlServer.Server;

namespace ConsoleApp44
{
    class Program
    {
        static void Main(string[] args)
        {
            var sqlDataRecord = new SqlDataRecord();
        }
    }
}

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Data.SqlClient" Version="1.0.19128.1-Preview" />
    <PackageReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

</Project>

It apparently works on .NET Core 3.0 with FrameworkReference, atleast I don’t get any error

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Data.SqlClient" Version="1.0.19128.1-Preview" />
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

</Project>

dotnet --info .NET Core SDK (gemäß "global.json"): Version: 3.0.100-preview4-010643 Commit: 88e7cb2515

Laufzeitumgebung: OS Name: Windows OS Version: 10.0.17134 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\3.0.100-preview4-010643\

Host (useful for support): Version: 3.0.0-preview4-27506-14 Commit: 98641ad643

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 28 (25 by maintainers)

Commits related to this issue

Merged PR 1353: Update namespace for Microsoft.SqlServer.Server to Microsoft.Data.SqlClient.Server This PR updates the namespace for Microsoft.SqlServer.Server to Microsoft.Data.SqlClient.Server. Thi... — committed to JRahnama/SqlClient by AfsanehR-zz 5 years ago

Most upvoted comments

If anyone ends up here needing a temporary work around, here’s one that worked for me.

Background for my use case: I have a project that needs to use SqlDataRecord and tries to do so via referencing package Microsoft.Data.SqlClient. It appears to be gettings its conflict via some kind of transitive dependency within Microsoft.NETCore.Platforms (3.0.0 preview). I’m using an extern alias to alias the Microsoft.Data.SqlClient copy of the conflicting namespace.

In my .csproj:

  <Target Name="ResolveNamespaceConflict" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
    <ItemGroup>
      <ReferencePath Condition="'%(FileName)' == 'Microsoft.Data.SqlClient'">
        <Aliases>MDSqlClient</Aliases>
      </ReferencePath>
    </ItemGroup>
  </Target>

In my .cs file in this project:

extern alias MDSqlClient;
using MDSqlClient::Microsoft.SqlServer.Server;

[...snip...]

	IEnumerable<SqlDataRecord> Entities { get; set; }

DannyMeister on Jun 17, 2019

@David-Engel question, though: there are scenarios where those types are useful today; if you remove them from the public API in M.D, will they work with S.D? Example: the TVP scenario mentioned above. I don’t know how often SqlMetaData is used (not one I’m very familiar with). If they don’t work, there may be an API gap. If they do work inwards, you’d presumably need to use reflection. And I’m not sure they could ever work outwards reliably.

Follow up question: is there no imaginative alternative namespace that could be used instead, even if slightly ugly?

mgravell on May 10, 2019

It seems like the best approach will be to bring the M.S.S classes forward into M.D.SqlClient under a new namespace.

I’m not crazy about dumping them straight into M.D.SqlClient. How about Microsoft.Data.SqlClient.Server?

This will allow applications to not depend on S.D.SqlClient for those classes. This also means M.S.S.SqlDataRecord will not be compatible with M.D.SqlClient.SqlParameter, which we believe should be fine. Applications need their entire stack to use SqlDataRecord with M.D.SqlClient, just like everything else in M.D.SqlClient (zero object interchangeability between S.D.SqlClient).

David-Engel on May 14, 2019

@divega being pragmatic and respecting assembly conventions, perhaps simply: Microsoft.Data.SqlClient.Something.SqlDataRecord etc? Where Something could also just be nothing, i.e. move them to the SqlClient namespace?

mgravell on May 11, 2019

Yeah, I tried to do a repro without the normal SqlClient package to make it more realistic. As for my use case: Table-Valued-Parameters together with Dapper, so from that namespace, I use SqlDataRecord and SqlMetadata.

Tornhoof on May 9, 2019