ADO.NET team blog : EDM

Sneak Preview: Model Defined Functions

dpblogs — Thu, 14 May 2009 22:31:00 GMT

Model Defined Functions is a new feature coming in .NET 4.0. They are similar to SqlServer Table Value Functions because they are composable, so you can layer function calls and queries. The key difference is that they are declared in terms of the conceptual model, rather than the storage model so they are defined in eSQL not T-SQL.

Model Defined Functions are useful if you want to encapsulate some commonly used eSQL in a function, for example something that calculates a person’s age.

To create a function that does that all you do is add something like this to the CSDL under the Schema element.

<Function Name="GetAge" ReturnType="Edm.Int32">
     <Parameter Name="Person" Type="Model.Person" />
     <DefiningExpression>
           Edm.DiffYears(Edm.CurrentDateTime(), Person.Birthday)
     </DefiningExpression>
</Function>

Notice that the DefiningExpression can be any valid eSQL expression that matches the expected ReturnType. Parameters, like Person, are referenced directly in the eSQL by name, without an @ symbol.

With this definition in place you can use it in eSQL queries immediately like this:

SELECT VALUE(P) FROM [MyEntityContainer].[People] 
AS P WHERE Namespace.GetAge(P) > 35

If you want to use the function in LINQ you need to have a corresponding CLR method that you can call. Essentially this is just a method stub too, something that has the same type signature, i.e. a function that takes a Person and returns an int.

[EdmFunction("Namespace", "GetAge")]
public int GetAge(Person p)
{ 
    throw new NotSupportedException(…);
}

Here the EdmFunction attribute allows the Entity Framework to map calls to this function in a LINQ expression back to the Model Defined Function.

With this in place the Entity Framework can translate the LINQ query below into something that can run completely in the database.

var results = from person in ctx.People
              where GetAge(person) > 35
              select person;

This simple example barely scratches the surface of the sorts of things you can do with Model Defined Functions.

Look out for a more in depth post on Model Defined Functions soon.

- Alex James
Program Manager, Entity Framework

Sneak Preview: Model First in the Entity Framework 4.0

dpblogs — Wed, 13 May 2009 01:52:38 GMT

An exciting new Entity Framework Designer feature in Visual Studio 2010 is the ability to generate DDL that will create a database that can store your entity data model. This feature is not only exciting because it brings a long overdue capability to life, but because it is fully extensible: You can take control of the entire process, or plug into parts of it. For example, you can take over the DDL generation step to add support for your database of choice, or to customize the DDL generation process. Alternatively, you can take over the inheritance mapping step and replace our out-of-the box strategy (which is table-per-type) with your own. Or take over the entire mechanism and generate both stored procedure mappings and CRUD stored procedures for all your types. In a future post, we will show you exactly how to do this and provide an implementation of the table-per-hierarchy mapping for you to use or modify.

For now, let’s take a quick look at this feature by taking a very simple model:

We right click…and in the context menu we see, and click on, “Generate Database Script from Model”:

The database generation wizard asks for a database to target. This information is used by the wizard to determine which database-specific types to translate the Entity Data Model (EDM) types to, and how to render DDL that is appropriate for the target database. In this case, I just created a new Microsoft SQL Server database file:

Once we click on next, we are shown a preview of the generated DDL, which will be saved to disk once we click on “Finish”. Here is an excerpt from the DDL generated now for SQL Server:

…
-- Creating table 'IngredientSet_Protien'
CREATE TABLE [dbo].[IngredientSet_Protien] (
    [Cut] nvarchar(100)  NOT NULL,
    [Type] nvarchar(70)  NULL,
    [Id] int  NOT NULL
);
GO
-- Creating table 'IngredientSet_Plant'
CREATE TABLE [dbo].[IngredientSet_Plant] (
    [IsFruit] bit  NOT NULL,
    [IsHerb] bit  NOT NULL,
    [IsVegetable] bit  NOT NULL,
    [Id] int  NOT NULL
);
GO

-- --------------------------------------------------
-- Creating all Primary Key Constraints
-- --------------------------------------------------

-- Creating primary key on [Id] in table 'RecipeSet'
ALTER TABLE [dbo].[RecipeSet] WITH NOCHECK
ADD CONSTRAINT [PK_RecipeSet]
    PRIMARY KEY CLUSTERED ([Id] ASC)
    ON [PRIMARY]
GO
…
-- --------------------------------------------------
-- Creating all Foreign Key Constraints
-- --------------------------------------------------

