Error: No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient'

Question

I recently upgraded/updated Entity Framework in an old project from version 4 or 5 to version 6. Now I get this exception:

An exception of type \'Syst

Answer 1

I just solved it. You need to install Entity Framework again in your solution. Follow any of the approaches.

First = Right Click your Solution or Project root and click Manage NuGet Packages. Select 'EntityFramework', select the appropriate Projects and click Ok.

or

Second = Go to Console Package Manager and run Install-Package EntityFramework.

Hope it helps.

Answer 2

Hendry's answer is 100% correct. I had the same problem with my application, where there is repository project dealing with database with use of methods encapsulating EF db context operation. Other projects use this repository, and I don't want to reference EF in those projects. Somehow I don't feel it's proper, I need EF only in repository project. Anyway, copying EntityFramework.SqlServer.dll to other project output directory solves the problem. To avoid problems, when you forget to copy this dll, you can change repository build directory. Go to repository project's properties, select Build tab, and in output section you can set output directory to other project's build directory. Sure, it's just workaround. Maybe the hack, mentioned in some placec, is better:

var instance = System.Data.Entity.SqlServer.SqlProviderServices.Instance;

Still, for development purposes it is enough. Later, when preparing install or publish, you can add this file to package.

I'm quite new to EF. Is there any better method to solve this issue? I don't like "hack" - it makes me feel that there is something that is "not secure".

Answer 3

Ok, this is pretty weird. I have a couple of projects: one is a UI project (an ASP.NET MVC project) and the others are projects for stuff like repositories. The repositories project had a reference to EF, but the UI project didn't (because it didn't need one, it just needed to reference the other projects). After I installed EF for the UI project as well, everything started working. This is why, it added this piece of code to my Web.config:

<entityFramework>
  <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  <providers>
    <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
  </providers>
</entityFramework>

Answer 4

Try adding the following runtime assembly bindings:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Answer 5

This issue could be because of wrong entity framework reference or sometimes the Class name not matching the entity name in database. Make sure the Table name matches with class name.

Answer 6

I had this problem in a situation where I have a model project that has the references to both EntityFramework and the .SqlServer assemblies, and a separate UI project that uses ASP.NET MVC. I wanted to upgrade from EF 4.1 to 6.1. I actually had to do part of what was described here: http://robsneuron.blogspot.com/2013/11/entity-framework-upgrade-to-6.html. I want to emphasize that I did not add a reference to these projects to my UI project nor did I add the configuration to the UI project's web.config, as those steps would violate my separation of concerns.

What I did do was in my model project, I had to flip the "Copy Local" reference settings for EntityFramework.SqlServer (and the EntityFramework reference, to be safe) to "False" and save all, to get the project to put the <Private> node into the .csproj file, and then set it back to "True" and save again, so that True ends up as the final value.

I also had to add the hack line to my DbContext-derived class in its constructor to force the use of the assembly, even though the line does nothing. Both of these steps I learned from the blog post.

public MyContext : DbContext
{
    public MyContext() : base("name=MyContext")
    {
        // the terrible hack
        var ensureDLLIsCopied = 
                System.Data.Entity.SqlServer.SqlProviderServices.Instance;   
    }

I want to thank the author of that blog that I referenced, as well as all the people that asked and answered the questions on SO, to try to help us get past this terrible bug.