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.