With the release of Microsoft Visual Studio 2010 coming up, we thought it would be useful to highlight some notable features & bug fixes coming out in the new release of the Entity Data Model Designer.  We divided these into "Big Features", "Little Features" and "Notable Bug Fixes".  In some cases, there are more in-depth docs & blog posts on the subject, so we've tried to link to as many of these as possible.  As always, we're very interested in what you think, so please let us know via the EF Forums. 

Big Features
The "Big Features" are some feature areas that added compelling new functionality to the Entity Designer experience.

Model First
The "Model First" feature lets you design a conceptual (CSDL) model in the Entity Designer, and then generate the storage (SSDL) model, as well as the mapping (MSL) between these.  In addition, we also generate T-SQL scripts to create the database for you.  To run the Model First wizard, just right-click on the Entity Designer surface, and choose "Generate Database from Model…".  There's an in-depth blog post here. 

One of the key goals of the Model First feature was to give users the ability to customize the database generation process.  We have released some examples of how this customization works.  In particular, this extension pack adds support for different, customizable inheritance strategies as well as integration with some of the powerful schema & data migration APIs found in Visual Studio 2010.  We published a walkthrough for the examples.  Check it out!

Complex Type Support (Including Refactoring)
One of the first things we did for V2 was add support for complex types.  Version 1 of the EF Runtime supported complex types, but due to schedule & resource constraints, we couldn't support them in V1 of the designer.  Now with V2, the designer lets you define complex types, view complex types in the model explorer tree, and refactor existing properties into a complex type.

Foreign key support/Referential Integrity Constraint support
V2 of the EF runtime adds support for foreign keys (FKs) in the conceptual model, and we extended this support into the Entity Designer.  When your app is targeting .Net 4.0, you can optionally include FK columns in your conceptual model.  If you include FKs, you must specify referential integrity constraints that map an FK column to a primary key (PK) in another entity.  These constraints obviate the need for mapping associations.

Adding custom code-gen templates
Users can now customize the code-generation process by adding custom templates to a project; just right-click the designer surface in VS and choose the "Add Code Generation Item".  There are two code-gen templates that ship with VS 2010: the standard "ADO.Net EntityObject Generator" and the new "ADO.Net Self Tracking Entity Generator" (more on the latter here).  Both options add T4 template files to your project.  Once included in your project, you're free to customize these templates as you see fit. 
 
If you want to make your own customizable code-gen templates available to others, the designer supports this as well; just create a Visual Studio Item Template, and make sure that the .vstemplate file name starts with the string: "ADONETArtifactGenerator_".  This naming convention is how the designer identifies the code-gen templates to display.  Your template will show up in the dialog box when users choose "Add Code Generation Item" from the Entity Designer surface. 
 
Multi-targeting support
We wanted customers to have a first-class designer experience, regardless of whether their application was targeting .Net 3.5 (i.e., V1 of the EF),  or .Net 4.0 (i.e., V2 of the EF).  If your application is targeting .Net 4.0 & you try to open an EDMX file from EF V1, we will prompt you to upgrade your EDMX.  If your app is targeting .Net 3.5 and you open a V2 EDMX, we prompt you to downgrade your EDMX.  When downgrading, if you're using some V2 concepts in your EDMX (e.g. FKs), then you may end up with errors.  But overall, the upgrade experience should be pretty smooth. 

We also ensure that certain user gestures & affordances are only enabled if the project is targeting a .Net version that supports those gestures.  For example, Foreign Key support only works when targeting .Net 4.0.  It then follows that when targeting .Net 3.5, the FK affordances are disabled (a tooltip will display to explain why).  If you're upgrading or downgrading, let us know how it works for you.  

Designer Extensibility
During this release, we took some time to define an extensibility model for the EF Designer.  There are three basic ways for a user to extend the designer:

 1. Extending or customizing the model first process
 2. Adding custom code-generation templates
 3. Programmatically via designer extensibility APIs

We already discussed the first two above, so we'll briefly touch on the programmatic extensions here.  They're based on a new .Net 4.0 component model called the Managed Extensibility Framework (MEF for short).  Programmatic extension authors write MEF components, and then package & deploy them as a VSIX file.

There are three things you can do with the Designer extensibility APIs:

 • Participate in the model-generation & update-model-from-database processes
 • Display custom properties in the property window for the Entity Designer
 • Customize the serialization of the EDMX file

The APIs are all documented, and we've put together a starter kit to get you on your way quickly.  For a more in-depth example, see a previous blog post illustrating how to add custom namespaces into your generated code.    

Little Features
Here are some smaller features that were implemented for this release.

