LINQ to SQL to Entity Framework conversion template

Many customers have asked us how to port a LINQ to SQL application to the Entity Framework. In order to make this process easier, we have developed a metadata conversion template.

This template converts LINQ to SQL metadata (.dbml) to metadata compatible with Entity Framework (.edmx). While not a complete solution to the conversion problem, it is a useful first step. The template available for download is still in the development stage, and any feedback you have on the user experience, additional features, or any other aspect of the conversion would be greatly appreciated.

The T4 template is intended to convert simple valid .dbml files to .edmx files. All of the basic elements of the .dbml file are mapped to their .edmx counterparts. For instance, Tables are mapped to EntitySets and Types are mapped to EntityTypes. Additionally, stored procedures (including customized insert, update and delete stored procedures) and associations are also converted.

Downloading the Metadata Conversion Template

Included in the zip file is a .vsix installer for the T4 Conversion Template. Also included is detailed documentation for the template. VS 2010 Beta 1 is required.

Download the Template

Walkthroughs

Two walkthroughs have been written to help guide users through the conversion process. The walkthroughs both take the form of unit tests which can be run against the existing LINQ to SQL metadata and the Entity Framework metadata produced by the conversion template. Each walkthrough contains detailed instructions on how to convert the existing LINQ to SQL project to Entity Framework using the Conversion Template. The first is the Widget Factory walkthrough, which shows a basic conversion. The second (CustomCUD) shows how to convert a LINQ to SQL project which uses custom insert, update and delete stored procedures. The walkthroughs are available individually.

Widget Factory Walkthrough

Custom CUD Walkthrough

Caveats and Known Issues

Because the Conversion Template is still under development, there are a number of open issues and unimplemented features. A more comprehensive list can be found in the documentation included with the template installer.

· Inheritance: Inheritance has not been fully implemented. While the template may work in some basic cases, this aspect of the conversion remains an open issue.

· Independent Associations: Foreign-key associations will not be available until .NET 4.0 Beta 2, so the current version of the template will only work with the "UseIndependentAssociations" flag set to true.

· Property Attributes: not all of the property attributes (such as "Unicode" and "FixedLength") are converted because these are not explicitly present in the .dbml file.

Feedback

We are interested to hear any comments you have about known issues, additional feature requests, suggestions for additional walkthroughs or any other aspect of the conversion process.

Thanks,
Christina Ilvento
Developer,
Entity Framework Team

FullInstaller.zip

Comments

  • Anonymous
    August 14, 2009
    Until the EF supports all the functions of Linq-To-Sql any conversion is going to be problematic.  Simple DateTime functions that worked just fine in Linq-To-Sql are all broken in EF.  Please can you prioritize getting EF to be a superset of Linq-To-Sql higher than this conversion code.  Many of us can create the metadata simply be re-importing our database but we can't easily make up for the lack of missing functionality.

  • Anonymous
    August 14, 2009
    I concur with App. Re-importing the DB seems to be far easier, but people graduating to EF from Linq2Sql are usually left with a whole bunch of lost functionality.

  • Anonymous
    August 16, 2009
    Unless there is a conversion tool for the code that uses the Linq 2 Sql diagram, then a conversion template is useless. In other words I agree with App and Robert McLaws...

  • Anonymous
    August 19, 2009
    Thank you for taking the time to look at the new metadata conversion template. As was suggested, you could create metadata for an EF project by re-importing the database used by the original LINQ to SQL project, but there are several scenarios in which we think the conversion template will be helpful. First, if there has been any change to the dbml which does not exactly correspond to the database, these changes will be lost. Second, the EF conventions for naming and relationships are significantly different. This metadata conversion template is the first of a set of tools we are considering to help you convert existing LINQ to SQL application code to EF. As the EF continues to incorporate more of the features available in LINQ to SQL, we plan to adapt the tools use this increased functionality. As always, thanks for your feedback! -Christina

  • Anonymous
    November 15, 2009
    +1 for making EF a superset of Linq2Sql.  Support for enums is one particular problem area.

  • Anonymous
    January 07, 2010
    The comment has been removed

  • Anonymous
    April 14, 2010
    Is there any update to this now that 2010 has been released?

  • Anonymous
    April 27, 2010
    Any updates? Would be great to get a converter that can work off of a LinqToSql xml file only, rather then the dbml. I use sqlmetal to generate the xml and code separately.

  • Anonymous
    April 27, 2010
    While there has been some interest, so far the interest has not been enough to justify further investment in this project rather than other efforts such as adding more core features to the EF.  If that changes in the future, we'll be sure to post back here.

  • Danny
  • Anonymous
    November 07, 2010
    Sometimes developers' attitude really amazes me. More a I read responses from devs like this, more I want to give up on .NET.

  • Anonymous
    April 15, 2011
    Any update on this conversion tool?

  • Anonymous
    July 20, 2015
    I disagree with some of the commenters above. Having a DBML to EDMX converter would be an excellent thing to have and a worthwhile investment of Microsoft's time. I have a very large Linq-to-SQL codebase that I need to move to EF and re-generation from the database doesn't work because there are many specific class name and field name mappings that get lost. A conversion function would help us all move to the (now) more feature-rich EF.