.NET Standard library not working with .NET Framework

[LNA-DEV]

Describe the bug

If you are using the Microsoft.Data.SqlClient NuGet in a .NET Standard project which you are referencing in a .NET Framework project it throws the following exception.

Exception message: System.IO.FileNotFoundException: 'Die Datei oder Assembly "Microsoft.Data.SqlClient, Version=5.0.0.0, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.'
Stack trace:   at StandardLibary.SqlClientWrapper.MakeConnectionToLocalhost() in C:\Users\LNA\source\repos\SqlClient.FrameworkStandard.MRE\StandardLibary\SqlClientWrapper.cs:line 10
   at FrameworkProject.Program.Main(String[] args) in C:\Users\LNA\source\repos\SqlClient.FrameworkStandard.MRE\SqlClient.FrameworkStandard.MRE\Program.cs:line 12

I also noticed that if you take a closer look at the DLLs provided by the NuGet you can see that in the netstandard2.0 folder there only is a .NETCoreApp v8.0 DLL and not the required .NET Standard one.

Workaround

For me the only way to get the NuGet to work is using a older version (5.1.3). But since then there is the wrong version in the .NET Standard folder.

To reproduce

To reproduce this issue you can take a look at this MRE: https://github.com/LNA-DEV/SqlClient.FrameworkStandard.MRE

As you can see .NET works without any issues while .NET Framework throws an exception.

Expected behavior

If there is a .NET Standard version of a NuGet I suspect that it would work on .NET and .NET Framework.

Further technical details

Microsoft.Data.SqlClient version: 5.2.1
.NET target: v4.8
Operating system: Windows

[dauinsight]

Hi @LNA-DEV we'll look into this issue further.

Can I confirm again - Microsoft.Data.SqlClient 5.1.3 is the earliest working version? So 5.1.4 and beyond all encounter the same issue?

[LNA-DEV]

Hej @dauinsight I experimented a bit with the different versions.

Using the MRE it throws the same exception regardless of the version. But if I add <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to the csproj the error changes to platform not supported. (Maybe this is somehow related? dotnet/runtime#103662)

In our real code it behaves a bit different. I think this is because we run the dotnet publish --runtime win command which seems to fix the platform not supported issues. So if you build the StandardLibary project in my example, run the dotnet publish command and paste the files in the Framework project it works with version 5.1.3. All newer versions do not seem to work. (As I mentioned previously I think this is caused by the .NET Core DLL in the .NET Standard folder)

If I try to do the same process with a newer version I get the exception:

FileLoadException: Could not load file or assembly 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

with stack trace:

   at Microsoft.Data.SqlClient.SqlConnection..ctor()
   at Microsoft.Data.SqlClient.SqlConnection..ctor(String connectionString)
   at StandardLibary.SqlClientWrapper.MakeConnectionToLocalhost() in C:\Users\LNA\source\repos\SqlClient.FrameworkStandard.MRE\StandardLibary\SqlClientWrapper.cs:line 9

[LNA-DEV]

I double checked the versions and found out that I was wrong. Version 5.1.5 is the latest working one. Version 5.2.0 and 5.2.1 both have the same error.

[dauinsight]

Thanks for the details

If the latest failing version is 5.2.0: it sounds like this could be related to issue #2535. We are releasing 5.2.2 hotfix soon that will address this issue so stay tuned for that.

[JRahnama]

@LNA-DEV I would suggest going through this documentation first, have you tried having a multi target frameworks for your application instead of having two separate projects? I had a brief look at your repro and those two netcore and netframework are looking almost identical. Based on the documentation provided it is better to do so

[LNA-DEV]

@JRahnama It is a bit more complex in our real world implementation. I added the two projects mainly to show the difference between .NET and .NET Framework.

We are building a sort of plugin for our software which currently runs in Framework. But for the future we want to have the flexibility to change that and therefore want to use .NET Standard for the plugin. (Which only works in version 5.1.5 that's the issue)

Multi targeting might be something worth looking into in the future but I am not sure how well it works in our case, because we are doing a bit of manual DLL loading. However thanks for the suggestion. Could be a benefit for us👍

Nevertheless if I install a NuGet which has support for .NET Standard I expect it to work in both Framework and .NET. Which I think currently is not the case.

[JRahnama]

@LNA-DEV I tested below scenarios:

1. Added binding redirects: did not solve the issue
2. I tried adding M.D.SqlClient to startup application: did not solve the issue
3. Adding M.D.S.sni package: did not help also
4. Converted .NetFramework to SDK-style: application ran to completion. Basically below was my csproj

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\StandardLibary\StandardLibary.csproj" />
  </ItemGroup>

</Project>

[LNA-DEV]

@JRahnama I can confirm this workaround is working for the project I provided. (But I do not understand why. What is SDK-style changing?)

For our production application this does not work because we are publishing the .NET Standard project directly (with runtime win). But we are using v5.1.5 there until the NuGet is fixed.

[LNA-DEV]

FYI: Version 5.2.2 does not seem to solve this issue

Thanks for the details

If the latest failing version is 5.2.0: it sounds like this could be related to issue #2535. We are releasing 5.2.2 hotfix soon that will address this issue so stay tuned for that.