Partager via


Entity Framework POCO Template updated for Visual Studio 2010 Release Candidate


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.


A refresh of the POCO Template that is compatible with Visual Studio 2010 Release Candidate is now available in the Extension Manager of Visual Studio and through Visual Studio Gallery.

For an introduction on how to use the template, please see the POCO Template Walkthrough (no updates have been made to the walkthrough for this version).

The RC compatible version of the POCO Template contains all the improvements made in the Beta 2 compatible version, including generated code improvements, relationship fixup, foreign keys, etc. In addition, the new version includes additional but fixes and compatibility with ASP.NET Web Site projects. 

There are now four different versions of the template:

  1. The standard VB version is here
  2. The standard C# version is here.
  3. A new version for VB ASP.NET Web Sites is here.
  4. A new version for C# ASP.NET Web Sites is here.

Note that the POCO Template is not going to be part of Visual Studio 2010 in RTM. Instead the current plan is to continue delivering updates for it through the Extension Manager and Visual Studio Gallery.

Known issues in this version

  1. Running a query with Include and MergeOption equal to NoTracking may cause an exception: There is a problem in the interaction between the implementation of relationships fixup code in classes generated by the POCO template and the change tracking POCO Proxies enabled by the POCO Template.  We are currently investigating this issue.
  2. Detach can cause nullable foreign keys properties to be nulled: The implementation of relationship fixup cannot distinguish the reason an entity is being removed from an object graph. When Detach is applied to an entity that is related to others through foreign key associations, fixup logic will react to references being nulled and elements being removed form collections and will set the corresponding FK properties to null. We are currently investigating this issue.
  3. The AssociationChanged event can be raised twice: The AssociationChanged event is raised twice with CollectionChangeAction.Add when fixup occurs in the model such that a collection is modified. We are currently investigating this issue.
  4. Cascade delete rules are not triggered with FK-based self-referencing associations: If you define an FK association for entity with other entities of the same set (i.e. each Employee entity has a Manager and a ManagerID property that point to another Employee) and you define an OnDelete Action=”Cascade” rule in the association, dependent entities won’t be automatically marked as deleted when the principal is deleted. 

Note that the Beta 2 compatible versions are no longer available in Visual Studio Gallery. If you still need a version for Visual Studio 2010 Beta 2, you can temporarily find it attached to the original announcement.

Your feedback is welcome

If you run into any problem or limitation with the POCO Template, please enter a bug or suggestion through the Microsoft Connect site for Entity Framework.

You can also provide feedback or ask your questions in the Entity Framework Pre-Release Forum.

Diego Vega,
Entity Framework Team

