POCO in the Entity Framework 4: Part 1 - The Experience

  • Article

 

The information in this post is out of date.

Visit msdn.com/data/ef for the latest information on current and past releases of EF.

 

Last week I mentioned in the sneak preview on POCO that support for POCO entities is one of the new capabilities we have added to Entity Framework 4.0. This week, I’d like to go into the details of POCO support in Entity Framework 4.0.

There’s quite a bit to discuss here, including:

  • Overall POCO experience in Entity Framework 4.0
  • Change Tracking in POCO
  • Relationship Fix-up
  • Complex Types
  • Deferred (Lazy) Loading and Explicit Loading
  • Best Practices

In this post, I will focus primarily on the overall experience so that you can get started with POCO in Entity Framework 4.0 right away. I’d like to use a simple example that we can walk through so you can see what it feels like to use POCO in Entity Framework 4.0. I will use the Northwind database, and  we’ll continue to build on this example in subsequent posts.

Step 1 – Create the Model, turn off default Code Generation

While POCO allows you to write your own entity classes in a persistence ignorant fashion, there is still the need for you to “plug in” persistence and EF metadata so that your POCO entities can be materialized from the database and persisted back to the database. In order to do this, you will still need to either create an Entity Data Model using the Entity Framework Designer or provide the CSDL, SSDL and MSL metadata files exactly as you have done with Entity Framework 3.5. So first I’ll generate an EDMX using the ADO.NET Entity Data Model Wizard.

image

  1. Create a class library project for defining your POCO types. I named mine NorthwindModel. This project will be persistence ignorant and will not have a dependency on the Entity Framework.
  2. Create a class library project that will contain your persistence aware code. I named mine NorthwindData. This project will have a dependency on Entity Framework (System.Data.Entity) in addition to a dependency on the NorthwindModel project.
  3. Add New Item to the NorthwindData project and add an ADO.NET Entity Data Model called Northwind.edmx (doing this will automatically add the dependency to the Entity Framework).
  4. Go through “Generate from Database” and build a model for the Northwind database.
  5. For now, select Categories and Products as the only two tables you are interested in adding to your Entity Data model.

Now that I have my Entity Data model to work with, there is one final step before I start to write code : turn off code generation. After all you are interested in POCO – so remove the Custom Tool that is responsible for generating EntityObject based code for Northwind.edmx. This will turn off code generation for your model.

image

We are now ready to write our POCO entities.

Step 2 – Code up your POCO entities

I am going to write simple POCO entities for Category and Product. These will be added to the NorthwindModel project. Note that what I show here shouldn’t be taken as best practice and the intention here is to demonstrate the simplest case that works out of the box. We will extend and customize this to our needs as we go forward and build on top of this using Repository and Unit of Work patterns later on.

Here’s sample code for our Category entity:

     public class

Category

     {
        public int CategoryID { get; set; }
        public string CategoryName { get; set; }
        public string Description { get; set; }
        public byte[] Picture { get; set; }
        public

List<Product

 > Products { get; set; }
    }

Note that I have defined properties for scalar properties as well as navigation properties in my model. The Navigation Property in our model translates to a List<Product>.

Similarly, Product entity can be coded like this:

     public class

Product

     {
        public int ProductID { get; set; }
        public string ProductName { get; set; }
        public int SupplierID { get; set; }
        public string QuantityPerUnit { get; set; }
        public decimal UnitPrice { get; set; }
        public

Int16

  UnitsInStock { get; set; }
        public

Int16

 UnitsOnOrder { get; set; }
        public

Int16

  ReorderLevel { get; set; }
        public bool Discontinued { get; set; }
        public

Category

  Category { get; set; }
    }

In this case, since the relationship allows only one Category that a Product can belong to, we have a reference to a Category (unlike the List<T> collection we have for modeling the Navigation Property in Category).

Step 3 – Code up your Entity Framework Context

The last thing I have to do in order to pull all of this together is to provide a context implementation (much like the ObjectContext implementation you get when you use default code generation). The context is the glue that brings persistence awareness into your application, and it will allow you to compose queries, materialize entities as well as save changes back to the database. The context will be a part of the NorthwindData project.

For simplicity, I will include our context into the same class library that has our entity types – but when we discuss patterns such as Repository and Unit of Work, we will set it up such that you have a pure POCO class library without any persistence concerns.

Here’s a simple context implementation for our scenario:

 public class

