Two Firsts, one great taste... A "Database-First Code-First Entity Framework 5 Model"

The Curly Brace - How to Create a Database-First Code-First Entity Framework 5 Model

Why would you ever want to have your EF5 model perform code-first operations, when using a database-first generated model? I can think of two reasons:

1. Dynamically creating a disconnected SQL Server Compact Edition (CE) database on the client, with a high degree of security
2. Silencing the developer who insists their database management tool has superior schema editing capabilities

In my case, I developed a read-only, disconnected client application that stored lots of data in a local SQL Server Compact Edition 4.0 database (CE), which was stored in their AppData\Local directory. Other requirements, which I will not discuss here, require the database files be created on-demand. We have the potential for new users that need a new CE file, on demand. The Database.Create() command of a code-first data model is ideal for this situation.
The average import was about 500MB, so not really something we want to pipe through the EF5 model. The most efficient way to periodically import data was through a BulkCopy command. CE has no BulkCopy command, but Erik created a library for that, here. Using this command requires the schema of both databases to match, which is satisfied by a database-first model.
The object of this exercise is to generate a database-first model from the schema defined in an existing database, and then turn that around to generate a new database from the EF5 backing store. Chocolate in your peanut butter, indeed.

...

Unfortunately, the code this message asks us to remove is generated by a T4 template. Let's get our hands into some code, and figure out how to remove the method.
This is a very easy fix. Famous last words, I know. But, this actually is an easy fix. Before we begin, here's the big, fat disclaimer:

• This solution disables the safeguard Entity Framework 5 (EF5) puts in place, to prevent a database-first model from performing code-first model functions
• This solution must be implemented every time you create a new, database-first EF5 model
• Assume that updating the schema of the database by using code-first functions will cause data loss or corruption
• No, I am not responsible for breaking your code, database, and/or data; that's all you

..."

Oh no... I think I'm a #2 (no wise cracks from the peanut gallery please...). I like the thought of Code First, but I've been doing Database First for so darn long that I'm having a problem breaking that mental block. But then again, having spent the week hand coding my entities and DAL... (Why? Because... um... Stored Procedures? um... err... because the magic of EF is kind of scary... um... err...  I'm lame and my brain is old? um... damn). sigh...

Anyway... While this seems like a cool kind of hack (hack in a good way), this might be something I'm going to have to look closer at.