-- Creating foreign key on [Chef_Id] in table 'RecipeSet'
ALTER TABLE [dbo].[RecipeSet] WITH NOCHECK
ADD CONSTRAINT [FK_ChefRecipe]
    FOREIGN KEY ([Chef_Id])
    REFERENCES [dbo].[ChefSet]
        ([Id])
    ON DELETE NO ACTION ON UPDATE NO ACTION
…

Note here that the default inheritance mapping strategy is to create a table for all subtypes: In the above DDL, you can see that we are generating tables for the Protien and Plant subtypes. These tables are named with the name of the EntitySet in which the types live, to which we append the name of the type itself.

Note also that we generate primary and foreign key constraints for the model.

Watch for our in-depth series on Model First with the Entity Framework that we are working on publishing in the coming weeks.

- Noam Ben-Ami
Program Manager, Entity Framework

Update Model – a Question of Identity – Part 2 of 3

dpblogs — Tue, 22 Jul 2008 19:23:00 GMT

This article is Part 2 of 3 – please see http://blogs.msdn.com/adonet/archive/2008/07/21/update-model-a-question-of-identity-part-1-of-3.aspx for Part 1.

In the last article I explained the principle that the C-side updates would be non-destructive.

The “Update Model” code needs to decide when we should add new C-side EntityTypes, new C-side Properties and new C-side Associations. This brings us into the idea of identity. Bear with me – this can get pretty complicated.

Suppose you have a database with two tables in it. They have the same name but are in different schemas e.g. schema1.Customer and schema2.Customer. All S-side EntitySets (which are the way the EDM represents a database table or view) in a given model must have unique names. So if you attempt to import both of the above tables then one of them will be represented as an EntitySet with name ‘Customer’ and one with name ‘Customer1’ each with a matching EntityType. Which one will be which? Well, it depends on in what order you import them and sometimes on what else you import at the same time. The important point is that the Name attribute of the EntitySet is not always the same as the name of underlying database object.

So we cannot rely on the Name attribute of a given EntitySet to identify the underlying database object. But for “Update Model from Database” we do need to identify what the true underlying database object is to decide whether a given one is “new”. So instead we construct a “database identity” for each S-side EntitySet which consists of its underlying schema name and its underlying table/view name. If the EntitySet’s Name attribute does not match the underlying table/view name then either a Table attribute or the special attribute store:Name (where ‘store’ is a prefix defined as the XML namespace “http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator”) is defined on that EntitySet. The value of this attribute is the true underlying database object name. Similarly the Schema or store schema attribute will represent the true underlying database schema name (and there’s a similar story for Function elements which is how the EDM represents stored procedures).

This combination of the true database schema name and the true database object name are the “database identity” of that EntitySet. “New” S-side EntitySets are defined as those whose “database identity” does not appear in the S-side of the existing model.

For every imported, new S-side EntitySet we create a single, matching C-side EntitySet and EntityType and the mappings necessary to map them through to the S-side EntitySet. If it is available, we will use the existing S-side name for the matching C-side EntityType, but that name may already be in use in which case we will try appending 1, 2, 3 … until we find a name that is not in use.

So as an example, if a C-side EntityType, say ‘Customer’, was originally mapped to the S-side ‘Customer’ EntityType but has been manually unmapped, and “Update Model from Database” is run then the above rules will _not_ result in a “duplicate” C-side EntityType called ‘Customer1’ because “Update Model” knows that there was already a ‘Customer’ S-side EntityType – we assume the user knew what s/he was doing when they unmapped the C-side EntityType. However if a _new_ S-side EntityType called ‘Customer’ is added and there happens to exist a C-side EntitySet already called ‘Customer’ then the new, matching C-side EntityType would be called ‘Customer1’ and it will be up to the user to rename the C-side EntityTypes as needed.

In the next article I’ll explain how this concept is extended to C-side Properties and Associations.

Lawrence Jones
Software Design Engineer, Entity Framework Tools

Update Model – a Question of Identity – Part 1 of 3

dpblogs — Mon, 21 Jul 2008 21:01:00 GMT

I propose to explain the reason behind some of the oddities of the “Update Model from Database” functionality and hopefully answer some common questions that come up about it.

Before I get started let me note that this will be a fairly technical post split into three parts (I’ll post links to the other parts as responses to this one). There is also a good blog on this subject taking a look at the changes since our last release and showcasing some particular examples of the principles I will be explaining below. This blog is by Noam Ben-Ami at the following link: http://blogs.msdn.com/adonet/archive/2008/04/01/update-model-from-db.aspx.

