Separate the model project

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.

Add a Model project

 The new entity model project is a full .NET class library.

Starting in Visual Studio 2010:

• From the menu: File | Add | New Project...
• Select the Class Library template
• Ensure the top-left ComboBox says ".NET Framework 4" 
• Name it to match the entity model's namespace; we'll call ours "DomainModel"
• Delete Class1

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

• Select each model-file (you can do all at once with ctrl-mouse-click)
• Drag them to DomainModel
• Delete these files from the web application project ( reminder: back-up the solution first )
• Add a DomainModel project reference to the web application project
  
  

Delete model file links in the Silverlight application project

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.

• Remove all links to the entity model class files (
• Delete the now empty Shared Code folder (if you had one)

You must delete those links before proceeding.

Finish the Model project

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. 

• Open the "Properties" window for the .edmx file by typing Alt-Enter
• Notice that the "Custom Tool" entry says EntityModelCodeGenerator.
  • Clear the "Custom Tool" entry (it should be empty).
  • The Entity Framework generated code file disappears
• Right-mouse-click the .tt file
• Pick "Run Custom Tool"

This regenerates the code file under the DomainModel namespace and adds the minimally required references at the same time:

• IdeaBlade.Core
• IdeaBlade.EntityModel
• IdeaBlade.Validation
• .NET's System.ComponentModel.DataAnnotations

Make sure you moved over all of the custom model files that you wrote (e.g., custom entity class files and metadata files).

Fix Model namespace references

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.

How to postpone namespace update

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. 

• Open the properties editor for the DomainModel project
• On the "Application" tab, set the "Default namespace" to the previous model namespace value
• Close that tab
• Right-mouse-click the .tt file
• Pick "Run Custom Tool"

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 Model project

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.

• IdeaBlade.Linq (only if needed)
• Select that reference and open its "Properties Window"
• Set the "Specific Version" to False

If this is a non-Silverlight application, you're almost done. Skip ahead to the "Finish the Non-Silverlight Application" section.

Add a Silverlight Model project

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.

• From the menu: File | Add | New Project...
• Select the Silverlight Class Library template
• Name it to match the entity model's namespace with a .SL suffix; we'll call ours "DomainModel.SL"
  • Choose the "Silverlight 4" version if asked.
• Delete Class1
• Press Alt-Enter on the new project to open its Properties
• On the "Silverlight" tab set the "Default namespace:" to DomainModel (i.e., remove the ".SL" suffix.

Now you're ready to link to the entity model class files in the DomainModel project.

• Press Alt-Shift-A to launch the "Add Existing Item" dialog
• Navigate to the DomainModel project that holds the full .NET model files
• Select every file code file (.cs or .vb); do not select any other file type.
• Do not click the "Add" button
• Drop down the ComboBox next to the "Add" button and pick "Add As Link".

Add Silverlight assembly references:

• Add DevForce references
  • IdeaBlade.Core
  • IdeaBlade.EntityModel
  • IdeaBlade.Validation
  • IdeaBlade.Linq (if needed)
• Select all of them and open the "Properties Window"
• Set their "Specific Version" to False
• Add .NET references
  • System.ComponentModel.DataAnnotations
  • System.Runtime.Serialization

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.

Finish the Silverlight Application

Almost there! 

• Add a reference to the DomainModel.SL project.
• Build the entire solution, correcting as necessary.
• Run.

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. 

Finish the Non-Silverlight Application

Almost there! 

• Add a reference to the DomainModel project.
• Build the entire solution, correcting as necessary.
• Run.

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.