Scott Guthrie announced on his blog that the Release Candidate of the excellent Entity Framework 4.1 is now available. See here for all the gen.
He has also updated the "NerdDinner" sample project to use the new EF4.1 features, especially the "Code First" pattern where you can create lovely, clean POCO models and have them automatically create the database schema, update the schema and handle the repository actions.
It's a fantastic post and goes a long way to explaining the topics. However, given the bleeding-edge of this technology, there are a couple of differences between Scott's code and the RC code that you can get from here.
New names for IDatabaseInitializer conventions
Scott's code shows the following to persuade (in debug code) how to recreate the database if the underlying model changes;
void Application_Start()
{
Database.SetInitializer<NerdDinners>(new RecreateDatabaseIfModelChanges<NerdDinners>());
RegisterRoutes(RouteTable.Routes);
}
In fact, the RecreateDatabaseIfModelChanges convention is now called DropCreateDatabaseIfModelChanges so the code should really look like this
void Application_Start()
{
Database.SetInitializer<NerdDinners>(new DropCreateDatabaseIfModelChanges<NerdDinners>());
RegisterRoutes(RouteTable.Routes);
}
Can't Drop and Create if using SQL Authentication
I was using SQL Authentication in my connection string but, when the application tried to drop and re-create the database (because the model changed), I got the following exception;
InvalidOperationException was unhandled by user code
This operation requires a connection to the 'master' database. Unable to create a connection to the 'master' database because the original database connection has been opened and credentials have been removed from the connection string. Supply an unopened connection.
it seems that this is a known issue with the current RC (and possibly the earlier CTP releases) and the only current solution is to use integrated security in the connect string;
<connectionStrings>
<add name="NerdDinners"
connectionString="Data Source=PC; Initial Catalog=nerdDinners; Integrated Security=SSPI"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
I'm ok with this because you should only really be using the drop/create functionality in dev and test. In production we would need some kind of migration script so, presumably, we'll be able to go back to SQL Server credentials.
Adding MicrosoftAjax.js and MicrosoftMvcValidation.js causes the form to silently fail
About halfway down the article, Scott adds some validation attributes to the POCOs, and brings in the Ajax and Validation javascript to the Create Controller. Looks great; in his blog there's a lovely picture of failed validation showing up some pinkey-red validation errors.
Unfortunately, when you type in the code he has there, the form fails to load. Something was going wrong in the script load but it was hard to see what. Playing around with the debugger showed that it was actually failing in the first line of MicrosoftAjax.js, which reads;
Type.registerNamespace('Sys.Mvc')
Scott's original code looked like this;
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Create new dinner</title>
<link href="/Content/Site.css" rel="stylesheet" type="text/css" />
<script src="/Scripts/MicrosoftAjax.js" type="text/javascript" />
<script src="/Scripts/MicrosoftMvcValidation.js" type="text/javascript" />
</head>
<body>
<% Html.EnableClientValidation(); %>
Guess what the problem was….? Yep, the trailing "/>" tags on the script definitions. If you change them to "> </script>", then it all starts working;
<script src="/Scripts/MicrosoftAjax.js" type="text/javascript" > </script>
<script src="/Scripts/MicrosoftMvcValidation.js" type="text/javascript" > </script>
How wierd is that? update looks like this is an IE-specific issue. I only have IE9 so it may even be an IE9 specific issue.
In regards to the following exception:
System.InvalidOperationException: This operation requires a connection to the ‘master’ database. Unable to create a connection to the ‘master’ database because the original database connection has been opened and credentials have been removed from the connection string. Supply an unopened connection. System.Data.SqlClient.SqlException: Login failed for user ‘sa’
Entity Framework 4.1 Update 1 contains a bug fix to remove the need to specify ‘Persist Security Info=True’ in the connection string when using SQL authentication.
http://www.microsoft.com/download/en/details.aspx?id=26825
Yep – spotted that today – it's also best to update nuget to ensure that you get the latest version of EF