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

Fixing error “No Entity Framework provider found for the ADO.NET provider with invariant name ‘System.Data.SqlClient'”

This post was most recently updated on April 28th, 2019.

Reading Time: 3 minutes.

This post describes the fix to error “No Entity Framework provider found for the ADO.NET provider with invariant name ‘System.Data.SqlClient’“, which Visual Studio throws at your face when you try to run an application on any Windows-based system (or which you’ve dug out of event logs). Also, your application is probably built on .NET Framework and Entity Framework.

Let’s get into it!

Error

Table of Contents

When debugging/running your code, somewhere in your code where you’re supposed to access the database using Entity Framework, you get an error like this:

An exception of type 'System.InvalidOperationException' occurred in EntityFramework.dll but was not handled in user code

Additional information: No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient'. Make sure the provider is registered in the 'entityFramework' section of the application config file. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.

The running of the program is stopped there, and removing and re-adding the nuget packages and/or other references to DLLs does not help. I, at least, tried also making all kinds of changes to my web.config and ran iisreset a couple of times, but nothing seemed to help. There’s a simple fix available, though!

Solution

First of all, you will want to verify that you do in fact have the provider configured in your application/web config file.

"System.Data.SqlClient" in web.config providers for Entity Framework
“System.Data.SqlClient” in web.config providers for Entity Framework

Now that the obvious case is taken care of, let’s jump to the weird ones!

You might be a victim of a pretty well-known and long-existing feature of msbuild. In a lot of cases, it might forget to copy your EntityFramework.dll to your output folder. To avoid this, there’s a couple of things you need to make sure of:

You need to make sure that EntityFramework package is included in the project where you get this error. It doesn’t matter whether you use it there or not, running your application requires it, and MSBuild usually fails to copy it unless you (1) have a reference to the package and (2) force all of the DLLs to be copied.

The first part is easy. Run this for the project you’re debugging (if you don’t have the package already):

Install-Package EntityFramework -ProjectName [YourStartupProject]

Next, you’ll need to forcibly load the DLLs that Entity Framework is using for its SqlClient connection. This forces them to be included in the build process.

Try adding this to your program’s beginning:

// the terrible hack
var ensureDLLIsCopied = System.Data.Entity.SqlServer.SqlProviderServices.Instance;

I know, I know, it’s terrible, and it’s a hack. That’s why the comment is there! ;)

Anyway, it should force msbuild to copy all of your DLLs to the build folder, since there’s an “explicit, actual call” to a class inside the DLL. Normally, it’d probably optimize your application by leaving “unused DLL” out. Now it can’t do that anymore :) 

If it’s stupid but it works, it’s not stupid. And you should be golden!

References

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.

1
Leave a Reply

avatar
5000
1 Comment threads
0 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Javier Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Javier
Guest
Javier

If you’re testing from a project that is not the intended startup project, include EntityFramework Nuget package in the project being tested, even though it doesn´t use EF.
That solved the issue for me