An EDMX file represents the conceptual (C-) side of the model, the storage (S-) side of the model and a mapping between the two. The major job of “Update Model from Database” is to update the S-side of the model to be consistent with any changes that have been made to the database since it was created or last updated. (Note that in this sense “changes” can also include any database objects which you chose not to include in your S-side model the last time through). “Update Model” will also automatically remove any mappings which would target non-existent S-side objects after the update.

For RTM, the S-side of the model is completely replaced by a new S-side model generated from all the tables/views/stored procedures in the existing model plus any new ones selected via the “Update Model from Database” wizard. This has the advantage of ensuring that the new S-side model is self-consistent, but has the disadvantage that it removes any S-side elements which have been added by hand to the EDMX file. We are considering alternatives to this approach for V2.

Now before we go on note that the Entity Designer shows you only the C-side of your model, not the S-side. The S-side is only visible through the Browser and entries in the Mapping Details window. Hence most people’s view of “the model” is the C-side of the model.

Note also that for any given S-side model there are many possible C-side models which could be mapped to it: in particular in addition to the more simple 1:1 scenario, two or more C-side EntityTypes can be mapped to the same underlying table, or a single C-side EntityType can be mapped to more than one table.

Although the major job of “Update Model from Database” is to update the S-side, we decided that, in order to reduce work for the user, we would also update the C-side but only under the following rule:

· The C-side updates would be non-destructive.

This means that we feel free to e.g. add new C-side EntityTypes to represent new S-side EntityTypes or new C-side Properties to represent new S-side Properties, but we will not e.g. delete a C-side EntityType because we believe the S-side EntityType it was mapped to has been deleted. Nor will we “resurrect” a C-side EntityType which the user has chosen to delete. We leave such decisions up to the user.

As a consequence of this it is possible that an Entity Data Model which passed validation before “Update Model” was run will no longer be valid after “Update Model” is run. In this case the user should investigate each error message in the Error List Window and manually take some action to update the model before it can be used. The action that needs to be taken is probably destructive and so we leave it up to the user to decide.

In the next article I’ll explain how “Update Model” makes the decision to create new C-side EntitySets based on new S-side EntitySets and what “identity” has to do with all this.

Lawrence Jones
Software Design Engineer, Entity Framework Tools

EDM Tools | Options (Part 3 of 4)

dpblogs — Fri, 27 Jun 2008 00:38:00 GMT

Introduction

In parts one and two of this four-part series, we discussed the file differences between EDMX & csdl, ssdl & msl files, and we looked at the model & code generation APIs available in the .Net Runtime. In Part three, we discuss validation of EDM models, and we look at view generation for EDM models.

Model Validation

The Visual Studio experience validates your EDMX models during a build, whenever an EDMX file is saved, and whenever a user selects the “Validate” context menu in the EDM designer. To validate a model from the command-line, you can execute the following command:

edmGen.exe /mode:ValidateArtifacts /incsdl:SqlCENorthwind.csdl /inssdl:SqlCENorthwind.ssdl /inmsl:SqlCENorthwind.msl

The code to programmatically validate a model defined in an EDMX file is shown in Listing 1. Here, we load the ssdl, csdl & msl into EdmItemCollection instances. The process of loading these returns a list of errors that we can output. We then compile the mappings, which does a semantic validation to ensure that the mappings are correct for the EDM.

To programmatically validate a model, you can do the following:

private static void Validate(
            FileInfo edmxFile)
        {
            XDocument doc = XDocument.Load(edmxFile.FullName);
            XElement c = GetCsdlFromEdmx(doc);
            XElement s = GetSsdlFromEdmx(doc);
            XElement m = GetMslFromEdmx(doc);

            // load the csdl
            XmlReader[] cReaders = { c.CreateReader() };
            IList<EdmSchemaError> cErrors = null;
            EdmItemCollection edmItemCollection = 
                MetadataItemCollectionFactory.CreateEdmItemCollection(cReaders, out cErrors);

            // load the ssdl 
            XmlReader[] sReaders = { s.CreateReader() };
            IList<EdmSchemaError> sErrors = null;
            StoreItemCollection storeItemCollection = 
                MetadataItemCollectionFactory.CreateStoreItemCollection(sReaders, out sErrors);

            // load the msl
            XmlReader[] mReaders = { m.CreateReader() };
            IList<EdmSchemaError> mErrors = null;
            StorageMappingItemCollection mappingItemCollection = 
                MetadataItemCollectionFactory.CreateStorageMappingItemCollection(
                edmItemCollection, storeItemCollection, mReaders, out mErrors);

            // validate the mappings
            IList<EdmSchemaError> viewGenerationErrors = null;
            viewGenerationErrors = EntityViewGenerator.Validate(mappingItemCollection);

            // write errors
            WriteErrors(cErrors);
            WriteErrors(sErrors);
            WriteErrors(mErrors);
            WriteErrors(viewGenerationErrors);
        }

