This spec covers the changes and minor update required for the EF tooling to work well with EF6. New features are covered in separate specs.

 

Branding/Installation

We will be branding the tooling that we ship in EF6 as 'Entity Framework Tools'. The switch from ‘Entity Framework Designer’ (used in EF5) to ‘Entity Framework Tools’ reflects that our MSI will eventually contain more than just the ‘EF Designer’ (the boxes and lines designer) and will include tooling for Code First models etc.

We will be producing two separate MSIs - one for Visual Studio 2012 and one for Visual Studio vNext.

  • The product names will be:
    • Entity Framework Tools for Visual Studio 2012
    • Entity Framework Tools for Visual Studio <tbd>
  • The two installers will have separate product ids and upgrade codes so that they can both be installed on the same machine (a.k.a. side-by-side install)
    • The VS2012 version will upgrade (a.k.a. replace) the EF Tools that we shipped in Visual Studio 2012
    • The VSvNext version will be included in the RTM of VSvNext.
    • Installing the VSvNext tools (included in VSvNext) will not affect the tools that were included in VS2012. (Upgrading the tools in VS2012 is only done on an opt-in basis by downloading and running the installer)
  • Although they are two separate MSIs and the product binaries will be installed to different directories they are essentially both the same product - just compiled against different versions of Visual Studio binaries etc. with some minor differences to work with the different VS APIs.

Although the tooling is considered part of the EF6 release the product/assembly version number will be 12. This is because the previous version of the tooling used the Visual Studio version number (11). We aren't going to use 12 as the version in branding etc. because it is confusing to release runtime version 6 and tooling version 12 as part of the same release of one product.

 

EF Designer Supported Version Combinations

The following combinations are supported for both VS2012 and VSvNext

Project .NET Framework Version

Supported Scenarios for Opening Models

Creating New Models

.NET 4.5 or higher

  • EF6
    • DbContext code gen (T4 based)
    • We should disable/remove the legacy Code Gen dropdown since built in code gen won't work for EF6 models and we are only planning to support T4 based code gen going forwards.
    • Open Issue: Do we want to provide T4 ObjectContext code gen? Probably not in-the-box but we should consider shipping T4 templates on VS Gallery.
  • EF5
    • DbContext code gen (T4 based)
    • (1) ObjectContext code gen (T4 or legacy non-T4)
  • EF4.3
    • (2) DbContext code gen (T4 based)
  • EF4.2
    • (2) DbContext code gen (T4 based)
  • EF4.1
    • (2) DbContext code gen (T4 based)

Where T4 code gen is specified the developer could also be using a custom T4 template that targets the same API. I.e. the STE template also counts as T4 ObjectContext code gen. There are also a number of third party templates for DbContext and ObjectContext.

(1) Regradless of whether an EF NuGet package is installed and what version it is, if ObjectContext code gen is being used then the model is considered to be EF5. This is because the model can make use of EF5 features - spatial, enums, etc.

(2) This is supported but if the developer makes use of EF5 features - spatial, enums, etc. - then code gen will fail. We do not try to prevent this.

High Level Goals

  • New models always default to DbContext code gen
  • We want to encourage people to use the latest version of EF
    • We will not automatically upgrade the EF version they are using

 

Challenges

 

High Level Design

  • Only one version of EF can be used per project.
    • If a version if already installed, we will use that.
    • If no version is installed, we need to decide which version to install based on whether the developer has a provider that can support EF6.
  • We will select the appropriate code generation template for the EF version they are using (required because EF5 code gen templates will generate code that won't compile against EF6 and vice versa).
    • The implementation of this actually works the other way around - when we add the code gen templates they will take care of installing the matching version of EF if there isn't already a version installed.

 

When Version Detection/Selection Occurs

  • Generate from Database: after the user has specified the connection that they are reverse engineering from.
  • Empty Model: when generating the database from the model after the connection has been specified.
    • This is a change in behavior because code generation will no longer occur on the model until the database has been created.
    • Open Issue: We should investigate having the ability to specify provider during creation of model

 

No Existing EF Version in Project:

  • This scenario is detected by the absence of references to EntityFramework.dll and System.Data.Entity.dll
  • If there is an EF6 provider installed for the database the user has chosen to target we will default to installing EF6.
    • For early previews EF6 provider detection will just be SQL Server and SQL CE.
    • The developer will have the option to switch to EF5.
    • Open Issue: We need to work out the technicals of dealing with just an EF6 provider being installed and no EF5 provider.
  • If there is no EF6 provider the version dropdown will be displayed with EF5 selected and EF6 will be greyed out.
    • A message explaining why EF6 cannot be chosen will be displayed.

 

Existing EF Version in Project:

  • If the version is EF6 we will add the EF6.x code generation templates to the new model.
  • If the version is pre EF6 (EF4.1-EF5) we will add the EF5.x code generation templates to the new model.
    • This works because the EF5 templates will generate code that will also compile and run with EF4.1-4.3.
    • We won't add the EF4.x code generation templates because it provides no benefit over using the EF5.x templates and causes 120 extra items in our setup (C#/VB x App/WebSite x 10 languages x 3 VS SKUs). The 4.x templates also weren't localized.
  • If the existing version is EF5 without EntityFramework.dll referenced (see (1) in column to left) then we will also add the EF5 NuGet package to the project (this actually happens by default because the 5.x code gen template installs the EF5 NuGet package if no EF package is installed).
  • Open Issue: Do we want to show a screen to let the user know our reasoning for choosing the EF version and how they can upgrade.

 

Open Issue: We could also add a feature to automate upgrading (both during model creation and for existing models)

    • Update NuGet package and update existing models to new code gen.
    • Code First models shouldn’t need any changes because the types used to create the model haven’t moved.
    • When upgrading to EF6 the app code may need to change to reflect core types moving to a new namespace. We probably wouldn’t try and help with this.

.NET 4

  • EF6
    • DbContext code gen (T4 based)
  • EF5
    • DbContext code gen (T4 based)
  • EF4.3
    • DbContext code gen (T4 based)
  • EF4.2
    • DbContext code gen (T4 based)
  • EF4.1
    • DbContext code gen (T4 based)
  • EF4
    • (1) ObjectContext code gen (T4 or legacy non-T4)

Where T4 code gen is specified the developer could also be using a custom T4 template that targets the same API. I.e. the STE template also counts as T4 ObjectContext code gen. There are also a number of third party templates for DbContext and ObjectContext.

(1) Regradless of whether an EF NuGet package is installed and what version it is, if ObjectContext code gen is being used then the model is considered to be EF4. This is because the model is only using features and types in EF4.

Same as .NET 4.5 except that if EntityFramework.dll isn't referenced then existing models are actually targeting EF4 rather than EF5. We still do the same thing though (target EF5) because the EF5 NuGet package can safely be installed without affecting any existing models.

.NET 3.5 SP1

  • EF3.5 SP1 (also known as EF1)
    • Non-T4 ObjectContext code gen

Create a new model that uses built-in (non-T4) ObjectContext code generation to target EF that was included in .NET 3.5 SP1.

Last edited Apr 5, 2013 at 8:05 PM by RoMiller, version 2

Comments

No comments yet.