Entity Framework 4.1 DbContext generator problems

Question

I am new to Entity Framework 4.1 and I really wanted to transition to POCO classes for my model. I found that this was very easy using the "DbContext Generator" item provided when you install EF 4.1. It did exactly what I wanted it to do and generated the DbContext object and all the POCOs for my existing EDMX model.

I ran the app and tested that it was still working. It was. Happy with this I deleted the EDMX file and the T4 templates and began reorganizing my new POCOs. However, after getting it to build properly again I encountered a runtime problem. When instantiating the DbContext it is unable to find the metadata files: .csdl, .ssdl, & .msl (I really don't know what they are, just that they are part of all EF connection strings).

After putting back my EDMX it ran fine again. I really don't want the EDMX file anymore. I would really like to stick to POCO classes and forget that the EDMX ever existed; especially because I don't want it running those T4 templates and regenerating my POCOs.

I have four related questions:

1. Why do I have to keep the edmx in my project?
2. Is there a workaround for this?
3. What happens when you do true "code-first" with EF 4.1, where does it get those metadata files from?
4. What are those metadata files anyway?

Answer 1

You should read this . It describes the different project types.

The short answer is you need the .edmx file when using the dbcontext generator. If you want to use Code First, you have to either describe the model by hand or use the Entity Framework power tools CTP1 to reverse engineer a code first model.

Answer 2

1. The EDMX file is responsible for embedding the CSDL, SSDL, & MSL metadata resources in the assembly at compile-time.

2. Yes. You will need Entity Framework Power Tools CTP 1. See Mystere Man's answer on this question for a link. This will be a true conversion from an existing database to code-first. What this means is that your code will drive the schema going forward, not the other way around.

3. When you are doing true code-first development the CSDL, SSDL, & MSL metadata resources are still there. They are simply inferred from your object model when you build. Because the code controls the model and schema, it is able to infer these resources on its own. There are some instances though where it does not know what to infer from the code. For instance, if you change an entity property name it has no way of knowing if you intended to delete the old column (property name) and add a new column with the new name, or if you intended to keep the old column and rename it with the new name. This is why there is no good data/schema migration with EF code-first and why it drops and recreates the entire database each time you change your model in code.

   This shortcoming of the DbContext API is definitely the biggest issue and is currently being worked on by the ADO.NET team as noted on Scott Hansleman's blog post .

   For now I have personally opted to modify the database manually and then simply update my C# code to reflect it. This requires some decent knowledge of how these things work and I'm still practicing. Another way to do this is to leave the EDMX file there, update it like you normally would, and let it regenerate your POCOs when things change. However that is almost no different than doing classic EF updates as any changes to the POCOs will be overwritten when they are regenerated.

   Yet another solution is to again leave the EDMX file there and update it when things change, but set the "Transform Related Text Templates On Save" property to false.

   http://www.codetunnel.com/content/images/TransformRelatedTextTemplatesOnSave.jpg

   This prevents the EDMX from running your T4 templates and regenerating your POCOs. So you would simply update it to ensure that the metadata resources remain accurate. But then you would manually modify your POCOs to reflect any changes to the model/schema. This still requires a lot more work than just letting it generate your code but it's good for learning in my humble opinion.

4. The CSDL, SSDL, & MSL are metadata resources for EF. They help EF determine how to map result sets to your object model and vice versa. It is the bridge between the database schema and your code. No matter what way you use EF these resources are there, only differing in the way they are generated.

Answer 3

That doesn't work this way. If you decide to use DbContext Generator you are saying that your mapping will be described in EDMX file. During compilation EDMX file is decomposed to three separate files with .ssdl, .csdl and .msl extensions. These metadata files describes your database, entities and mapping from database to entities. These files are by default stored as resources in your compiled assembly and referenced from connection string passed to your DbContext instance. You must keep your EDMX file in the project if you want to use DbContext created by generator. It is same mapping approach as was used in EFv1 and EFv4 = it is not code first.

Code first means no EDMX and no T4 template to generate mapping and code for you. In normal way code first means that you write your classes before you have any database and a database is created by EF. Many people are using this approach with existing database and mapping they classes to existing database manually but it requires some knowledge / experience with EF (or you can ask targeted questions here and we will help you).

Metadata are needed for context to perform mapping and SQL command generation. EDMX mapping strategy uses metadata defined in mentioned XML files. Code first mapping strategy uses some default conventions, fluent-API or data annotations to get metadata from compiled code.

There is separate project allowing to generate code first mapping from existing database - I pointed that project in your previous question .