A few weeks ago I wrote a blog post showing how EF5 uses DbLocal as its default database along with a screenshot of the configuration info that EF5 puts into your config (web.config or app.config) of the project that you’ve installed EF5 into.

Since then, EF5 Beta 2 was released and the details have changed ever so slightly.

Now, instead of having a SqlConnectionFactory and critical elements of a connection string, we have a new factory, the LocalDbConnectionFactory.

Here is what the element looks like with EF5 Beta 2:

  <entityFramework>
    <defaultConnectionFactory 
      type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

EF 4.x:

EF 4.1+ has a DataAnnotations namespace for the new EF related annotations. Most of them are related to database schema.

EF 5

Not even a DataAnnotations namespace in here. That’s because the annotations got incorporated into .NET 4.5.

.NET 4.5

A new namespace within System.ComponentModel.DataAnnotations: “Schema”

All of the EF schema annotations are in here now. MaxLength and MinLength are in the DataAnnotations namespace.

Added the following thanks to a suggestion from Cecil Phillip

If you are using EF5 with .NET 4, there is a special version of the Entity Framework assembly which actually has the version 4.4.*.

The EF related DataAnnotations *are* in this assembly but notice they’ve been organized into regular and schema as they are in  .NET 4.5.

What did I do? I wasted hours and hours so that I can share this lesson with you. The bottom line is that I’m kindofa dope sometimes.

I had an EF 4.3 project that I moved onto a new machine with VS11 Beta.

I wanted to see the new enum support in action.

So, I installed the new EF 5 by opening up the Package Manager Console and typing in

install-package entityframework –pre

(The pre ensures that you get the latest pre-release version rather than the latest RTM…very clever )

I added in my enums and fixed up my classes and then since I was on a new machine, I ran enough code to initialize the database.

I had done this before on another machine and already seen this work, so I wasn’t quite as excited this time when I opened up the database to see what Code First had given me. But the properties that were based on my new enums were NOT THERE.

Fast forward to about 2 hours later, then sleep, then another hour this morning.

In all of that time one thing I had noticed but NOT realized was my biggest clue was that the version of EntityFramework.dll in my projects as 4.4. I thought that maybe the team had decided not to number it 5 until it was released. (No only someone as dumb as me would think of that excuse, I guess )

Finally this morning after my 2nd cup of coffee I figured it out.

Installing EF5 (beta) installs TWO packages. One that can be used with .NET 4 and one that can be used with .NET 4.5. Note that it is .NET 4.5 that brings the goods for the enum support.

So then the question was, “why did I get the .NET 4 version of EF5?” and I know the answer.

I installed the package BEFORE I updated my projects from targeting .NET 4 to targeting .NET 4.5.

So, to update an EF 4.x project to EF5 + .NET 4.5 goodies the steps are:

1. Update the projects to target .NET 4.5 *first*
2. Install the EF5 package into each of the relevant projects.

Hoping this saves someone the grief and waste of time that it cost me. You know…it’s just how I roll!

In my recent Code First Migrations course on Pluralsight.com, I showed how you can get detailed information about the parameters of update-database. These can also be used if you want to execute the migrations from the command line using the counterpart migrate.exe command rather than from within Visual Studio.

You can get at the details from the Package Manager Console in Visual Studio with the get-help commandlet as shown below. Or if you are using the command line just type migrate –? as you can see in this blog post I wrote about executing migrations from the command line. I don’t know how to get the “full” information from the command line but it’s available in the Package Mgr Console and displayed below.

• -detailed gives a description of each parameter.
•  –full provides the description and then even more detail about how to use each parameter. I show that output below the output of the DETAILED display.

(Note, I just had to correct the misspelling of omitted when I pasted this in. )

PM> get-help update-database -detailed

NAME
    Update-Database
   
SYNOPSIS
    Applies any pending migrations to the database.
   
   
SYNTAX
    Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUp
    ProjectName <String>] [-ConfigurationTypeName <String>] [-ConnectionStringName <String>] [<CommonParameters>]
   
    Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUp
    ProjectName <String>] [-ConfigurationTypeName <String>] -ConnectionString <String> -ConnectionProviderName <String> [<Common
    Parameters>]
   
   
DESCRIPTION
    Updates the database to the current model by applying pending migrations.
   