NorthwindContext : ObjectContext

     {   
        public NorthwindContext() : base

("name=NorthwindEntities",

  

"NorthwindEntities"

 )  
        {
            _categories = CreateObjectSet<

Category

 >();
            _products = CreateObjectSet<

Product

 >();
        }

        public

ObjectSet<Category

 > Categories
        {
            get 
            { 
                return _categories; 
            }
        }
        private

ObjectSet<Category

 > _categories;

        public

ObjectSet

 <

Product

 > Products
        {
            get
            {
                return _products;
            }
        }
        private

ObjectSet

 <

Product

 > _products;
    }

Note that ObjectSet<T> is a more specialized ObjectQuery<T> that we introduced in Entity Framework 4.0.

That’s it – now you have pure POCO entities with a simple context that will allow you to write queries like this:

NorthwindContext

  db = new

NorthwindContext

 ();

var

  beverages =

from

  p in db.Products
                    where p.Category.CategoryName == "Beverages"

select

  p;

The entities that are materialized are pure POCO entities, and you can make and persist changes much like you would with regular EntityObject or IPOCO entities. You get all the services provided by Entity Framework - the only difference is that you are using pure POCO entities.

There are many possibilities here as far as how we can improve on this simplified example. Before we get into that however, I would like to get some basic questions out of the way.

Do I need an Entity Data Model before I can use POCO?

Yes – POCO support in Entity Framework 4.0 simply removes the need of having persistence specific concerns in your entity classes. There is still the need for you to have a CSDL/SSDL/MSL (collectively EDMX) metadata so that the Entity Framework is able to use your entities along with the metadata in order to enable data access. There is a separate effort that we are working on that will allow you to do true “code-first” development without the need to have a predefined EDMX model. A community preview of this feature will be released to the web in the coming months. We will roll this into the product the first chance we get. As always, your feedback will be helpful.

Do I have to always hand-craft these entities and the context?

No – there is a very powerful and flexible code generation mechanism in Entity Framework 4.0 that is based on T4 as Alex blogged about here. You can provide your own templates that allow you to build your entities in a way that you see fit. We are also working on providing standard out of the box templates that will generate POCO entities for you.

How is metadata mapped when using POCO entities?

In Entity Framework 3.5, both EntityObject and IPOCO based entities relied on the use of mapping attributes that were meant for decorating and mapping the entity types and properties back to the corresponding elements in the Conceptual model. Entity Framework 4.0 introduces convention based mapping for allowing mapping of Entity Types, Properties, Complex Types and Relationships back to the conceptual model without the need for explicit decoration. The simple rule here is that Entity Type names, Property names and Complex Types names used in your POCO classes must match those defined by the conceptual model. Namespace names are ignored and don’t have to match between the class definition and the conceptual model.

Do I need to have public getters and setters for all properties in my entity classes?

You can use any access modifier on your POCO type’s properties as long as none of the mapped properties are virtual and as long as you don’t require partial trust support. When running in partial trust, there are specific requirements on the visibility of access modifiers on your entity classes. We will be documenting the complete set of access modifiers that are supported when partial trust is involved.

What types of collections are supported for collection based navigation properties?

Any collection that is an ICollection<T> will be supported. If you don’t initialize the field with a concrete type that is an ICollection<T> type, then an List<T> type will be provided upon materialization.

Can I have uni-directional relationships? For instance – I would like to have a Category property in my Product class, but I don’t want to have a Products collection in my Category class.

Yes – this is supported. The only restriction here is that your entity types have to reflect what is defined by the model. If you are not interested in having the navigation property for one side of the relationship, then remove it from the model completely.

Is Deferred (Lazy) Loading supported with POCO?

Yes – Deferred (Lazy) loading is supported with POCO through the use of proxy types that are used to provide automatic lazy loading behavior on top of your POCO classes. This is something that we’ll cover when we get to deferred loading – until then know that eager loading via the use of “Include” is also supported, like so:

var

  beverageCategory = (

from

  c in context.Categories
.Include("Products")
                        where c.CategoryName == "Beverages"

select

  c).Single();

If I were to use Deferred (Lazy) Loading, I don’t have to do this – we’ll discuss that when we discuss proxies.

Fixing up Relationships

There are two types of fix-ups to be aware of: 1)Fix-up during query, and 2) Fix-up during changes to your entities/relationships

Fix-up during Query

Fix-up during query happens when you load related entities using separate queries on the same ObjectContext. For instance, if I were to query for a category instance Beverages, and later query for a product instance Chai (that is in Category Beverages), I would want chai.Category to point to the instance of the Beverages category without additional work.