Stored procedure return type sensing
The Entity Designer now detects the columns returned by a stored procedure and can generate a complex type from these columns. In addition, when a stored procedure changes, the EF Designer can synchronize the definition of the complex type with the updated stored procedure.  This includes handling renames of properties in the corresponding complex type.

Controlling view keys from the model
The EF requires that all entity types in a model specify one or more properties that make up the type’s key. The reverse engineering logic that creates an entity type from a view has to guess about what these key properties are.  Specifically, we guess that any non-nullable column in the view is part of the key.  Often this guess is incorrect.  In VS 2010, when setting the key properties on an entity type that is mapped to a view, the EF Designer pushes those key-changes to the key definition on the view in the storage model.  This allows users to focus on the design of the conceptual model without worrying about the store model.

Delete Unmapped Tables and Views
In V1 of the Entity Designer, when a user deleted an Entity Type, only the conceptual-side (CSDL) type was deleted; the storage-side (SSDL) type was left in the model.  This subsequently caused confusion for users when the Update Model from Database wizard failed to recreate those previously-deleted CSDL types. Our implementation assumed that since the table was still present in the SSDL, the delete on the CSDL was intentional, and no new CSDL type was created.  With VS 2010, deleting a CSDL Entity Type offers users the choice of also deleting any corresponding SSDL tables and/or views.  If a user accepts, future runs of the Update Model wizard will recreate those previously-deleted CSDL entities (if the user chooses to add back those tables or views).

Improved control over property facets from the property sheet
A "facet" is a bit of data about a CSDL Property or SSDL Property.  Examples include "Nullable", "MaxLength" and "IsUnicode".  In V1 of the designer, it was not possible to disambiguate between a value not being present in the source, and a value having an empty string.  This caused problems with some facets such as DefaultValue.  In this release, we have added the ability to specify “(None)” as an option for many facets, which will result in that facet’s XML attribute being removed from the document. This feature also, then, provides the ability to specify an empty string as the value for string facets.

Navigation property management (add/edit/delete)
In some cases, most notably with hand-written POCO classes, including navigation properties on both sides of an association is either difficult to implement, or it does not match the desired programming model.  With VS 2010, users can delete navigation properties, essentially making some associations uni-directional.  To make the feature symmetrical, users can also add and modify navigation properties.
 
Added Search to the Model Browser
VS 2010 includes a searchable Model Browser.  The browser now allows you to search for elements of a particular name. All results are highlighted, and the previous/next buttons allow easy navigation from result to result.

Notable Bug Fixes
Can't Open EDMX File!!!
After the first version of the designer shipped, we started hearing reports about users double-clicking the EDMX file in VS expecting the designer, but nothing would happen - that is, the EDMX file wouldn't open.  We were never able to reliably reproduce the problem in house.  Luckily, one of our customers was able to reliably reproduce the problem, and he was kind enough to help us.  Thankfully, this is fixed in VS 2010.
   
Layout Performance Fix
V1 of the Designer had some particularly pitiful layout performance for models with a large number of entity types.  Investigating this during VS 2010, we noticed that that the performance problems were avoided when the initial shape positions didn't overlap.  After digging around a bit, we realized that by initially positioning shapes along a diagonal, layout performance was significantly improved.  Are you experiencing performance issues with the EF Designer?  If so, let us know.  We want to understand your scenario.

Xml End-Tag Fix
We heard from customers that placing all those XML end-tags on the same line was really annoying, so we got this fixed.  Easy, right?  Turns out, not really.  The Entity Designer is built over the Visual Studio XML Editor.  The VS XML Editor has a powerful API that supports editing of an XML DOM, while maintaining "text fidelity" with the underlying source.  "Text fidelity" is a fancy way of saying changes pushed from the in-memory DOM to the underlying source buffer only update a small section of the buffer.  In particular, things like insignificant whitespace, singleton tags, & XML comments are preserved.  Moreover, the system doesn't need to reparse the entire file (which is a big deal for XML files, as they can become very large).  It turns out that adding new lines between end tags flushed out some subtle bugs in how the XML Editor handled whitespace.  But, we got these issues resolved, and now new end tags are all placed on their own line.  We hope that this will help you in many SCC scenarios.

Incremental Build
We used to re-deploy EDMX files (if any of the files were set to produced embedded output resources) regardless of whether anything had changed in the model. This unnecessarily initiated other build actions, and for some large projects, these extra build actions could take some time. In VS 2010, we updated our EntityDeploy build task to only deploy when the model has changed.

Thanks!
I think that gives a pretty good overview of notable Entity Desinger changes coming in VS 2010.  Thanks for reading, thanks for using our software, and thanks for providing feedback.

Yours truly,

The EF Designer Team