After Downloading: Depending on your security settings, windows might Block all files, causing the application to not run correctly. If this happens you must right-click ALL FILES in ALL Directories (Release, CodeGenerator, EntityProvider directories) and select "Unblock".Microsoft Visual Studio 2010 Solution Source Code
- MsOrmCodeGen.exe - Entity Framework and Linq to Sql Poco Code Generator
- Northwind Console Application Source Code - Utilizes Dtos generated from by MsOrmCodeGen and demonstrates using Entity Framework and Linq to Sql in a Persistence Ignorant way
- MsOrmCodeGen - Entity Framework and Linq to Sql Poco Code Generator
- Jodo.CodeGenerator.Core - Lightweight code generation and templating framework
- The Northwind console application which demonstrates using Entity Framework and Linq to Sql in a Persistence Ignorant way. This project uses the generated Dtos from the MsOrmCodeGen application and demonstrates how to instantiate a DataContext and ObjectContext using embedded Xml mapping files and flexible DbProviderFactories. Even if you choose to not use the MsOrmCodeGen code generator, this example project is extremely valuable in demonstrating a clean and simple method for using Entity Framework and Linq to Sql. A quick start specifically for this project can be found here: Quick Start Guide
MsOrmCodeGen is a code generator that produces Poco data transfer objects (Dtos) and Xml mapping code that works with Entity Framework and Linq to Sql. You can create one set of data transfer objects that can be used with both technologies. Simply point the generator to a database and all the required code to utilize Entity Framework and Linq to Sql will be generated.
The classes generated will be pure Poco and void of any Entity Framework or Linq to Sql technology specific requirements.
MsOrmCodeGen builds on top of the code generators provided by Microsoft to support Entity Framework (Edmgen.exe) and Linq to Sql (SqlMetal.exe) and provides the following enhancements:
Microsoft has not provided Poco code generation templates for Linq to Sql; MsOrmCodeGen fills this void.
As of VS2010 Poco code generation templates have been provided for Entity Framework, but they require that you create an Edmx model, from which it will generate Poco classes. So even if you desire to use Poco templates you will still have to create and continually update your Edmx file in order for your Poco classes to be generated. This can be a real hassle and the larger your model gets, the more cumbersome and time consuming this becomes. Using MsOrmCodeGen avoids this maintenance hassle since you do not have to provide an Edmx model. With MsOrmCodeGen building your Poco classes and keeping them in sync with the database is a one-click process, with no need to even see the Edmx!
- Template based generation
Using the text template you can control exactly how your code will be constructed. If you need to implement a custom "project specific" Interface on all your Dtos, you can just add it to the template and you are done.
- Enforced Pascal Case Notation for Classes and Properties
Linq to Sql's code generator, SqlMetal.exe, will force all properties to be Pascal Case; if your database column name is "firstName", the SqlMetal generated class will contain a property named "FirstName". This is highly desirable since it follows normal C# naming conventions. This is not enforced by Entity Framework's Edmgen.exe code generator. Edmgen.exe will follow whatever notation your database provides, which quite often is Camel Case. MsOrmCodeGen solves this issue, making all Entity Framework Poco classes Pascal Case.
- Easy to use GUI for Initiating Code Generation and Saving Configurations
- Generates one unified set of Dtos that can be utilized by both Entity Framework and Linq to Sql
- Quickly Regenerate Classes to Stay in Sync with the Database in One Step
The goal of this project was to build a utility that would be capable of generating a complete one-to-one, database entity to data transfer object, layer of classes that could be built quickly, and also be easily rebuilt to keep in sync with any database schema changes. A one step process was the goal.
The first step was to simply build a GUI over top of the Microsoft-provided code generators for Entity Framework and Linq to Sql. These generators already provided the means to generate a complete one-to-one, database entity to data transfer object, layer of classes. Providing a means to execute these utilities in "one-click" using saved configurations was the first objective. Once this was accomplished the projects goals expanded.
The utilities provided by Microsoft produced Persistence Aware classes that were bound to a particular technology. Figuring it would be nice to be able to produce Persistence Ignorant (PI) data transfer objects, MsOrmCodeGen began to take the output of the Microsoft-provided code generators and parse it to create Poco classes that would continue to comply with the requirements of the technology.
By this time I was only using Linq to Sql for data access. When Entity Framework 2.0 was launched it supported Persistence Ignorance as well, and I wanted a way to easily migrate my data layer code from Linq to Sql to Entity Framework. Knowing this would be a staged approach and that I would not be able to do this in one full sweep, I thought it would be ideal if my Poco classes could function with either Linq to Sql or Entity Framework with little or no change. After a series of prototyping to determine if this was possible, I concluded that it was, and the requirements imposed by both technologies were almost identical.
MsOrmCodeGen was then expanded to be able to produce one set of data classes that would work with both Linq to Sql and Entity Framework and generate all the necessary technology specific mapping files to support the classes for both technologies. The goal of being able to write data access code against one set of Dto classes and use either Linq to Sql or Entity Framework to carry out the work was achieved and I was able to slowly migrate to Entity Framework one repository at a time. All of my data mapper classes which transfer data from business objects to data transfer objects were able to be used "as is", regardless of whether my repository implementation was using Linq to Sql or Entity Framework.
The end result of the project was a tool that allowed "one-step" generation of Poco data access classes and mapping code that supports Linq to Sql, Entity Framework, or both, depending on the provider you select when running the tool.
It is worth noting that it is completely optional whether you choose to generate Poco classes that will operate with both Linq to Sql and Entity Framework or just one technology. MsOrmCodeGen ships with three EntityProviders and allows you to choose whether you want to generate only Linq to Sql code and mapping, only Entity Framework code and mapping, or both. If you know you will only be using one technology, it is advised that you just use that specific provider.
- Users that will be building a purely data centric application and simply need direct access to the database. In this scenario the code generator will be used to quickly generate 100% database coverage classes that are easily regenerated and kept in sync with the database.
- Users that will be building n-layer and Model Driven applications using design techniques such as Domain Driven Design, with a clean separation between data access code and business code. In this scenario the code generator will be used to auto-generate all data access layer Dtos and hand-authored data mapper classes will be used to transfer data between the generated data layer Dtos and business objects.
It is worth noting that in both scenarios there will only be one file generated that includes all the data transfer object classes. This is highly desirable because the purpose of the generated data classes is for them to be rebuilt as often as necessary and for them to function behind the scenes without the need for a programmer to ever see them.
In scenario one, if you needed to add functionality to a class, you can use partial classes and the added functionality can be authored in another file. In scenario two, you will never be adding functionality to the data transfer objects because you will be using business objects for behavior and only using the generated Dtos for getting data in and out of the database and hydrating your business objects.
Quick Start Guide
Running the MsOrmCodeGen Binary
.Net 4.0 must be installed.1. (Optional) Install Microsoft SQL Server Compact 4.0
- This is used to save your settings. It eliminates the need to enter your settings for a particular project more than once. It is not required that this be installed, but if it is not, your settings will not be stored. It is a fairly quick install that does not require a reboot.http://www.microsoft.com/downloads/en/details.aspx?FamilyID=033cfb76-5382-44fb-bc7e-b3c8174832e22. Download and extract the zip file containing the MsOrmCodeGen.exe and its supporting files.Click the "Download" button on the right side of this page3. "Double Click" MsOrmCodeGen.exe to run the WinForms client.4. Enter the required fields:
- Database Server
- Database Name
- Database Username and Password are optional, depending on your environment
- Choose an appropriate Entity Provider for the technologies you want to use. MsOrmCodeGen ships with three Entity Providers:
- Edmgen Entity Provider - Will generate a .cs file of your Dto classes, the three necessary Entity Framework Xml mapping files, Csdl.xml, Msl.xml, Ssdl.xml, and the typed views classes, Views.cs. This is everything you need to use Entity Framework.
- SqlMetal Entity Provider - Will generate a .cs file of your Dto classes, and the necessary Linq to Sql Xml mapping file.
- Edmgen SqlMetal Entity Provider - Will generate a .cs file of your Dto classes, the three necessary Entity Framework Xml mapping files, Csdl.xml, Msl.xml, Ssdl.xml, and the typed views classes, Views.cs, and the necessary Linq to Sql Xml mapping file
This is the fully qualified path to the .cs file that will contain the generated Dto classes. You should point this directly to a Visual Studio project path where you will be using the classes. Example: C:\Users\jdevenny\Documents\Visual Studio 2010\Projects\MsOrmCodeGen\Northwind\Dto\Dtos.cs
- Linq Xml Destination or EF Files Destination:
- If you are using the "SqlMetal Entity Provider" you will need to provide a fully qualified path to the Linq to Sql Xml mapping file destination. You should point this directly to a Visual Studio project path where you will be using the Linq to Sql code. Example: C:\Users\jdevenny\Documents\Visual Studio 2010\Projects\MsOrmCodeGen\Northwind\Linq\DataContext.xml
- If you are using the "Edmgen Entity Provider" you will need to provide a fully qualified path to a directory where the Entity Frameworks Xml and Views.cs files will be stored. You should point this directly to a Visual Studio project path where you will be using the Entity Framework. Exmple: C:\Users\jdevenny\Documents\Visual Studio 2010\Projects\MsOrmCodeGen\Northwind\Entity
- If you are using the "Edmgen SqlMetal Entity Provider" you should provide values for the "Linq Xml Destination" and "EF Files Destination" fields.
- Code Template:
Choose a template to use to generate your Dto classes. All available templates should be placed in the "Templates" directory under the applications start-up directory. MsOrmCodeGen ships with two templates to get you started. All templates should follow the format of the provided examples and should be .txt files.
Provides a namespace in which your .cs classes will be placed, as well as being used by the Edmgen.exe and SqlMetal,exe to provide fully qualified type names.
- Create New Configuration:
5. Generate Code:
If you have Microsoft SQL Server Compact 4.0, you can check this checkbox in order to save your configuration when you hit the "Generate" button. Even if the generation fails, your configuration will be saved first and should be persisted. If you do not have Microsoft SQL Server Compact 4.0 installed this checkbox will do nothing.
Click the "Generate" button to begin the generation process. When completed, the "Output" tab will show you the code that was produced, and the "Entities" tab will show you the Entity types that were found by the Entity Provider you selected and will display their names. Generally speaking, these names should match the names of the tables in the database you selected.
Running the Northwind Entity Framework / Linq to Sql Example Usage Project
1. Download the source code which contains one VS2010 solution with all the included projects.2. Compile the Solution3. Locate the "Northwind" project and Run the included "Northwind_OrmTest.sql" database script against SqlServer 2005 or above.
4. Locate the "Northwind" project and open the App.config file and change the connection string to the appropriate settings for your environment.5. Run the console program in debug mode.
This script contains a slightly altered version of the typical Northwind database and pre-populates it with some test data. A database named "NorthwindOrmTest" should be created. Check to make sure the name is correct and if not, rename the created database to "NorthwindOrmTest".
You should see the same data loaded using an Entity Framework ObjectContext and a Linq to Sql DataContext. If you want to test regenerating the Dto classes and mapping files, you can run the MsOrmCodeGen pointing the output files to the appropriate locations for this project (the "Entity" and "Linq" directories). The namespace should be set to "Northwind.Dto", and database settings should point to the "Northwind_OrmTest" database you created. You must choose the "Edmgen SqlMetal Entity Provider" Provider for this program to work.
Running the MsOrmCodeGen from the VS2010 Solution
1. Compile the Solution 2. Open the "debug" directory in the MsOrmCodeGen's start-up directory.
3. Run the MsOrmCodeGen client in debug mode.4. Follow the instructions above under "Running the MsOrmCodeGen Binary", in order to populate the UI with the correct values.
- Navigate to the References\Resources directory under the root of the solution.
- Copy all contents of the "Resources" directory into the MsOrmCodeGen's "debug" directory. This should bring in the Edmgen.exe, SqlMetal.exe, the MsOrmCodeGen.Client.Data.ObjectContext sample database and a "Templates" directory which contains two default templates. These resource files must be present to run the application.
Here the code generator was pointed to the Microsoft AdventureWorks database and a complete set of Dto classes and the necessary Xml mapping files were created. The output was dumped directly to a Visual Studio project, where the code will compile and be loadable using an ObjectContext (Entity Framework), or a DataContext (Linq To Sql).