Julia Lerman's Blog, page 19

Video: Entity Framework 5 Enums and Moving Solution from EF 4.3

I moved a small EF 4.3 solution to EF5 (and to .NET 4.5) so I can add the new enum support to it. Then I started the process all over again and captured it as a screencast.

Pluralsight is hosting it on their blog here: Video: Entity Framework 5 New Features Sneak Peek. It’s 14 minutes long. I learned a whole bunch of tricks along with way which I’ve shared here.

Moving a solution from EF4.3 +.NET 4 to EF5 +.NET 4.5
Using the new SQL Server Object Explorer in Visual Studio 11
Working with the new DbLocal database
Seeing the enum support in action : how it impacts the database, inserting and querying data with enums.

Update to EF5 and DbLocal Default in Config

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>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

EF5: Where are my DataAnnotations?

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.

Moving Projects from EF 4.1,2,3–> EF5Beta: Don’t do what I did

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:

Update the projects to target .NET 4.5 *first*
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!

Moving Projects from EF 4.1,2,3–> EF5Beta: Don't do what I did

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:

Update the projects to target .NET 4.5 *first*
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!

EF Code First Migrations Update-Database Parameters Documentation?

In my recent )

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".

VS11 and EF5: Where’s that database that Code First created?

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.

VS11 and EF5: Where's that database that Code First created?

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.

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.

Updating to Entity Framework v.Latest the Easy Way

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.)

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. 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.

EF Code First Migrations, Update-Database outside of Visual Studio

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.