Error: Failed to generate a user instance of SQL Server

ok, it works now! guess it was a compound problem ... the steps I took to resolve it are as such:

1. Changed the following property in the connection string (note the subtle difference): AttachDbFilename=|DataDirectory|CustomerDb.mdf;
2. Deleted the contents of the following directory: c:\Users\<user name>\AppData\Local\Microsoft\Microsoft SQL Server Data\SQLEXPRESS. I thought I had looked for this before, but I had actually looked in the Microsoft Sql Server folder. Again, a subtle difference.

Once I did these two things, the connection started working :-D

I experienced the same error when i moved the code from one machine to another. i am using VS2010 and SQLEXPRESS 2008 comes along with it.

Trick , deleting all the contents from the following folde "C:\Users\UserName\AppData\Local\Microsoft\Microsoft SQL Server Data\SQLEXPRESS" worked for me.

In addition to the other solutions here, this one may also be helpful. Ensure the Application Pool is running as network service, and not ApplicationPoolIdentity.

This solution was found here: http://blogs.msdn.com/b/webdevelopertips/archive/2010/05/06/tip-106-did-you-know-how-to-create-the-aspnetdb-mdf-file.aspx

Even despite above answers solved the problem many people, I m still finding these falling short of the essence of the problem. Closest to it is the answer by @sohaiby above. But it wrongly refers to using Management Studio.

The error message on top of this topic tells very clearly that the problem is with generating a user instance. What instance is and how it is used is described here in every detail: https://msdn.microsoft.com/en-us/library/ms254504(v=vs.110).aspx

Personally, I encountered this problem when switching DB connection from windows authentication mode to SQL Server authentication. I solved it by just modifying a part of connection string to: "User Instance=false;" instead of "User Instance=true;", which worked fine with windows authentication.

After I changed to "User Instance=false;" my connection worked fine without any additional manipulations. I cannot insist that it will work or will be suitable in all scenarios. However, I will definitely recommend trying it before other drastic methods described above, such as erasing SQL server work directories.