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

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

This post was most recently updated on October 4th, 2022.

2 min read.

This post describes the fix to THE “No Entity Framework provider found for the ADO.NET provider with invariant name ‘System.Data.SqlClient’” error, 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

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

Time needed: 5 minutes

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

  1. 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 are a couple of things you need to make sure of:

    You need to make sure that the 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.

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

    <pre lang="powershell">Install-Package EntityFramework -ProjectName [YourStartupProject]
    </pre>


  3. 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:

    <pre lang="csharp">// the terrible hack
    var ensureDLLIsCopied = System.Data.Entity.SqlServer.SqlProviderServices.Instance;</pre>

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

mm
5 6 votes
Article Rating
Subscribe
Notify of
guest

12 Comments
most voted
newest oldest
Inline Feedbacks
View all comments