EF 4.1 exception "The provider did not return a ProviderManifestToken string"
I am trying to replicate an example found on MSDN. I am using ASP.NET and EF 4.1 (CTP?). I've used NuGet to install the EntityFramework package.
I am getting this error: The provider did not return a ProviderManifestToken string
...
and the database is never created.
Here is my connection string:
<add name="HospitalContext"
connectionString=
"data source=.\SQLExpress;initial catalog=NewTestDB;integrated security=True;"
providerName="System.Data.SqlClient"/>
Here is my code:
var pat = new Patient { Name = "Shane123132524356436435234" 开发者_运维百科};
db.Patients.Add(pat);
var labResult = new LabResult { Result = "bad", Patient = pat };
int recordAffected = db.SaveChanges();
Here is my context:
public class HospitalContext : DbContext
{
static HospitalContext()
{
Database.SetInitializer(new HostpitalContextInitializer());
}
public DbSet<Patient> Patients { get; set; }
public DbSet<LabResult> LabResults { get; set; }
}
public class HostpitalContextInitializer :
DropCreateDatabaseIfModelChanges<HospitalContext>
{
protected override void Seed(HospitalContext context)
{
context.Patients.Add(new Patient { Name = "Fred Peters" });
context.Patients.Add(new Patient { Name = "John Smith" });
context.Patients.Add(new Patient { Name = "Karen Fredricks" });
}
}
This is a fully patched SQL 2008 system, with VS 2010 SP1.
I was getting this error and tried a few of the earlier suggestions. Then I checked the Inner Exception and noticed I was getting a simple SQL login failure for the user. Just something else to check.
This can happen sometimes when you place the connection string within the app.config of the wrong project in Visual Studio.
For example, I got this problem in EF 4.1 (the released version) project + WCF Data Service project and I noticed that I didn't have a connection string specified in the Data Services Project, where it was being used.
I had the same problem, and I add the below code just after the instance of my context (onload by exemple)
context.Database.Connection.ConnectionString = @"Data Source=.\SQLExpress;Initial Catalog=Test;Integrated Security=True";
I was having same error, and actually it was login failed for the specified server. I removed "Integrated Security" attribute from the config connection string and it worked.
I had a similar issue with the MvcMusicStore app. I changed a line in the Web.config from "Instance=true" to "Instance=false". It sometimes works without this tweak but I don't know what causes the difference. Reading this http://msdn.microsoft.com/en-us/library/ms254504.aspx didn't really help.
By some certain reason of permission, EF can not create database connection. I had faced the same problem all of one day. Finally I had tried following solution and it worked: a/ Open IIS (I'm using IIS 7) b/ Open advanced settings of appool which web site was using (Ex: DefaultAppPool) c/ Look at Process Model group, change Identity value to "Localsystem"
Hope it work with you.
I was just having the same problem...
the solution that worked for me was:
run the client network configuration tool (type cliconfg in Run)
and make sure TCP/IP is enabled..
I finally cracked it - after a slight wild goose chase thinking it was due to permissions.
Revelation: USE SQL PROFILER
(Note: I recently downgraded from EF6 to EF5)
Using SQL Profiler I quickly found the last SQL executed before the reported failure:
SELECT TOP (1)
[Project1].[C1] AS [C1],
[Project1].[MigrationId] AS [MigrationId],
[Project1].[Model] AS [Model]
FROM ( SELECT
[Extent1].[MigrationId] AS [MigrationId],
[Extent1].[Model] AS [Model],
1 AS [C1]
FROM [dbo].[__MigrationHistory] AS [Extent1]
) AS [Project1]
ORDER BY [Project1].[MigrationId] DESC
Well look at that - something to do with migrations. It's looking in __MigrationHistory
table - which I hadn't even realized it had created (I had already wiped out Migrations in my CSPROJ) and cleared that out.
So I pull up the rows for that table and see that it is tied to a specific product version (v6).
I actually downgraded from EF6 (which I didn't intend to install in the first place) to EF5 (which is more compatible with scaffolding) and that when the problems began.
My guess is that the Model (<Binary data>)
column is not backward compatible - hence the The provider did not return a ProviderManifest instance
error since it was unable to decode it.
I didn't have anything to lose and just wiped out this table completely and ran Update-Database -Verbose
and then was back up and running.
If you're in an advanced environment or already in production then wiping out this table may not be the solution, but this way allowed me to get right back to work.
In using Visual Studio 11 Beta with EF4.1 and ASP.NET MVC, I nearly pulled my hair out until I found
http://connect.microsoft.com/VisualStudio/feedback/details/740623/asp-net-mvc-4-default-connection-string-improperly-escaped
To fix my problem, I went into Application_Start and changed
Database.DefaultConnectionFactory = new SqlConnectionFactory("Data Source=(localdb)\v11.0; Integrated Security=True; MultipleActiveResultSets=True");
to
Database.DefaultConnectionFactory = new SqlConnectionFactory(@"Data Source=(localdb)\v11.0; Integrated Security=True; MultipleActiveResultSets=True");
This error is only present while the .edmx file is open and disappears as soon as the file is closed again.
This quote from CodePlex , this worked with me (visual studio 2013 /MVC 5)
One other thing to consider if you're using EF Code First is that it sometimes doesn't automatically create the backing database to your DbContext class. The solution is to add your own connection string - you can use the connection string that may be present to handle the user/registration database that backs the Simple Membership Provider, as a template. Finally, you will need to add a default constructor for the DbContext class you created:
public ChaletDb():base("ChaletConnection")
{
}
Here, the name of the connection string as you entered in your web.config file is used to direct the DbContext to create the database. Very occasionally, I've had to manually create the database (in SQL Server Management Studio) which prompted it to work.
I have multiple projects in a solution and added EF to each project in different times. On some machines it was working and on some it failed with aforementioned error. It took me a while to notice that some of my project's app.config had this:
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
<parameters>
<parameter value="v11.0" />
</parameters>
</defaultConnectionFactory>
This is ok if you use LocalDb (new "sql express" like), but completely wrong if you don't have that specific server installed and use a regular SQL.
Solution: Remove the above code.
This is because connection to SQL server failed.
Make sure the User Account under-which you are running the process have access to SQL Server.
If you have generated the DbContext from parent thread (like using dependency Injection) and then if you are impersonating another user then this error would occur. The solution would be to generate the DbContext inside the new thread or new Impersonation context.
I just closed all instances of Visual Studio and reopened my solution.
I don't know what really happened, but I had the same solution opened from two different local workspaces (one with my local changes, one with the unchanged repository source code). I work with a postgres DB, Entity Framework 6, Visual Studio 2013 and ASP.NET MVC 5.
I had a error for entity framework, but none of the above answers ended up fitting into the solution that finally worked.
My EntityFramework Code First Models and DataContext were in a Separate project from my WebAPI Main Project. My Entity Framework Project somewhere down the line of coding was set as the startup project and therefore when I was running a migration I was getting “The provider did not return a ProviderManifestToken string” ... connection issue.
Turns out that since the ConnectionString to the DB is located in the Web.config file in WebAPI Main project, that when I was running a migration the connection string was not being retrieved. By setting WebAPI project as my startProject I was able to successfully connect.
精彩评论