DBML to Entity Framework Converter

This topic describes how to use the DBML to Entity Framework conversion tool that is available for download at the project website. It will read a LINQ to SQL DBML file and convert it to a fairly equivalent set of entity classes and a data context suitable for use with Entity Framework. The converted code makes use of the data annotation attributes and extension methods in this library to allow for similar functionality related to stored procedures. Some review and rework of the converted types and the code that uses them is still needed but it is a quick way to get up and running with Entity Framework without having to completely rewrite the LINQ to SQL data access code especially if you made significant use of stored procedures with it.

• Using the Converter
• To Do Notes
• Other Areas Needing Review
• Example Conversions

The conversion tool is a .NET 8 command line utility. The following command line options are available:

• PathToDbmlFile is required and specifies the DBML file to convert.
• OutputFolder is required and specifies where the generated files will be stored. It is suggested these be placed in a folder separate from any existing source files to prevent accidentally overwriting existing project code. The converted files can be merged into the main project as they are reviewed.
• /contextNamespace:Context.Namespace is optional. If not specified, the context namespace from the DBML file is used if specified or Database if not.
• /entityNamespace:Entity.Namespace is optional. If not specified, the entity namespace from the DBML file is used if specified or the context namespace if not.
• /schema:SchemaName is optional. If not specified, dbo is used as the default schema.
• /paramPrefix:ParameterPrefix is optional. If not specified, no common stored procedure parameter prefix is defined.
• /useFieldKeyword is optional (requires C# 13 preview or later). If not specified, backing fields will be generated for entity properties that use change tracking.
• /useCommunityMvvm is optional. If specified, generated entity classes that require change tracking will derive from ObservableObject from the Community Toolkit MVVM NuGet package. Values in the entity classes will be marked with the ObservableProperty attribute and written out using field syntax. If using C# 14.0 or later, the code fix in Visual Studio can be used when reviewing the generated code to convert the fields to partial properties which you may find more natural to use.
• /nullableRefTypes is optional (requires C# 8 or later). If not specified, defaults will not be added to non-nullable reference types and null forgiving operators will be omitted.
• /ef7orLater is optional (requires Entity Framework Core 7.0 or later). This controls how certain elements such as key fields are rendered in the generated code.

The DBML file to convert and the output folder must be the first and second parameters respectively. Optional parameters can appear in any order.

When conversion is completed, the output folder will contain a data context class file named after the DBML file data context and one class file for each entity type in the DBML file. Table entities will be derived from the ChangeTrackingEntity type from the library. It implements the necessary INotifyPropertyChanging and INotifyPropertyChanged interfaces to support change tracking. Stored procedure result types are simple classes with properties for each column in the result set and no change tracking capabilities.

The generated data context and entity class files will contain various "To Do" notes that may need review to fix up issues or add additional code to make the classes usable. Below is a summary of each of the To Do notes that may be seen.

TODO: Add or remove using statements as needed

The converter adds a default set of using statements to each generated code file. Remove or add to them as necessary.

TODO: Check CodeFile.cs for additional code for the entity/data context

If a code file related to the data context or entity is found in the DBML file's folder, this To Do note will be added. Check the indicated file for additional source code that may need to be added to the Entity Framework data context or entity to implement required features.

TODO: If you pluralize or otherwise change the entity property names...

A commented out section of code is added to the data context's OnModelCreating override that allows keeping the underlying table names the same as their database counterparts if you change the related data context table entity property names for them (e.g., pluralizing them).

TODO: If necessary define entity relationships here

This comment is added to the data context's OnModelCreating override as a reminder to define any necessary relationships between the entities. Currently, any relationships defined in the DBML file are only used to add properties to the entity types.

TODO: This method has no parameters...

This comment is added to data context stored procedure methods that have no parameters and return a result set. Such methods can likely be removed in favor of adding a LoadAllStoredProcedureAttribute to the result set entity type and using the LoadAll<TEntity>() extension method instead.

TODO: This method's parameters match the key on the result set type...

This comment is added to data context stored procedure methods that have parameters matching the key on the result set entity type. Such methods can likely be removed in favor of adding a LoadByKeyStoredProcedureAttribute to the result set entity type and using the LoadByKey<TEntity>() extension method instead.

TODO: All of this method's parameters match properties on the result set type....

This comment is added to data context stored procedure methods in which all parameters match properties on the stored procedure result set entity type. Such methods can likely be removed in favor of adding a LoadByKeyStoredProcedureAttribute to the result set entity type and using the LoadByKey<TEntity>() extension method instead if the corresponding properties are marked as the primary key. Note that the properties don't necessarily have to be an actual key, it just satisfies the requirements for the extension method to be used.

TODO: This method is used to insert entities...

This comment is added to data context stored procedure methods that are used to insert a table entity. Such methods can likely be removed in favor of adding an InsertEntityStoredProcedureAttribute to the entity type and using the InsertEntity<TEntity>() or SubmitChanges<TEntity>() extension method instead.

TODO: This method is used to update entities...

This comment is added to data context stored procedure methods that are used to update a table entity. Such methods can likely be removed in favor of adding an UpdateEntityStoredProcedureAttribute to the entity type and using the UpdateEntity<TEntity>() or SubmitChanges<TEntity>() extension method instead.

TODO: This method is used to delete entities...

This comment is added to data context stored procedure methods that are used to delete a table entity. Such methods can likely be removed in favor of adding a DeleteEntityStoredProcedureAttribute to the entity type and using the DeleteEntity<TEntity>() or SubmitChanges<TEntity>() extension method instead.

After conversion, any code that edits data using table entities with change tracking will need to be reviewed. Calls to the old LINQ to SQL SubmitChanges method will need changing to the Entity Framework SaveChanges method or the library's SubmitChanges method if stored procedures were defined to handle the inserts, updates, and deletes.

Another potential change that may be needed is when enumerating the results of a stored procedure call. The extension methods return an enumerable list and use a data reader. As such, if two are enumerated at the same time, you will need to use ToList() on the outermost enumerable to prevent any subsequent simultaneous enumerations from failing due to multiple open data readers.

Asynchronous versions of all the data context stored procedure related extension methods are available. As such, you may be able to update your code to take advantage of them if so desired.

The project website contains an example LINQ to SQL application and equivalent Entity Framework examples (.NET 8 and .NET 4.8). The example applications do not do anything useful. They just contains some common test cases for the conversion.

• LINQToSQLTestApp - This is the LINQ to SQL test application. The .\Database folder contains the DBML file used for the test conversion.
• EntityFrameworkNet48TestApp - This is the .NET 4.8 Entity Framework test application. The .\Conversion folder contains the data context and entity class files as generated by the conversion tool. The .\Database folder contains the files after they have been reviewed and fixed up. The forms can be compared to the LINQ to SQL versions to see changes made to them.
• EntityFrameworkNet8TestApp - This is the .NET 8.0 Entity Framework test application. The .\Conversion folder contains the data context and entity class files as generated by the conversion tool. The .\Database folder contains the files after they have been reviewed and fixed up. The forms can be compared to the LINQ to SQL versions to see changes made to them.
• AvaloniaTestApp - This is a .NET 8.0 Entity Framework test application that uses Avalonia and Community Toolkit MVVM. The .\Conversion folder contains the data context and entity class files as generated by the conversion tool. The .\Database folder contains the files after they have been reviewed and fixed up for use with the application.

Other Resources
Welcome