Listing 1. Code example to validate an EDMX file. Full code can be downloaded here.

Generating Views

The Entity Framework runtime reasons about your data model via ESql Views. The runtime will generate and cache views if they aren’t included in your assembly, so there is no need to pre-generate the views. However, view-generation can be expensive. Pre-generating views and compiling them into your assembly may eliminate some of your application’s start-up costs. Inside of Visual Studio, we don’t do anything with the pre-generating views, but views can be generated using EdmGen.exe with the following command:

edmGen.exe /mode:ViewGeneration /incsdl:SqlCENorthwind.csdl /language:CSharp /outviews:views.cs /inmsl:SqlCENorthwind.msl /inssdl:SqlCENorthwind.ssdl

The views are output as ESql queries in a C# or VB file. After running the above example, the file views.cs will contain the views, and views.cs will need to be compiled into your assembly.

The code in Listing 2 below illustrates programmatically generating views given an EDMX file. You’ll note that the code below is very similar to the validation code in Listing 1. This is because the data structures built during validation are needed to perform view-compilation. In fact, the only difference between the validation and view generation is that view generation will output the views to a file.

private static void ValidateAndGenerateViews(
            FileInfo edmxFile, LanguageOption languageOption)
        {
            XDocument doc = XDocument.Load(edmxFile.FullName);
            XElement c = GetCsdlFromEdmx(doc);
            XElement s = GetSsdlFromEdmx(doc);
            XElement m = GetMslFromEdmx(doc);

            // load the csdl
            XmlReader[] cReaders = { c.CreateReader() };
            IList<EdmSchemaError> cErrors = null;
            EdmItemCollection edmItemCollection = 
                MetadataItemCollectionFactory.CreateEdmItemCollection(cReaders, out cErrors);

            // load the ssdl 
            XmlReader[] sReaders = { s.CreateReader() };
            IList<EdmSchemaError> sErrors = null;
            StoreItemCollection storeItemCollection = 
                MetadataItemCollectionFactory.CreateStoreItemCollection(sReaders, out sErrors);

            // load the msl
            XmlReader[] mReaders = { m.CreateReader() };
            IList<EdmSchemaError> mErrors = null;
            StorageMappingItemCollection mappingItemCollection = 
                MetadataItemCollectionFactory.CreateStorageMappingItemCollection(
                edmItemCollection, storeItemCollection, mReaders, out mErrors);

            // generate views & write them out to a file
            IList<EdmSchemaError> viewGenerationErrors = null;
            string outputFile =
                GetFileNameWithNewExtension(edmxFile, ".GeneratedViews" +
                    GetFileExtensionForLanguageOption(languageOption));
            EntityViewGenerator evg = new EntityViewGenerator(languageOption);
            viewGenerationErrors =
                evg.GenerateViews(mappingItemCollection, outputFile);

            // write errors
            WriteErrors(cErrors);
            WriteErrors(sErrors);
            WriteErrors(mErrors);
            WriteErrors(viewGenerationErrors);
        }

Listing 2. Code example showing programmatic view generation. Full code can be downloaded here.

Coming Up Next

In the final installment of this four-part series, we combine the code we’ve written into a new command-line tool called EdmGen2.exe. This is similar in functionality to EdmGen.exe, but understands how to read & write EDMX files.

Mike Kaufman
Software Design Engineer

EDM Tools | Options (Part 1 of 4)

dpblogs — Sat, 21 Jun 2008 00:27:00 GMT

Introduction

The Entity Data Model (EDM) Tools team has done a lot of work to enable a productive developer experience using the Microsoft Entity Framework. Model generation, model validation, and code generation are all plugged into the Visual Studio (VS) environment for a seamless user experience. Model generation is accomplished through a Visual Studio wizard, while model validation and code generation are behind-the-scenes operations that users generally need not think about. Consequently, you may not realize that the tooling functionality integrated into Visual Studio is also available from the command-line (via EdmGen.exe), and via programmatic APIs defined in the System.Data.Entity.Design namespace and assembly. Access to this functionality can be very useful. For example, you can hook code-generation and validation into your automated build. Or, you can write your own tools, like MSBuild tasks, to generate code or validate models.