Comments

  • Anonymous
    February 18, 2010
    What the different from four template version? And we can't use Beta 2 compatible versions a in Visual Studio Gallery. Thanks

  • Anonymous
    February 18, 2010
    Hello Jacob, Visual Studio Gallery and Extension Manager requires that each item template extension contain a single item template. There are two major differences among the four versions of the template: the language of the generated code (C# or Visual Basic), and Web Site projects vs. standard projects. ASP.NET Web Sites require slightly different item templates, so we had to create them and make them available separately. There is also a functional difference between the standard templates and the Web Site templates: while the standard templates generate separate entity types in separate source code files, this is not supported in Web Sites and therefore all the code is generated in a single file. I hope this answers your question. Thanks, Diego

  • Anonymous
    February 18, 2010
    I want to use IoC with my app. so need to make the POCO classes implement some inferfaces. Any easy way I can achive this?  Any walk through for me to follow? What I want is just like the Kigg sample app on asp.net website. Thanks.

  • Anonymous
    February 19, 2010
    Hello Eric, If your classes are going to implement those interfaces always, and you want to keep the ability to generate your classes from the model automatically, the best approach would probably be to customize the T4 template to add the interfaces. There is a walkthrough for that here: http://blogs.msdn.com/adonet/archive/2009/07/22/customizing-t4-templates.aspx On the other side, different partial class source files can specify different base interfaces, and the final type implements all of the interfaces listed by all of the partial declarations. Since the POCO Template generate partial classes for entities, you can simply add a new part source file for an existing entity and specify that it implements your interface. The compiler will merge both definitions of the entity type, the one that is generated by the POCO Template and the one that you provided. Finally, if you are ok with losing the ability to sync automatically the generated code with the model, and it is important to you to keep the entity types as simple and self-contained as possible, then you could simply take the code generated by the template as a starting point, copy it to another class file and then remove the template. From there you can manually customize your POCO types in whatever way you need. Hope this helps, Diego

  • Anonymous
    February 19, 2010
    I am unsure if it is intended, but something that works in the Entity Framework, which I actually like, but I wish to 'verify' a bit more. If I create my POCO objects in different namespaces, as long as the ObjectContext maps to the right objects, they still work - even if the namespaces do not match up in the Entity Map. Is this intended, or am I breaking something here? It's extremely convenient to be able to separate objects by namespaces like that - but it seems 'iffy' to me that it's letting me do it.

  • Anonymous
    February 21, 2010
    Which template do we use for ASP.net MVC?

  • Anonymous
    February 23, 2010
    When I tried to generate self tracking poco entities, I got this error Error 1 Compiling transformation: The type or namespace name 'TemplateFileManager' could not be found (are you missing a using directive or an assembly reference?) Error 2 Compiling transformation: The name 'TemplateFileManager' does not exist in the current contex

  • Anonymous
    February 24, 2010
    Perhaps this is a silly question, but is it going to be possible to either precompile the proxy classes, or maybe "link" the pocos/STEs to another "fully-featured" pregenerated type like entityobject/complexobject?

  • Anonymous
    February 25, 2010
    @Derek This is intentional. You can put your POCO classes in whatever namespace you'd like. The Entity Framework's by convention mechanism for detecting which properties on the entity match the properties of entities in your model does not use Namespace. What matters is that the type name (without namespace) matches the EntityType name in your model (edmx/csdl file). One area to watch out for is if you have multiple types with the same name but in different namespaces. Because we don't account for namespace, we detect that we've found multiple types and we throw an exception. Jeff

  • Anonymous
    February 25, 2010
    @Stevphen For ASP.NET MVC projects you should use the regular POCO C# or VB template. All MVC projects are currently defined as "Web Applications", not "Web Sites" so you don't need to worry about the Web Site POCO template. Jeff

  • Anonymous
    February 25, 2010
    @Hien The TemplateFileManager was renamed between the Beta2 and RC versions of the POCO template. Is it possible that your project contained the Beta2 template and you upgraded your project to RC? If that is the case, you should download the RC version of the template and re-add this version of the template to your project. This will give you a template with the current name of the file manager. Jeff

  • Anonymous
    February 25, 2010
    @Pradley Right now the proxy mechanism is not that extensible and so there is no way to do what you are asking. What we'd like to enable going forward is the idea that you can tell EF to use a factory method to create your entities. In this factory method, you can have it return your own type as long as it derives from the type EF cares about. This way you could create your own proxies / type links. Unfortunately that will have to wait until a release beyond VS 2010. For now, the best bet to augment the POCO classes is to subscribe to the ObjectContext.ObjectMaterialized event. In this event handler you can insert whatever you'd like into your class instance (but it has to remain the same type). Jeff

  • Anonymous
    February 25, 2010
    Hmm...Anyway that I can help making that happen :)? That said, how much performance am I actually losing by using reflect emit?

  • Anonymous
    February 27, 2010
    @Pradley You won't have to use reflection or reflection.emit to do this. What I would suggest is to create your own base class or implement your own interface that has the contents of what you want to inject. For example, let's say you want to inject the ObjectContext instance as an object reference (to keep things POCO): IEntityWithContext {   object Context { get; set; } } class Customer : IEntityWithContext { ... } In your derived ObjectContext class, you can do something like this: partial class MyContext : ObjectContext {   public MyContext()   {      this.ObjectMaterialized += InjectContext;   }   private static void InjectContext(                    object sender,                    ObjectMaterializedEventArgs args)   {      ((IEntityWithContext)args).Context = sender;   } } I am not sure what you meant when you suggested something with Reflection.Emit. In general, Reflection.Emit code that is compiled has very good performance. Jeff

  • Anonymous
    March 01, 2010
    Oh, I was actually talking about how generating the proxy classes uses reflection emit - yeah it would just be nice to basically keep those generated types around...

  • Anonymous
    March 01, 2010
    I am really liking the changes with the new Entity Framework. It really seems to be heading in the right direction. Something that would be overwhelmingly useful would be to enable the ability to ATTACH a database post-model design. Is that possible? When developing the POCO classes, it's very useful to build the structure and then build the database, then build the model and attach it - the 'autogeneration' feature is 'neat', but it still does a few things that are a little frustrating to work with.

  • Anonymous
    March 02, 2010
    What happen???? Error 1 Running transformation: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Unable to locate file   at Microsoft.VisualStudio.TextTemplating.VSHost.TextTemplatingService.ResolvePath(String path)   at Microsoft.VisualStudio.TextTemplating.VSHost.TextTemplatingService.ResolvePath(String path)   --- End of inner exception stack trace ---   at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner)   at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner)   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)   at Microsoft.VisualStudio.TextTemplatingE78BCB29E8D7A2F9432A449161229C3F.GeneratedTextTransformation.DynamicHost.ResolvePath(String path)   at Microsoft.VisualStudio.TextTemplatingE78BCB29E8D7A2F9432A449161229C3F.GeneratedTextTransformation.MetadataLoader.TryCreateEdmItemCollection(String sourcePath, String[] referenceSchemas, EdmItemCollection& edmItemCollection)   at Microsoft.VisualStudio.TextTemplatingE78BCB29E8D7A2F9432A449161229C3F.GeneratedTextTransformation.MetadataLoader.CreateEdmItemCollection(String sourcePath, String[] referenceSchemas)   at Microsoft.VisualStudio.TextTemplatingE78BCB29E8D7A2F9432A449161229C3F.GeneratedTextTransformation.MetadataLoader.TryLoadAllMetadata(String inputFile, MetadataWorkspace& metadataWorkspace)   at Microsoft.VisualStudio.TextTemplatingE78BCB29E8D7A2F9432A449161229C3F.GeneratedTextTransformation.TransformText()   at Microsoft.VisualStudio.TextTemplating.TransformationRunner.RunTransformation(TemplateProcessingSession session, String source, ITextTemplatingEngineHost host, String& result) 1 1

  • Anonymous
    March 08, 2010
    The comment has been removed

  • Anonymous
    March 17, 2010
    The comment has been removed

  • Anonymous
    March 27, 2010
    The comment has been removed

  • Anonymous
    March 27, 2010
    The comment has been removed

  • Anonymous
    April 03, 2010
    The comment has been removed

  • Anonymous
    April 12, 2010
    Hi, I am writing WCF+REST+using POCO entity model code is generated by POCO code generator (recently downloaded 12th April). I have only one table in my model. When I try to fetch this table using WebGet, WCF REST simply doesn't show anything. for this I have to do following:-

  1. context.ContextOptions.LazyLoadingEnabled = false; before running the query.
  2. Remove the virtual keywords from POCO class's data-members. Without doing above two, REST-WebGet does not work. My queries are:- Q1. if my model has only one entity, then why step 1 (mentioned above) is required. Q2. Why it is mandatory to remove virutal keyword, as if some later point of time i want lazy loading enabled, I would have to write another entity class with virtual members for same db entity. Please suggest.
  • Anonymous
    September 09, 2010
    Hien, Please visit blog.vuscode.com/.../using-the-entity-framework-poco-template-with-vs2010-rc-easier-way.aspx for the TemplateFileManager fixer upper.

  • Anonymous
    May 05, 2011
    Hi there, I've been experimenting with the latest version of the ADO.Net POCO Entity Generator templates (as well as the DbContext, EntityObject and Self-Tracking generators), but the POCO generator seems to miss out the generation of Function Imports that have a return type of "None". Specifically, I have a stored procedures that have output parameters for boolean return result. Returning a recordset is not really the route I wanted to go down. It seems to generate fine with all of the other templates, but their implementations aren't really what I'm looking for for my business layer. I'd really like to use the POCO generator, but this specific missing feature will create me a lot of work. For the time being, I'm going to see it'll be easy to modify the .tt files to include these functions, but I thought I would report it as a bug.