PARAMETERS
    -SourceMigration <String>
        Only valid with -Script. Specifies the name of a particular migration to use
        as the update’s starting point. If omitted, the last applied migration in
        the database will be used.
       
    -TargetMigration <String>
        Specifies the name of a particular migration to update the database to. If
        omitted, the current model will be used.
       
    -Script [<SwitchParameter>]
        Generate a SQL script rather than executing the pending changes directly.
       
    -Force [<SwitchParameter>]
        Specifies that data loss is acceptable during automatic migration of the
        database.
       
    -ProjectName <String>
        Specifies the project that contains the migration configuration type to be
        used. If omitted, the default project selected in package manager console
        is used.
       
    -StartUpProjectName <String>
        Specifies the configuration file to use for named connection strings. If
        omitted, the specified project’s configuration file is used.
       
    -ConfigurationTypeName <String>
        Specifies the migrations configuration to use. If omitted, migrations will
        attempt to locate a single migrations configuration type in the target
        project.
       
    -ConnectionStringName <String>
        Specifies the name of a connection string to use from the application’s
        configuration file.
       
    -ConnectionString <String>
        Specifies the the connection string to use. If omitted, the context’s
        default connection will be used.
       
    -ConnectionProviderName <String>
        Specifies the provider invariant name of the connection string.
       
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        "get-help about_commonparameters".
   

---

PM> get-help update-database -full

NAME
    Update-Database
   
SYNOPSIS
    Applies any pending migrations to the database.
   
SYNTAX
    Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUp
    ProjectName <String>] [-ConfigurationTypeName <String>] [-ConnectionStringName <String>] [<CommonParameters>]
   
    Update-Database [-SourceMigration <String>] [-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>] [-StartUp
    ProjectName <String>] [-ConfigurationTypeName <String>] -ConnectionString <String> -ConnectionProviderName <String> [<Common
    Parameters>]
   
   
DESCRIPTION
    Updates the database to the current model by applying pending migrations.
   

PARAMETERS
    -SourceMigration <String>
        Only valid with -Script. Specifies the name of a particular migration to use
        as the update’s starting point. If omitted, the last applied migration in
        the database will be used.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -TargetMigration <String>
        Specifies the name of a particular migration to update the database to. If
        omitted, the current model will be used.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -Script [<SwitchParameter>]
        Generate a SQL script rather than executing the pending changes directly.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -Force [<SwitchParameter>]
        Specifies that data loss is acceptable during automatic migration of the
        database.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -ProjectName <String>
        Specifies the project that contains the migration configuration type to be
        used. If omitted, the default project selected in package manager console
        is used.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -StartUpProjectName <String>
        Specifies the configuration file to use for named connection strings. If
        omitted, the specified project’s configuration file is used.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -ConfigurationTypeName <String>
        Specifies the migrations configuration to use. If omitted, migrations will
        attempt to locate a single migrations configuration type in the target
        project.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -ConnectionStringName <String>
        Specifies the name of a connection string to use from the application’s
        configuration file.
       
        Required?                    false
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -ConnectionString <String>
        Specifies the the connection string to use. If omitted, the context’s
        default connection will be used.
       
        Required?                    true
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    -ConnectionProviderName <String>
        Specifies the provider invariant name of the connection string.
       
        Required?                    true
        Position?                    named
        Default value               
        Accept pipeline input?       false
        Accept wildcard characters? 
       
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        "get-help about_commonparameters".

Visual Studio 11 brings a new development database — SQL Server Local Database. Bye bye SQL Server Express dependency.

I typically let Code First run with it’s default database of choice – up to now that’s been SQL Server Express — when I’m creating simple samples where  I don’t care too much about keeping the sample database around.

But I’m so used to opening up SSMS to look at detailed information about the database, especially when Code First is involved in creating it’s schema. I like to see what’s happening.

In Visual Studio 2010’s server explorer, I can’t typically glean the details I’m after. (Maybe I need more instruction here? ) For example, I have to open a column’s properties window to see details.

In SSMS, I prefer the view:

With EF5 however, the default database for code first is the new SQL Server 2012 LocalDb.

When you add EntityFramework 5 to your project it adds some configuration elements to the application’s config file and in there is where EF is setting the default ConnectionFactory for Code First to use LocalDb.

NOTE: April 3, 2012: This connection factory info has changed a bit with EF 5 Beta 2. See this updated blog post: Update to EF5 and DbLocal Default in Config

I’m sure lots of people won’t think to look in there and will just be happy that the database is magically there. (Not me. I can’t bear not knowing how things work. )

