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'”

Table of Contents

This post was most recently updated on March 24th, 2019.

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!


When debugging/running your code 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 for more information.

The running of the program is stopped there, and removing and readding 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!


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 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!


Follow me

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.
Follow me

Leave a Reply

Notify of