This is automatic and works today.

Fix-up during changes to your entities/relationships

This is the relationship fix-up between two entities when I add/remove an entity that is related to another entity or alter relationships. Think of this as the case when I create a new product called “Diet Chai” and want to associate it with the Beverages category .

In Beta1 of Entity Framework 4.0, you do not get automatic relationship fix-up in this case with POCO entities. When dealing with relationships that change between entities, you will have to make sure that your POCO types include the logic to manage fix-up on both ends of the relationship correctly.

For instance, in my Northwind example, I have defined the following method on Category to support adding / removing of Orders.

         public void AddProduct(

Product

  p)
        {
            if (Products == null)
            {
                Products = new

List<Product

 >();
            }

            if (!Products.Contains(p))
            {
                Products.Add(p);
            }            
            
            p.Category = this;
        }

In general, it is good to use a pattern like this to support adding/removing related items rather than using the relationship collection to add/remove related entities. You also have options of making the getter/setter for the actual EF backed collection private/internal to support more fine grained access – but as mentioned earlier, some of this depends on the requirements as to whether you require partial trust support or not.

So we have covered quite a bit of ground in this “quick look” at the overall POCO experience. There’s quite a lot more to talk about – and I will be continuing this discussion early next week. In the meantime, take a look at the complete solution (attached) if you are interested in the sample code covering all the concepts we covered here. Please keep in mind that you must have a local instance of Northwind database installed on the machine where you are running this sample.

In my next post we will look at Complex Types, Change Tracking, Proxies, Lazy Loading and Eager Loading. Until then, please look through the MSDN Documentation on POCO here for more details on POCO support in Entity Framework 4.0.

Let us know what you think!

Faisal Mohamood
Program Manager, Entity Framework

NorthwindPocoSamplePart1.zip