So if you want to look at your data, forget the Server Explorer. Check out the new SQL Server Object Explorer in Visual Studio. It will look very familiar … if you use SSMS, that is. They’ve pulled the explorer from SSMS into Visual Studio and improved upon it. Very nice!!

Also, take note that last time I checked, you could not open up localdb databases in SSMS. That may not longer be the case. But I don’t feel like installing full blown SQL Server on my virtual machine to verify since I now have what I need inside of Visual Studio.

To see your database in the new Object Explorer:

1. Click the New Database icon/glyph/blob (circled)

2. In Connect to Server window, TYPE IN “(localdb)/v11.0”. Don’t click the dropdown unless you want to wait for the wizard to explore the outer reaches of the universe for every possibly accessible SQL Server instance.

3. Then after connecting, you can expand the new connection to explore your database, in detail, inside of Visual Studio. (yay)

There are some nice improvements over the SSMS 2008 UI I’m used to. For example, if you right click a table you can choose View Data and there is an option box in the viewer to choose how many rows you want to look at. That’s just one little example. Another example is if you do something like delete a table, you will get the options of creating a script or just executing the change on the database. I’m sure you’ll find lots of information on these types of changes.

Now when you are working with Code First and using default behavior, you know where to find the database it’s created for you and how to inspect that database.

Entity Framework is evolving rapidly which is why they are releasing via NuGet rather than being strapped to the .NET release cycle. (You can read more about the how’s and why’s of EF’s release cycle here: http://blogs.msdn.com/b/diego/archive/2012/01/15/why-entity-framework-vnext-will-be-ef5-and-nothing-else.aspx ).

The following is about keeping current with Entity Framework Code First and DbContext, not about upgrading the core API that is in .NET.
EF 4.1 – 4.3.1 work with .NET 4.0.
EF 5 (currently in beta) will work with .NET 4.5 (also currently in beta).

It’s recommended that you keep your apps that use EF (Code First/DbContext) up to date. The updates add functionality and fix some bugs, so this is a fairly safe prospect (granted there were a few problems for some very particular scenarios in the past but those have been corrected).

Thanks to the NuGet integration in Visual Studio it’s really easy to update EF assemblies across a solution without having to update each project that might need it. (You’ll need NuGet installed in VS which you can do via the Extension Manager.)

Right click the solution in Solution Explorer and click Manage NuGet Packages for Solution.

Select Updates (circled in the image). The dialog will show you any packages for which updates are available. My solution has 5 projects and I am using EF 4.1 in four of them. So the tool sees that I’ve got those installed and that there’s a newer version available, so it presents that to me. Click Update.

Now I am presented with all of the projects that are using an out-of-date version of Entity Framework. By default, they are all checked to have the most current version installed. Click OK.

As NuGet updates the packages in your projects, it will show the progress for each package. Here I can see that my console app project has just been updated from 4.1 to 4.3.1.

In a recent blog post comment, someone asked “can you please tell them [EF Dev Team] some developers would like to use the Power Shell command script and not PM console to update database.”

If you look inside the package folder for Entity Framework 4.3 (or 4.3.1 or whatever is the current version in the future) there’s a tools directory and inside of there a migrate.exe command. It is the same as the update-database command with all of the same parameters.

Modified the original title of this post because it was derived from a misquote. Scott Hanselman clarifies with: The quote (what I said was) "EF is joining our team under ScottGu" and "EF is now the M in MVC". Scott Guthrie chimes in with “Yes – now part of my team (which includes ASPNET, WCF, WF, EF, Service Bus, BizTalk, Cache)”

_________________________________

Arthur Vickers, from the EF team, tweeted:

Also, very happy to be moving to @scottgu’s org with the rest of the Entity Framework team. Great for us, great for EF, great for Microsoft.

Just a reminder of Scott’s current role: “responsible for delivering the development platform for Windows Azure, as well as the .NET Framework and Visual Studio technologies used in building Web and server applications.”

A little later there was this on twitter from Noah Coad who is at Dallas Days of .NET (follow #dodn12 on twitter)

@shanselman at #dodn12 "just announced, we have an M in MVC, Entity Framework is now part of ASP.NET"

And then this interesting question from Daniel Bradley:

if Entity framework is to be part of ASP.NET, does this mean open-sourcing of the tools & framework?

Stay tuned….

(and since someone asked, EF has always been part of ADO.NET)