The tutorials instruct you to add your entity model to one of the projects generated from a DevForce template.
They do so because they are tutorials. The entity model tends to be in its own project/assembly in production applications. This topic demonstrates how to break out the entity model into its own assembly.
The Silverlight and WPF tutorials encourage you to add your entity model to one of the existing projects: the Web Application project in Silverlight examples; the lone application project in the 2-tier WPF example.
As your application evolves and begins to add other projects that need to reference the entity model, you may wish you had put the entity model in its own project. You don't have to start over; it's pretty easy to extract it as its own project and re-link the projects that depend upon it.
Here you will find step-by-step instructions for Silverlight and non-Silverlight applications. The Silverlight case is the primary scenario as it requires attention to the linking between full .NET and Silverlight assemblies. You can follow along with the zip file attached to this page which contains both "before" and "after" C# Silverlight solutions.
Be sure to backup the entire solution before you begin.
The new entity model project is a full .NET class library.
Starting in Visual Studio 2010:
In the multi-tier scenarios, the entity model tends to be defined in the web application project; this is always true for Silverlight and also for n-tier WPF demonstrations.
Move the Entity Framework model (.edmx), the .tt file, and all custom model classes into DomainModel
This section only applies to Silverlight applications built using DevForce 6.0.9 and earlier.
The links to your entity model are now broken and likely display the yellow warning triangle icon.
You must delete those links before proceeding.
You should have a .tt file and a DevForce code-generated file under that .tt file.
You probably also have a code-generated file appears under the .edmx file, that's the Entity Framework getting involved when it should not.
This regenerates the code file under the DomainModel namespace and adds the minimally required references at the same time:
Make sure you moved over all of the custom model files that you wrote (e.g., custom entity class files and metadata files).
The re-located, re-generated entity model classes are now defined in the default namespace for the model project, DomainModel. That is typically what you want.
It also means that your model namespace references elsewhere are stranded under the old name. You have to clean them up.
Start with the custom classes you moved into the DomainModel project. A Customer partial class, for example, is still defined under its old namespace. Use search-and-replace to swap in the new namespace for all of the custom classes in this project only.
Do not search-and-replace the namespace in other projects, especially not your application project. The old namespace name remains legitimate for non-model classes. You are likely to succeed simply by adding "using DomainModel;" statements to the class files that need them. Let the compiler be your guide. Be patient for now.
You can postpone this exercise by resetting the default namespace for the DomainModel project to the old namespace name as it was before we moved these files. That namespace is probably the default namespace of the Web Application project.
The entity class file is re-generated again, restoring the entity classes to their old namespace.
You can come back and fix this later. The longer you wait, the more you'll have to clean up.
Build the DomainModel project. It should build cleanly or be easy to fix as it has no dependencies on other projects in your solution.
You may need to add one more DevForce library if you are referencing it in any custom class.
If this is a non-Silverlight application, you're almost done. Skip ahead to the "Finish the Non-Silverlight Application" section.
This section applies only to Silverlight applications. Non-Silverlight applications simply reference the DomainModel project.
In this topic, our assumption is that you want a separate Silverlight application project to parallel the separate full .NET DomainModel project we just created.
Now you're ready to link to the entity model class files in the DomainModel project.
Add Silverlight assembly references:
Build the DomainModel.SL project. It should build cleanly or be easy to fix as it has no dependencies on other projects in your solution.
Almost there!
The most likely compile errors will be missing references to your re-factored model project. The entity classes have a new namespace. Adding some "using DomainModel;" statements to the class files that need them should do the trick.
Almost there!
The most likely compile errors will be missing references to your re-factored model project. The entity classes have a new namespace. Adding some "using DomainModel;" statements to the class files that need them should do the trick.