Generating the Implementation

Retired Content

The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site.

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Retired: November 2011

Creating the Solution Structure

The first step in generating the implementation for the services is to create a project that the code will be generated into. This project is referred to as the solution structure. You can unfold the solution structure by completing exercise 5 in the Hands On Lab - Building a Web Service (VS2010).

The Project Mapping Table

Project mapping is a technology built into the Service Factory that provides a level of decoupling between the models and the projects that they will generate code into. Figure 1 illustrates the relationship between the mapping tables in the ProjectMapping.xml file and the solution structure.


Figure 1

Project mapping tables associate the model elements and the Visual Studio projects

The ProjectMapping.xml file can be created and changed in the following ways:

The next sections describe each of these.


When you use the Add ASMX/WCF Implementation Projects recipe, all the project mappings are created when the solution structure is unfolded. The name of the mapping table is the same as the name you provide when you create the implementation projects.

With a Recipe

If you would rather create each of the projects individually in a solution folder, you can use the Populate Project Mapping Table recipe. This recipe uses the suffix of the project names to associate roles to the projects. The following strings are all of the appropriate suffixes to be used in project names:

  • “Host”
  • “Client”
  • “BusinessLogic”
  • “BusinessEntity”
  • “DataContract”
  • “FaultContract”
  • “ServiceContract” *
  • “MessageContract”
  • “ServiceImplementation”

* The ServiceContract project will automatically be associated with the ServiceContract and MessageContract roles.


If you have already created projects and you want to use the Service Factory to generate code into them, you have to make manual changes to the ProjectMapping.xml file. However, because the project mappings are represented in an XML document, the document can be edited in an XML editor (such as the one provided in Visual Studio). The following XML snippet is an example of a project mapping.

    ProjectPath="\GeneratedCode" ProjectName="MyServiceContract">
        <Role Name="ServiceContractRole" />
        <Role Name="MessageContractRole" />

The ProjectName attribute is provided for the sole purpose of manually editing the file. It is not used by the project mapping technology in the Service Factory. This means that if a project name changes, it will not automatically be updated in the ProjectMapping.xml file—it must be changed manually. However, this change is not required. The value of the ProjectId attribute is the GUID for the Visual Studio project. You can find this value in the ProjectGuid element inside of the Visual Studio project file.

For more information about the project mapping table, see the “Project Mapping Table” section in the Code Generation Extensions topic.

Code Generation

You can generate code from the models—and you might choose to do so for single shapes or for the whole model. However, the code generation framework does not cross models even if there are dependency relationships established between the models.

This version of the Service Factory is only capable of generating Visual C# code and XML for configuration files. During the development of the Service Factory, we tested the architecture to make sure that it can generate Visual Basic .NET by creating a text template for data contracts. This text template is in the Service Factory source code to serve as an example to anyone wanting to create the other Visual Basic .NET text templates.

One of the principals of the Service Factory code generation capability is that the user should never manually change code that was generated. To facilitate this, the Double Derived pattern has been applied to generated classes that will need to be changed. This pattern can be seen in any service implementation class. Exercise 8 in the Hands On Lab - Building a Web Service (VS2010) walks you through the process of extending the service implementation through the use of partial classes and method overloading.