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!
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!
First of all, you will want to verify that you do in fact have the provider configured in your application/web config file.
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!
- Originally discovered on Stack Overflow!
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.
Latest posts by Antti K. Koskela (see all)
- IE11 fails to load a (server-side) Blazor web app - November 13, 2019
- How to instantiate your DbContext outside your Data project? - November 11, 2019
- Another year, another Hacktoberfest (2019)! - November 1, 2019