Condividi tramite

EF 4.1 Release Candidate Available

  • Articolo

 

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.

 

We are excited to announce that Microsoft ADO.NET Entity Framework 4.1 Release Candidate (EF 4.1 RC) is now available. This is a fully supported, go-live release. In approximately one month we plan to release the final Release to Web (RTW). We are not planning any changes to the API surface or behavior between RC and RTW, the release is purely to allow any new bugs found in the RC build to be evaluated and potentially fixed.

 

What’s in EF 4.1 RC?

ADO.NET Entity Framework 4.1 RC introduces two new features:

  • The DbContext API is a simplified abstraction over ObjectContext and a number of other types that were included in previous releases of the ADO.NET Entity Framework. The DbContext API surface is optimized for common tasks and coding patterns. DbContext can be used with Database First, Model First and Code First development.
  • Code First is a new development pattern for the ADO.NET Entity Framework and provides an alternative to the existing Database First and Model First patterns. Code First is focused around defining your model using C#/VB.NET classes, these classes can then be mapped to an existing database or be used to generate a database schema. Additional configuration can be supplied using Data Annotations or via a fluent API.

 

Getting EF 4.1 RC

ADO.NET Entity Framework 4.1 RC is available in a couple of places:

 

Getting Started

There are a number of resources to help you get started with EF 4.1 RC:

 

NuGet Package Rename

Previous releases of Code First were made available as the ‘EFCodeFirst’ NuGet package. The EF 4.1 RC release contains features that are also applicable to Model First and Database First development, therefore we have chosen to adopt the ‘EntityFramework’ package name for this release, and future releases. If you are currently using the ‘EFCodeFirst’ package you will need to swap to the ‘EntityFramework’ package to get the supported go-live release. If you own a package that depends on ‘EFCodeFirst’ we would encourage you to swap the dependency over to the ‘EntityFramework’ package as soon as possible.

 

Support

This release can be used in a live operating environment subject to the terms in the License Terms. The ADO.NET Entity Framework Forum can be used for questions relating to this release. To contact Microsoft directly please send questions to ef41rc@microsoft.com.  

What Changed Since EF Feature CTP5?

The new features in ADO.NET Entity Framework 4.1 RC were previously included in Entity Framework Feature CTP5. The changes since Feature CTP5 include:

  • Rename of ‘DbDatabase’ to ‘Database’. This class has also moved to the ‘System.Data.Entity’ namespace, along with the database initializer classes.
  • Rename of ‘ModelBuilder’ to ‘DbModelBuilder’, to align with the other core classes.
  • Validation in Model First and Database First. The new validation feature was only supported in Code First in CTP5. In RC the validation feature will work with all three development workflows (Model First, Database First, and Code First).
  • Complete Intellisense docs. Feature CTPs were not extensively documented because the API surface was changing significantly between each release. This release includes complete documentation.
  • Removal of Code First Pluggable Conventions. Pluggable Conventions were previewed in Feature CTP5 but were not at go-live quality for this release. This release still supports the removal of default conventions.
  • Consolidation of IsIndependent in the Code First relationship API. When configuring relationships in Feature CTP5 the IsIndependent method was used to identify that the relationship did not have a foreign key property exposed in the object model. This is now done by calling the Map method. HasForeignKey is still used for relationships where the foreign key property is exposed in the object model.

 

What’s Not in EF 4.1?

There are a number of commonly requested features that did not make it into EF 4.1. We appreciate that these are really important to you and our team has started work on a number of them already, we will be reaching out for your feedback on these features soon:

  • Enum support
  • Spatial data type support
  • Stored Procedure support in Code First
  • Migration support in Code First
  • Customizable conventions in Code First

 

Thank You

It has been great to have so much community involvement helping us drive the new features in EF 4.1. We thank you for giving us your valuable input and look forward to working together on the next release.
 
ADO.NET Entity Framework Team