This is the first in a series of four posts that look at tooling options for the EDM. In this series, we review some of the EDM tooling processes that are integrated into Visual Studio, and discusses alternatives for running these outside of VS - either from the command-line or from your own program. The motivating example we use is building a simple replacement for the .Net Framework tool EdmGen.exe. The approach we follow is to first look at a piece of functionality integrated into the Visual Studio experience. Then, we look at how it is available via the EdmGen.exe tool, and then we’ll look at the public APIs available in the .Net Framework.

In this first post, we discuss the different file formats between the Visual Studio tools & the Entity Framework APIs in the .Net Framework. In the second part, we will review how to generate models from a database, and how to generate code from a model. In the third part, we look at the validation of models & mappings. The final part in this series will tie all of the previous examples together into a command-line tool that understands how to read and write the EDMX file formats.

Full source-code for the full command-line tool is available at http://code.msdn.microsoft.com/EdmGen2. This contains code for all examples in this series.

EDMX files vs. CSDL, SSDL and MSL files

Before we discuss the tooling tasks outside of VS, we first need to address a slight difference in file formats. In the beginning, there was only an Entity Framework runtime, and the runtime operated on three different files: one for the “conceptual model” (the .csdl file), another for the “storage model” (the .ssdl file), and a third for the “mapping” (the .msl file). Internally, the Data Programmability team refers to a set of these files as “c/m/s files”. The EDM Tools Team made a decision simplify the VS experience by aggregating the c/m/s files into a single .edmx file. The unfortunate state of affairs for V1 is that EdmGen.exe and the Entity Framework APIs that ship in the .Net runtime can’t read EDMX files.

Breaking Down an EDMX File

The first bit of Code that we we’ll show you is how to extract an EDMX file into the “c/m/s” parts. This is actually quite simple, since the EDMX file embeds the csdl, ssdl & msl. In the code below, we use Linq To Xml to extract the appropriate data from the EDMX, and write out separate files for the csdl, ssdl & msl. To do the inverse (ie, combine c/m/s files into an EDMX), see the full code listing at the MSDN Code Gallery.

     private static void FromEdmx(FileInfo edmxFile)
     {
            XDocument xdoc = XDocument.Load(edmxFile.FullName);

            // select the csdl element, and write it out
            XElement csdl = GetCsdlFromEdmx(xdoc);
            string csdlFileName = GetFileNameWithNewExtension(edmxFile, ".csdl");
            File.WriteAllText(csdlFileName, csdl.ToString());

            // select the ssdl element and write it out
            XElement ssdl = GetSsdlFromEdmx(xdoc);
            string ssdlFileName = GetFileNameWithNewExtension(edmxFile, ".ssdl");
            File.WriteAllText(ssdlFileName, ssdl.ToString());

            // select the msl element and write it out
            XElement msl = GetMslFromEdmx(xdoc);
            string mslFileName = GetFileNameWithNewExtension(edmxFile, ".msl");
            File.WriteAllText(mslFileName, msl.ToString());
     }

     private static XElement GetCsdlFromEdmx(XDocument xdoc)
     {
            return (from item in xdoc.Descendants(
                        XName.Get("Schema", csdlNamespace)) select item).First();
     }

     private static XElement GetSsdlFromEdmx(XDocument xdoc)
     {
            return (from item in xdoc.Descendants(
                        XName.Get("Schema", ssdlNamespace)) select item).First();
     }

     private static XElement GetMslFromEdmx(XDocument xdoc)
     {
            return (from item in xdoc.Descendants(
                        XName.Get("Mapping", mslNamespace)) select item).First();
     }

Listing 1. Code to extract CSDL, SSDL & MSL sections from an edmx into files. Full code can be downloaded.

Coming Up Next

In part two of this four-part series, we will review the command-line & .NET APIs around EDM model and code generation.

Mike Kaufman
Software Design Engineer, ADO.NET Tools

How to use a T4 template for View Generation

dpblogs — Fri, 20 Jun 2008 22:27:00 GMT

Background

To set the stage for this article, do take a look at Exploring the Performance of the ADO.NET Entity Framework - Part 1 to learn more about pre-generating views and how they can reduce the startup time for applications that consume ADO.NET Entity Data Models.