Comments

  • Anonymous
    May 21, 2009
    PingBack from http://asp-net-hosting.simplynetdev.com/poco-in-the-entity-framework-part-1-the-experience/

  • Anonymous
    May 21, 2009
    In LINQ, it has a CreateDatabase() method where I can create the database based on the POCO. Does EntityFramework have that kind of method?

  • Anonymous
    May 21, 2009
    Is there a way to use "HashSet<Product> Products" instead of "List<Product> Products" in the Category POCO?

  • Anonymous
    May 21, 2009
    Thank you for submitting this cool story - Trackback from progg.ru

  • Anonymous
    May 21, 2009
    @dmitry: HashSet<T> should work as it implements ICollection<T>.

  • Anonymous
    May 21, 2009
    9efish.感谢你的文章 - Trackback from 9eFish

  • Anonymous
    May 21, 2009
    Is partial table mapping supported via the use of defaults defined within the model? e.g: Table: Id int PK,           Col1 varchar(250) null,           Col2 bit not null I'd create the model to match the above but miss out Col2 and provide a default of null within the SSDL. My POCO would then just have the Id and Col2 properties. Is this possible?

  • Anonymous
    May 21, 2009
    I meant Col1 (in my above question) for the POCO property!

  • Anonymous
    May 22, 2009
    @Matt, for some reason HashSet/ISet does not work as an automatic property. The exception says something like "unable to to create property x for type y." It does work if you create a backing variable and initialize it. ICollection/IList and List all work fine with an automatic property.

  • Anonymous
    May 22, 2009
    Great article.   Towards the end of the article though, you wrote, "In the meantime, take a look at the complete solution (attached) if you are interested in the sample code covering all the concepts we covered here."   I don't see a link to the sample code anywhere though.  Can you point me to the location of the sample code download? Also, can anybody provide any references that show how to use generated entities (EntityObject) that support changes on the entity made after the context has been detached? Thanks, Rick

  • Anonymous
    May 22, 2009
    Thank you for submitting this cool story - Trackback from DotNetShoutout

  • Anonymous
    May 22, 2009
    Nicely done Faisal! well presented and explained. That was really an addition to existing documentation.

  • Anonymous
    May 22, 2009
    Hi Rick, I have fixed the issue with the attachment not being a part of the post. The post now has an attachment that you can download. -faisal

  • Anonymous
    May 22, 2009
    Since we shipped the .NET Framework 3.5 SP1 and Visual Studio 2008, we’ve been working on the next version

  • Anonymous
    May 24, 2009
    you are completely missing the point with the "generate from the DB"... POCO idiom is used in DDD, there is no reason to abstract the framework away with POCO once my goal is to "design" from the DB. And no ability to create the DB from POCO. And the designer is DB diagram not entity/POCO diagram. fail

  • Anonymous
    May 24, 2009
    Hi, Very nice post Faisal. So you are making it completely persistent one. Cheers! Thani

  • Anonymous
    May 25, 2009
    I don't understand why i have to provide a context implementation. Since I have a diagram definition, the framework must know how make the entity tracking using proxies without define ObjectSet<T>. I think that EF must use more the model definition to manage entities. By the momen, I prefer the NHibernate solution in this way.

  • Anonymous
    May 25, 2009
    @Savante, I don't think really have to "implement" the context implementation. If you look at the code the sample context does two things.

  1. Provides connection and container names into the base ObjectContext object.
  2. Caches an instance of the ObjectSet<T> in a public property for each entity type. There is really nothing model specific in it. Both the issues above could be resolved by implementing a context that works with any EF 4.0 projects. The derived object would get connection and container data from Web.Config and the mapping metadata and would pass it into the ObjectContext. It would also implement implement a method (for example) Set<T>() which would initialize and cache in a hashtable an ObjectSet<T> instance for each entity type. This context could be reused in any application without having to manually implement anything; and you would be able to access entity sets using "context.Set<Category>()". P.S. I agree with nhibernateuser that it would make more sense to generate designer mappings from the model and not the other way around.

  • Anonymous
    May 26, 2009
    Pick of the week: IP and Non-Competes for Employees General Visual Studio 2010 Beta 1 : Go get the first beta of the next version of Visual Studio! Microsoft Set To Announce Commercial Availability of Windows Azure at PDC This Year : Alin Irimie has some

  • Anonymous
    May 26, 2009
    Going through the changes in Entity Framework I must say MSFT really does take in feedback. I have been

  • Anonymous
    May 27, 2009
    Going through the changes in Entity Framework I must say MSFT really does take in feedback. I have been

  • Anonymous
    May 27, 2009
    @Brendan, We don't have plans for supporting partially mapped entity types in this release, but I certainly would like to hear what makes this feature important to you. -Diego

  • Anonymous
    May 27, 2009
    What about references in POCO types to general entities and vice versa.

  • Anonymous
    May 28, 2009
    In my post last week on the POCO Experience in Entity Framework , I covered the fundamentals of POCO

  • Anonymous
    May 29, 2009
    Is it possible to use the entity framework 4.0 in Visual Studio 2008? I hope MS does not expect us to keep buying a new IDE every 2 yrs ;)

  • Anonymous
    May 30, 2009
    Last week I mentioned in the sneak preview on POCO that support for POCO entities is one of the new capabilities

  • Anonymous
    May 30, 2009
    【译者按】 Entity Framework 1.0 发布也有一段时间了，但感觉用的人很少。其中一个很大的原因，也许就是不支持POCO。要知道，Entity Framework 1.0的做法是让你的实体从EF的基类继承而来

  • Anonymous
    May 31, 2009
    Will this code supported in this version of EF? var products = from p in db.Products                            select new Product                            {                                Id = n.Id,                                Name = n.Name                            }; I played with VS2010 Beta1 and this exception still occured while it is valid in LINQ to SQL: "The entity or complex type 'Demo.Product' cannot be constructed in a LINQ to Entities query."

  • Anonymous
    June 01, 2009
    #.think.in infoDose #31 (24th May - 1st June)

  • Anonymous
    June 03, 2009
    Introduction: From the moment I put my hands on Visual Studio.Net 2010 Beta 1 and I’m targeting EF4

  • Anonymous
    June 03, 2009
    Going through the changes in Entity Framework 4.0 I must say MSFT really does take in feedback. I have

  • Anonymous
    June 04, 2009
    Hi Can you, please, write a complete sample of generic repository and unit of work together, using EF.4.0

  • Anonymous
    June 10, 2009
    There are currently two ways to get Entity Framework apps up and running, we call these Database First

  • Anonymous
    June 12, 2009
    Hi. I've just tried the feature. Why can't i have some mapped properties in a base class and map to it's child where other mapped properties are contained? i keep getting " The required property 'Name' does not exist on the type 'EFTest.User2'. " while the property is just in the base class (if i override it it works ok). I understand why linq to sql can't support such a scenario, but can't see a reason why you don't. Can't you tune up you BindingFlags in the convention mapper ? :)

  • Anonymous
    June 14, 2009
    &#160; There are currently two ways to get Entity Framework apps up and running, we call these Database

  • Anonymous
    June 16, 2009
    If you have been watching this blog, you know that I have been discussing the various aspects of POCO

  • Anonymous
    June 17, 2009
    Usually I don’t really like generated stuff, somehow it seems like I always reach a certain point where

  • Anonymous
    July 12, 2009
    This looks like a great step forward (finally allowing POCOs for domain models w/ EF). I'm curious as to why properties cannot be virtual, though.  Unless I misread. NHibernate does it exactly the opposite way, where by default your properties should all be virtual to make it so they can generate subclassed proxies more easily and inject lazy loading and such.

  • Anonymous
    July 19, 2009
    I meant Col1 (in my above question) for the POCO property!

  • Anonymous
    August 04, 2009
    uni-directional relationships is supported, the only restriction is that I should delete the related end navigation property that is not needed! but how I can do so?

  • Anonymous
    November 10, 2009
    It is very good short paper and get the point precisely. Nobody complains "The unit tests are failed!". Pops up "InvalidOperationException was unhandled by user code". The solution is to add "Microsoft.CSharp" into the reference of NorthwindModel.

  • Anonymous
    December 01, 2009
    When try to test the example I'm always getting an ArgumentException in Public NorthwindContext() : base("name=NorthwindEntities" , "NorthwindEntities") telling me that the specified named connection is either not found in configuration, not intended to be used with the EntityClient provider, or not valid. How can I correct the problem and using the example code?

  • Anonymous
    December 12, 2009
    When selecting Category and Product for your model it is important to note that CategoryID needs to be removed from the Product table otherwise you get a MetadataException. The issue is because you POCO Product class does not define the property CategoryID

  • Anonymous
    January 05, 2010
    I keep getting this error message: "Mapping and metadata information could not be found for EntityType 'EfTest.Category'.". EfTest is my namespace. Anyone know how to fix this problem?

  • Anonymous
    February 11, 2010
    Hy, Joe. I lost many time to resolve issue like yours. And my problem was in two .edmx files in a single library. I move one to another library and now everything works fine. (I use POCO TT Code Generator; when I use normal codegenerator all my two models works fine in a single library). Also you can force load model from resources or files to objContext.WorkspaceMetadata (in constructor, for example) over XmlReader.

  • Anonymous
    April 29, 2010
    Following your example, when instantiating your NorthwindContext, it produces this exception at the CreateObjectSet<Category>() method: System.Data.MetadataException was unhandled Schema specified is not valid. Errors: The relationship 'NorthwindModel.FK_Products_Categories' was not loaded because the type 'NorthwindModel.Product' is not available. The following information may be useful in resolving the previous error: The required property 'CategoryID' does not exist on the type 'NorthwindModel.Product'.

  • Anonymous
    May 11, 2010
    hey also ensure tht you add connection string from app.config to your web.config.

  • Anonymous
    May 26, 2010
    Hi, I have a question - do I need to check "Pluralize and singuralize generated object names"? It seems that I should

  • Anonymous
    May 28, 2010
    Hi Faisal, It is nice article, but i have a query . How .csdl,.ssdl and msl metadata can be generated to work with POCO classes ? In one of the article i was reading, that has used nHibernate model and still useing csdl,ssdl and msl metadata(as i saw in connectionstring) , but edmx file was not there. SO how can we have these metadata files without including edmx file ? I am using VS 2010 with silverlight 4. Dhruv

  • Anonymous
    June 14, 2010
    Nice article.  I wrote an article on POCO performance where I do a comparison between POCO and  ordinary EntityObject based auto-generated classes.  The results are very interesting. The article is here: sharedtolearn.blogspot.com/.../entity-framework-40-poco-performance.html Alexandro Velarde

  • Anonymous
    August 12, 2010
    it would help a great deal if this code would run! I too am getting the meta data error.

  • Anonymous
    August 15, 2010
    Nice article. I came across while searching for the metadata error that 'codegrue' was running into. I just wanted to write how I resolved it for my situation. The error message that 'codegrue' posted includes the following  :   "The required property 'CategoryID' does not exist on the type 'NorthwindModel.Product'" I had like 10 of these errors and resolved them by simply doing what it is complaining about. For this example let's say I added a 'CategoryID' property to the POCO class Product to match the conceptual model. I needed to do it for the references as well. Like Faisal included 'Category' property to the Product and a 'list of Products' property to the Category. Once I added all the relations declared in the conceptual model section of the XML file, my application was running in the way it was supposed to. I haven't tried but if I don't want to have all of the relations in my POCO classes, removing the ones that I don't want from the conceptual model declaration might work as well. That might solve 'codegrue' s problem as well, I guess.

  • Anonymous
    September 08, 2010
    I am getting the following error: {"Mapping and metadata information could not be found for EntityType 'NorthwindModel.User'."} Any idea why...?

  • Anonymous
    September 23, 2010
    The comment has been removed

  • Anonymous
    September 25, 2010
    Do you have any ideas of this problem? The relationship '??' was not loaded because the type '??' is not available. The following information may be useful in resolving the previous error: The required property '??' does not exist on the type '??'. Can you provide me a solution ? (jycouet@gmail.com)

  • Anonymous
    December 05, 2010
    Can I use this (POCO with Entity Framework model) in .Net Framework 3.5?

  • Anonymous
    January 04, 2011
    "The required property 'CategoryID' does not exist on the type 'NorthwindModel.Product'" --> I just unchecked "Include foreign key columns in the model" and ot worked BUT The relationship was not loaded so my Category pointer is null (without any exception) Can you provider a hint

  • Anonymous
    January 10, 2011
    yes, relashionship loading d'ont work with me ! I use Include() function... it's good ?

  • Anonymous
    February 03, 2011
    For those getting the "Mapping and metadata information could not be found for EntityType 'EfTest.Category'." error, try removing the edmx and the app.config file then recreate the model, but make sure the "Pluralize or singularize..." checkbox is checked and the "Include foreign key columns..." checkbox is NOT checked.

  • Anonymous
    June 30, 2011
    Should, or could, ID properties be declared with protected or protected internal or even private access modifiers to ensure they are not modified outside the scope of the inheritance hierarchy, assembly, or class respectively?

  • Anonymous
    August 19, 2011
    Hi, I followed this example and it worked excellent. However, when I tried to use my own existing POCO from my existing layered architecture, I had to go through decorating class and its properties with below attributes. For class: [EdmEntityTypeAttribute(Name = "Corporation", NamespaceName = "WOTCSurveyModel")] For properties: [EdmScalarProperty(EntityKeyProperty = true, IsNullable = false)] [EdmScalarPropertyAttribute(EntityKeyProperty = false, IsNullable = false)] If I do not decorate my POCO - I get error with below message: "Object Mapping could not be found for Type with identity 'WOTCSurveyModel.Corporation'" This error continues to occur even after updating EDMX and synchronizing with underlying database. Below article explained what I needed to do. (Reference: mtaulty.com/.../9648.aspx) Why is that the sample POCO worked fine and for my own existing POCO I had to decorate? Please guide. Thank you.

  • Anonymous
    December 14, 2011
    I think that you should add "   public int CategoryID { get; set; }" to your Product class as follow: public class Product    {        public int ProductID { get; set; }        public string ProductName { get; set; }        public int SupplierID { get; set; }        public string QuantityPerUnit { get; set; }        public decimal UnitPrice { get; set; }        public Int16 UnitsInStock { get; set; }        public Int16 UnitsOnOrder { get; set; }        public Int16 ReorderLevel { get; set; }        public bool Discontinued { get; set; }        public int CategoryID { get; set; }        public Category Category { get; set; }    }

  • Anonymous
    February 29, 2012
    You guys ROCK! Just what I was looking for

  • Anonymous
    June 08, 2012
    Thanks for the information!

  • Anonymous
    May 07, 2013
    The comment has been removed

  • Anonymous
    May 08, 2013
    @ltheONEl - This post is ~4 years old and is built using an early preview of EF4. Visit http://msdn.com/data/ef for the latest information on current and past releases of EF.

  • Anonymous
    June 09, 2013
    Hi Mi question is: what i need install in the client pc after compile my project with entity framework?? i mean, what i need to  run the aplicattion (my .exe) on client pc?? thanks

  • Anonymous
    June 10, 2013
    @David - You'll need the version of .NET that your project targets to be installed on the machine. If you are using EF4.1 or later you will also need to copy the EF assemblies over (primarily EntityFramework.dll - a few extras if you are using EF6). These assemblies will already be copied to you output directory when you build.

  • Anonymous
    November 07, 2013
    how do use poco in framework 3.5

  • Anonymous
    November 08, 2013
    @Kumhar Ravi - POCO entities are not supported in EF1/.NET Framework 3.5. You need at least .NET Framework 4 where you could use EF4, EF4.x, EF5 for .NET Framework 4 or EF6 - all these versions support POCO entities.