Comments

  • Anonymous
    March 15, 2011
    Thank you! I was waiting for this release. Ado.Net/Ef Teamis doing a great job. I think that if Entity Framework Core was separated of .NET Framework, we can have more features without wait for .NET 5

  • Anonymous
    March 15, 2011
    Very good news. Keep the good work!

  • Anonymous
    March 15, 2011
    Very glad to see this. Since this is an RC with a go-live I assume that the ability to map a code first context with unique constraints won't happen? Thanks!

  • Anonymous
    March 15, 2011
    Great stuff folks, I'm looking forward to trying it out. Lack of enum support is disappointing but you're aware of it, so that's good. Migration support - I'm interested in seeing your thoughts on how you see it working. What I would love would be to see a link between Entity Framework model / code first and Database Projects rather than the current way of simply generating a massive script. This would allow us to use EF to generate our models and DB projects to manage the databases that are generated as a result of that model.

  • Anonymous
    March 15, 2011
    Good work! +1 for what Issac has said about database management - that'd be a great idea. Plus;

  • Is there any work underway to officially support a 2nd level cache?
  • Are there any plans to support Data Service's Query/ChangeInteceptor attributes (they really should be in EF) Is it possible to at least give a ship vehicle for what you're working on? It's really difficult trying to bring teams/orginisations along with any techniical decisions not knowing plans. Especially when NHib is fairly mature in the above respects... I know this is all very complex, but the amount of time it's taking the team to ship Code First, enum support etc gives the impression that EF is dying, or at least that it's not worth MS putting enough resources onto the team.

  • Anonymous
    March 15, 2011
    That's great news! Is this bug fixed in this version ? weblogs.asp.net/.../huge-ef4-inheritance-bug.aspx

  • Anonymous
    March 15, 2011
    Looking forward to implement this into current and future projects. Will Code First RC run in medium trust environments?

  • Anonymous
    March 15, 2011
    I was very surprised to see that this code first release had reverted to using 'Id' for Id fields in the database rather than 'TableName + Id' and also that it reverted to using underscores in foreign key names with the default conventions - e.g. Customer_Id. Coupled with the lack of custom conventions support in code first this is a real nuisance. The last thing we want is to have to manually configure every Id and foreign key field in the database.

  • Anonymous
    March 15, 2011
    What about table-valued functions?

  • Anonymous
    March 15, 2011
    Correct me if I'm wrong... but til CTP5 I did'nt see any way to map to a non-public property (such as private or protected) as we can do using the ModelFirst approaching. Is it possible in this Release Candidate?

  • Anonymous
    March 16, 2011
    Is there going to be a new version of RIA services that work with code-first ?

  • Anonymous
    March 16, 2011
    Is there any more comprehensive list of the changes between CTP5 and RC? I've got a project that has a relatively large amount of effort put into it and converting it from CTP 5 to RC has so far been problematic. You can see two things I've run into over here: social.msdn.microsoft.com/.../threads Those might be something I did wrong, but it worked in the CTP 5 release and I'm just wondering if maybe there's a better list of changes to help me out here. Thanks!

  • Anonymous
    March 16, 2011
    thanks very much for sharing about this, I think it will be very helpful to my wesite <a href="http://www.neopower.hk">Voltage Stabilizer</a>,thanks, indeed. good luck for the programming team. good job.

  • Anonymous
    March 16, 2011
    Great, this does not help at all. Code first still without migrations? You should call it: Code first destroy your DB later.

  • Anonymous
    March 17, 2011
    Is there a way to extend an entity object and expose it through WCF data services?  I'd like to include a bool property in my entity that will indicate a logical state that is not from the database but calculated on the fly.

  • Anonymous
    March 17, 2011
    A tiny point, how come the default installation directory is in the x86 Program Files, rather than just Program Files? Perhaps it has 32-bit and 64-bit drivers so goes in the lowest common denominator

  • Anonymous
    March 17, 2011
    @Tim - It would be helpful if you linked directly to the post that describes your issues.

  • Anonymous
    March 17, 2011
    The comment has been removed

  • Anonymous
    March 18, 2011
    Thank you! I cannot wait to use it for my next project.

  • Anonymous
    March 19, 2011
    Our project is working great with CTP5. After referencing the new release it stopped working. I get this error: Schema specified is not valid. Errors: (2057,8) : error 0111: There is no property with name 'Employee_Id1' defined in type referred by Role 'SomeEntityName'. That is all I get from the Message, InnerException is null and the StackTrace is: at System.Data.Metadata.Edm.StoreItemCollection.Loader.ThrowOnNonWarningErrors()   at System.Data.Metadata.Edm.StoreItemCollection.Loader.LoadItems(IEnumerable1 xmlReaders, IEnumerable1 sourceFilePaths)   at System.Data.Metadata.Edm.StoreItemCollection.Init(IEnumerable1 xmlReaders, IEnumerable1 filePaths, Boolean throwOnError, DbProviderManifest& providerManifest, DbProviderFactory& providerFactory, String& providerManifestToken, Memoizer2&amp; cachedCTypeFunction) &nbsp; at System.Data.Metadata.Edm.StoreItemCollection..ctor(IEnumerable1 xmlReaders)   at System.Data.Entity.ModelConfiguration.Edm.Db.DbDatabaseMetadataExtensions.ToStoreItemCollection(DbDatabaseMetadata database, Action1 storeAction) &nbsp; at System.Data.Entity.ModelConfiguration.Edm.Db.Mapping.DbDatabaseMappingExtensions.ToMetadataWorkspace(DbDatabaseMapping databaseMapping, Action1 storeAction)   at System.Data.Entity.Internal.CodeFirstCachedMetadataWorkspace..ctor(DbDatabaseMapping databaseMapping)   at System.Data.Entity.Infrastructure.DbCompiledModel..ctor(DbModel model)   at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)   at System.Data.Entity.Internal.RetryLazy2.GetValue(TInput input) &nbsp; at System.Data.Entity.Internal.LazyInternalContext.InitializeContext() &nbsp; at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType) &nbsp; at System.Data.Entity.Internal.Linq.InternalSet1.Initialize()   at System.Data.Entity.Internal.Linq.InternalSet1.get_InternalContext() &nbsp; at System.Data.Entity.Internal.Linq.InternalSet1.Find(Object[] keyValues)   at System.Data.Entity.DbSet`1.Find(Object[] keyValues)   at A more descriptive error or additional details to the error would definitely help.

  • Anonymous
    March 19, 2011
    I guess Enum support in 5.0, maybe? It's a bit a deal breaker for us. Looks like we'll be heading down the NHibernate path :(

  • Anonymous
    March 19, 2011
    I found out where the problem is and I played around with RC1 and could not fix it. Again, the following code is working with CTP5: public abstract class Note    {        public virtual Guid Id { get; set; }        public virtual string Description { get; set; }            }    public class Note1 : Note    {        public virtual Employee Employee { get; set; }    }    public class Note2 : Note    {        public virtual Employee Employee { get; set; }    }  public abstract class Person    {        public Guid Id { get; set; }        public string FirstName { get; set; }        public string LastName { get; set; }                  } public class Employee : Person    {            public DateTime? DateOfBirth { get; set; }    } public class MyContext : DbContext    {        protected override void OnModelCreating(DbModelBuilder modelBuilder)        {            modelBuilder.Entity<Person>().ToTable("Person");            modelBuilder.Entity<Employee>().ToTable("Employee");            modelBuilder.Entity<Note>().ToTable("Note");            modelBuilder.Entity<Note1>().ToTable("Note1");            modelBuilder.Entity<Note1>().HasRequired(x => x.Employee);            modelBuilder.Entity<Note2>().ToTable("Note2");            modelBuilder.Entity<Note2>().HasRequired(x => x.Employee);        }    }

  • Anonymous
    March 19, 2011
    (sorry pressed Enter too soon) The problem is if I have more than one property referencing the same entity then EF will give the error: "error 0111: There is no property with name 'REFERENCED_ENTITY_Id1' defined in type referred by Role 'REFERENCING_ENTITY'" So, in the above code if I remove Note2 everything will work.

  • Anonymous
    March 20, 2011
    Hmmmm... No table valued function support, no enum support, no batch support,... That's what we asked for and we got code first. Code first looks good but I guess it could only use EF 4 available features?  Give us a timeline for EF.

  • Anonymous
    March 20, 2011
    @Amir : try to create an extension method, or define entity class as partial in the T4 template, so you can add  another code file for that class with the extra property.

  • Anonymous
    March 20, 2011
    Can we now expose our DbContext derived class directly in WCF Data Services or do we still need to expose it as ObjectContext & do our init in CreateDataSource override?

  • Anonymous
    March 20, 2011
    The comment has been removed

  • Anonymous
    March 20, 2011
    Do you have any plans to support mapping fields, not only props?

  • Anonymous
    March 23, 2011
    Add: Note: The NuGet package only includes the EF 4.1 runtime and does not include the Visual Studio item templates for using DbContext with Model First and Database First development. Where do I get item templates for using DbContext with Model First and Database First development than ?

  • Anonymous
    March 24, 2011
    Nice job guys. This is awesome, and a big step in the right direction.

  • Anonymous
    March 24, 2011
    @mynkow: We have a work item to add the ability to map to fields instead of properties in our backlog, but we have a bunch of other features that we are planning to do before, so I don't think this will happen very soon. Certainly not for EF 4.1.

  • Anonymous
    March 24, 2011
    @LyphTEC: Jeff posted an article that explains exactly how to do just that: blogs.msdn.com/.../using-wcf-data-services-with-entity-framework-4-1-and-code-first.aspx.

  • Anonymous
    March 30, 2011
    The comment has been removed

  • Anonymous
    March 30, 2011
    How has the connection string to define for accessing a Microsoft Access database instead of a SQL-Server?

  • Anonymous
    March 30, 2011
    I'd say this release is a big step to nowhere. Where did GenerateDatabaseScript method from CTP4 go? DbContext doesn't support compiled queries at all. No user-defined conventions supported. In previous releases you had absolutely no documentation plus you changed namespaces, assembly names, method names and class names every time you released a new CTP. That's how you do software development in MS? Don't just borrow ideas from NHibernate. Make your implementation work in corner cases by adding more unit-tests. Add not only examples of usage for nursery school kids, but the ones showing advanced concepts and scenarios. Can't come up with any - ask community to help you. When you see the solution to a problem developers had with EF, and the solution is an acrobatic code heavily relying on implementation details - that's what can be a target to create an example, showing why you EF have such problems, ways to solve them if any, and what you as framework developers can do to fix this problems in upcoming releases. From Russia with love, yours faithfully .NET developer

  • Anonymous
    March 31, 2011
    The comment has been removed

  • Anonymous
    March 31, 2011
    @Von: We were able to reprduce the issue you described and confirmed that it's a bug we introduced in the Release Candidate. We have a fix for RTM, but in the meanwhile here are a couple of alternative workarounds you can use with the RC:

  1. Move the the Employees navigation property to the base class.
  2. Rename the Employees navigation properties in on of the derived types so that they don't have the same name. Thanks a lot for raising this! Diego

  • Anonymous
    March 31, 2011
    @Torsten: there is no support for Access in EF. You would need to create your own EF compatible ADO.NET data provider for Access to get it to work. SQLCE and many other databases are supported, though. Here is a list of ADO.NET data providers with Entity Framework support: msdn.microsoft.com/.../dd363565.aspx   Diego

  • Anonymous
    March 31, 2011
    If I have POCO classes and DataTables in the same project, is there any possibility to create one model with a DBContext object? Is there a way to create POCO objects at runtime from DataTables/Datatable-Definitions?

  • Anonymous
    April 05, 2011
    When will this 10000 pound gorilla have encryption support? Funny how Microsoft says to use this for all your new projects when there are big pieces of functionality missing. Oh wait thats normal business.

  • Anonymous
    May 10, 2011
    We are started to use this Entity framework 4.1 rc thank u

  • Anonymous
    June 17, 2011
    This article contains disinformation around Enum supported in new EF 4.1 Candiadate Release. I've spent few hours doing few experiment in code and trying to figure out why it does not work. It turned out it's still not supported. Just have found: www.hanselman.com/.../EntityFramework41ReleaseCandidateWithGoLiveWithFinalReleaseToFollowInAMonth.aspx Hanselman says Enum support is not still in new EF 4.1 Candidate Release :(, so first link contains disinformation