A while back, Jaroslaw Kowalski from our team posted a great reply about using EdmGen.exe to generate views for your ADO.NET Entity Data Model in this forum question. This information is also available on MSDN for reference.

While using EdmGen.exe is a good approach for certain view generation scenarios, it is somewhat problematic in the following situations when you use it inside Visual Studio:

1. It does not work with EDMX files (you need to give it the individual CSDL, MSL and SSDL files)

2. Getting at the individual CSDL, MSL and SSDL files is a challenge when you’ve set “Metadata Artifact Processing” to “Embed in Output Assembly” in the Entity Designer.

3. Users are forced to fuss with post-build steps in the project

This article presents an easier and more intuitive approach to generate pre-compiled views with the Text Template Transformation Toolkit (a.k.a. T4 templates) in Visual Studio 2008. If you are not familiar with T4 templates, this video provides a great introduction.

T4 template for view generation

Introduction

This article is accompanied by two T4 templates: CSharp.Views.tt for use in C# projects and VisualBasic.Views.tt for use in VB projects. Both versions do the same thing:

1. Figure out which EDMX file to process based on the file name

2. Extract the individual CSDL, MSL and SSDL from the EDMX file and

3. Use public APIs in the ADO.NET Entity Framework to generate views.

To keep things simple, the code in the T4 template follows a simple file naming convention to determine the EDMX file to process. It assumes that [edmx-file-name].Views.tt will process and generate views for the file [edmx-file-name].edmx. The views are generated in the code behind file [edmx-file-name].Views.cs or [edmx-file-name].Views.vb as the case may be.

Usage

I think this is one of those things that’s best demonstrated by actually using it, so I’ll jump right into it.

C# projects

Scenario: Generate pre-compiled views for an EDMX file in a C# project

1. Create a new C# Console project

2. Add a new ADO.NET Entity Data Model to the project via “Add…New…Item”

3. Go with the default file name of Model1.edmx

4. Generate a model from a database (say, Northwind) and complete the wizard

5. Use “Add…Existing…Item” to add the C# version of the T4 template (CSharp.Views.tt) into the project in the same project directory as Model1.edmx

6. In Solution Explorer, rename the file CSharp.Views.tt to Model1.Views.tt

7. Click OK to continue if Visual Studio displays the following dialog:

8. In Solution Explorer, right-click Model1.Views.tt and choose "Run Custom Tool" to generate the views

9. Visual Studio runs the text transformation code in Model1.Views.tt which processes Model1.edmx to produce the generated views in the code behind file Model1.Views.cs

10. The generated file Model1.Views.cs is compiled into the output assembly when you build the project

11. If needed, click “Show All Files” in Solution Explorer to see the generated code behind file

VB projects

Scenario: Generate pre-compiled views for an EDMX file in a VB project

1. Create a new VB Console project

2. Add a new ADO.NET Entity Data Model to the project via “Add…New…Item”

3. Go with the default file name of Model1.edmx

4. Generate a model from a database (say, Northwind) and complete the wizard

5. Use “Add…Existing…Item” to add the VB version of the T4 template (VisualBasic.Views.tt) into the project in the same project directory as Model1.edmx

6. In Solution Explorer, rename the file VisualBasic.Views.tt to Model1.Views.tt

7. Click OK to continue if Visual Studio displays the following dialog:

8. In Solution Explorer, right-click Model1.Views.tt and choose "Run Custom Tool" to generate the views

9. Visual Studio runs the text transformation code in Model1.Views.tt which processes Model1.edmx to produce the generated views in the code behind file Model1.Views.vb

10. The generated file Model1.Views.vb is compiled into the output assembly when you build the project

11. If needed, click “Show All Files” in Solution Explorer to see the generated code behind file

Tips

1. As and when you make changes to the EDMX file, simply right-click Model1.Views.tt in in Solution Explorer and choose "Run Custom Tool" to generate the views

2. If you have multiple EDMX files in your project then make as many copies of the.tt file and rename appropriately to pair each with each EDMX file

3. To generate views for all EDMX files in the solution, click the “Transform All Templates” button in the Solution Explorer toolbar (the rightmost button in the toolbar)

I hope this article helps get your creative juices flowing for similar scenarios. For example, one could imagine a similar approach to do custom code generation from an EDMX file (shameless plug for a future blog post!)

Sanjay Nagamangalam
Lead PM – ADO.NET Entity Designer