Could not load file or assembly error in .Net Standard 2.0 class library
Asked Answered
W

4

19

I have a .NET Standard 2.0 class library project with installed Nuget package System.Data.SqlClient version 4.4.0 and a Windows Form .NET Framework 4.7 project that has a reference to that class library.

Installing the Nuget Package and building the solution is successful. but in runtime every time that the code reaches a method that has any thing from SqlClient assembly inside it (for example an instance from SqlConnection) it gets this error:

Could not load file or assembly 'System.Data.SqlClient, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Considering this question, I assume the problem was also there in the last major version of the Nuget package.

Edit

I downloaded the Nuget package and unzipped it and from \ref\netstandard2.0 folder copied the System.DataSqlClient.dll manually in \bin\Debug folder of my Windows Form Project and now it works. The exact situation also happened with Microsoft.Win32.Registry package. So I was almost convinced that it's my fault and I'm doing something the wrong way, but when I tested it with System.Drawing.Primitive Package it worked perfectly without any need to copy a dll. Now I'm really confused.

Whig answered 17/8, 2017 at 15:53 Comment(0)
G
14

I guess you may have figured it out already but hope it would help someone - wasted some time too on this.

So, in order to make everything work you would need to reference System.Data.SqlClient in Windows Form project that is referencing your .NET Standard Library From that point everything should be working like a charm

As you already mentioned System.Data.SqlClient.dll was not in output directory. Sounds like .NET Standard Library haven't grabbed with itself dependent library binary. There is nothing like "Copy Local" option in .NET Standard references so I don't see any way to check or set this behavior too

Gynecium answered 2/9, 2017 at 16:23 Comment(3)
This pointed me in the right direction. I use nuget to install the package on the .NET app side and it fixed the issue.Pankey
Is there no way to get the project to manage the dependencies itself? Like if a .NET Standard project depends on x and a .NET Framework project depends on the .NET Standard project, then the .NET Framework project also depends o x and it will go install it?Kosaka
My question exactly @JamieTwells. DId you ever get an answer to this?Potpourri
S
5

I had the same problem. The .NETStandard assembly was added as a reference to my WPF project. I needed to make changes in the .csproj of the WPF project.

The solution mentioned in https://github.com/dotnet/sdk/issues/901 fixes it.

Steps:

  1. Edit your core .csproj file in notepad.
  2. Add the below two lines in each that you find in it.

    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    
  3. Clean and rebuild your solution.

Yes... I used Notepad.

Scowl answered 11/12, 2018 at 20:43 Comment(4)
Def to be avoided... add from NuGet package ... search for System.Data.SqlClient and add latest stable version.Fructiferous
@DanB, It's because the NuGet package method didn't fix the issue, that I looked to other solutions. And what is 'Def'?Scowl
"Def" in this case is "definitely", as in "definitely to be avoided".Clack
Why avoid this? Doesn't it keep the dependency versions correct? What if the version used in the .NET Standard project is not the latest?Facile
E
4

I had same problem.

Solution for me was adding dependecy from nuget for latest System.Data.SqlClient at my .NET Standard Library project.

Exclusion answered 25/4, 2018 at 12:47 Comment(1)
exactly, not all the libraries are included in default and you have to get them from NuGet. Very helpful response, really helped me.Unionism
C
0

I had a similar problem, bindingRedirect helped in my case:

<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0"/>
Cirrose answered 14/9, 2018 at 12:26 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.