Sharing WCF Collection Types between Service and Client

• Download source - 14.8 Kb

Introduction

In this article, I will illustrate an example of sharing types between services and clients in Windows Communication Foundation (WCF) including types in multiple assemblies and custom collection types.

Background

Making the decision to share types between WCF service and clients can be controversial. Service Oriented Architecture (SOA) purists will tell you that you should never share types between services and clients; you should only share contracts. So you should carefully consider the decision to share types between clients and services. In one application I am working on, I am controlling both the client and service, and will for the foreseeable future. As I started implementation, it quickly became obvious that I would have to copy (or factor out in some way) a fair amount of code to support sharing only contracts, so I decided to share the types themselves on this project.

After I made the decision to share types, one of the resources that pointed me in the right direction was an article on The Code Project by Mike Robsiki titled Sharing Types Between WCF Services and Client. It shows the basic syntax for using SvcUtil.exe to generate a proxy using shared types, but it does not cover topics such as using types from multiple assemblies, or collection types. This article addresses these additional topics.

This article assumes you have a basic understanding of WCF. For other Code Project articles regarding WCF, check out this link.

Source Code Overview

The source code for this article contains a Visual Studio 2005 solution with four projects: a service (ShareTypes.Service), client (ShareTypes.Client), and two common class libraries (ShareTypes.Common1, ShareTypes.Common2). The common libraries contain the classes that are shared between the service and client. Both the service and client projects are console applications. The configuration for both the client and service are hard coded for this example.

Shared Types

There are two assemblies containing types to be shared between the service and client. The ShareTypes.Common1 assembly defines three classes:

using System.Collections.ObjectModel;
using System.Runtime.Serialization;

namespace ShareTypes.Common {
   [DataContract]
   public class SharedType1 {
      public SharedType1() {
         Item = new SharedCollection1();
         ItemWithContractNotShared = new CollectionWithContractNotShared();
      }

      [DataMember]
      public SharedCollection1 Item;

      [DataMember]
      public CollectionWithContractNotShared ItemWithContractNotShared;
   }

   [CollectionDataContract]
   public class SharedCollection1:Collection<string /> {
      public void AddArray( string[] toAdd ) {
         foreach ( string s in toAdd ) {
            Add( s );
         }
      }
   }

   [CollectionDataContract]
   public class CollectionWithContractNotShared: Collection<string /> {
      public void AddArray( string[] toAdd ) {
         foreach ( string s in toAdd ) {
            Add( s );
         }
      }
   }
}

The SharedType1 class is decorated with the DataContract attribute, and has fields marked with the DataMember attribute. Each field is a collection. SharedCollection1 is intended to be shared between the client and server, while CollectionWithContractNotShared will not be shared between client and service. For convenience in this example, I have used public fields rather than private fields with corresponding public properties. This is not recommended for production applications.

Note that the collections are marked with the CollectionDataContract attribute rather than the DataContract attribute. This is necessary (but not sufficient) to share collection types between services and clients and affects the generated proxy as will be seen later.

The ShareTypes.Common2 assembly defines two classes, both of which are to be shared between client and service:

using System.Collections.ObjectModel;
using System.Runtime.Serialization;

namespace ShareTypes.Common {
   [DataContract]
   public class SharedType2 {
      public SharedType2() {
         Item = new SharedCollection2< int >();
      }

      [DataMember]
      public SharedCollection2< int > Item;
   }

   [CollectionDataContract]
   public class SharedCollection2< T >: Collection< T > {
      public void AddArray( T[] toAdd ) {
         foreach ( T o in toAdd ) {
            Add( o );
         }
      }
   }
}

Service

The service itself is very simple. Each method accepts one of the types with a collection as a public field and returns a collection from the instance passed as a parameter. Each method echoes the collection values passed as a parameter. Here is the service interface and implementation:

[ServiceContract]
public interface IService {
   [OperationContract]
   SharedCollection1 UseSharedTypes1( SharedType1 sharedType );

   [OperationContract]
   SharedCollection2< int > UseSharedTypes2( SharedType2 sharedType );

   [OperationContract]
   CollectionWithContractNotShared UseCollectionWithContractNotShared( SharedType1 sharedType );

   [OperationContract]
   NonSharedCollection UseNonSharedTypes( NonSharedType nonSharedType );
}

public class Service: IService {
   public SharedCollection1 UseSharedTypes1( SharedType1 sharedType ) {
      return sharedType.Item;
   }

   public SharedCollection2 UseSharedTypes2( SharedType2 sharedType ) {
      return sharedType.Item;
   }

   public CollectionWithContractNotShared UseCollectionWithContractNotShared( SharedType1 sharedType ) {
      return sharedType.ItemWithContractNotShared;
   }

   public NonSharedCollection UseNonSharedTypes( NonSharedType nonSharedType ) {
      return nonSharedType.Item;
   }
}

The service project also defines some types that are not shared between the client and service:

[DataContract]
public class NonSharedType {
   public NonSharedType() {
      Item = new NonSharedCollection();
   }

   [DataMember]
   public NonSharedCollection Item;
}

public class NonSharedCollection: Collection< int > {}

Hosting the service

The following code hosts the service. To enable the SvcUtil.exe to be able to create a proxy for our service, we need to enable metadata exchange. To enable metadata exchanges we need to add the ServiceMetadataBehavior to the service and add a service endpoint. (Note the use of the static CreateMexTcpBinding method on the MetadataExchangeBindings class to create a binding for metadata exchange. There are methods to create bindings for various protocols.)

public static void Main() {
   Uri baseAddress = new Uri( "net.tcp://localhost:9042/Service" );
   Uri mexAddress = new Uri( "mex", UriKind.Relative );
   using ( ServiceHost serviceHost = new ServiceHost( typeof( Service ), baseAddress ) ) {
      NetTcpBinding binding = new NetTcpBinding();

      serviceHost.AddServiceEndpoint( typeof ( IService ), binding, baseAddress );

      // Add metadata exchange behavior to the service

      serviceHost.Description.Behaviors.Add( new ServiceMetadataBehavior() );

      // Add a service Endpoint for the metadata exchange

      serviceHost.AddServiceEndpoint( typeof ( IMetadataExchange ), 
          MetadataExchangeBindings.CreateMexTcpBinding(), mexAddress );

      // Run the service

      serviceHost.Open();
      Console.WriteLine( "Service started. Press enter to terminate service." );
      Console.ReadLine();
      serviceHost.Close();
   }
}

Client

SvcUtil.exe command line

Before writing client code, we must generate a proxy class for the service. To share types between a service and client, you must generate the proxy using the SvcUtil.exe command line tool, rather than adding a service reference in Visual Studio. (In the Orcas version of Visual Studio, more SvcUtil.exe options will be available within the IDE and this may no longer be necessary). The following shows the command line required to generate the client proxy. It is included in the client project source in UpdateServiceReference.bat (in the batch file, it is all on one line, but is wrapped here for readability):

"c:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\SvcUtil" 
      /language:cs 
      /out:ServiceClient.cs  
      /namespace:*,ShareTypes.Client 
      /noconfig
      /reference:..\ShareTypes.Common1\bin\Debug\ShareTypes.Common1.dll
      /reference:..\ShareTypes.Common2\bin\Debug\ShareTypes.Common2.dll
      /collectionType:ShareTypes.Common.SharedCollection1 
      /collectionType:ShareTypes.Common.SharedCollection2`1 
      net.tcp://localhost:9042/Service/mex

The options relevant to sharing types between client and service are the reference and collectionType switches. The reference switch (short form: /r), instructs SvcUtil.exe to use types in the referenced assembly directly, rather than generating client side versions of them; basically, this prevents SvcUtil.exe from generating code for the types in these assemblies. You can specify the reference switch multiple times. For types that are not collections, this is all you need to do to share types between clients and services.

For collection types, there is an additional step necessary to share types between the client and service, which is adding the collectionType switch (short form: /ct). Each occurrence of the collectionType switch identifies a collection type that will be shared between the service and client. The collectionType switch must identify a type that is defined within an assembly specified in a reference switch.

The expression in the collectionType switch for SharedCollection2 is followed by a back quote (`) and a 1. For generic types, you must specify the number of generic parameters with a back quote followed by the number of generic parameters (one for SharedCollection2). Do not confuse the back quote (`) with the single quote ('). (On my keyboard, the back quote is under the tilde (~)).

If a collection is marked with the CollectionDataContract attribute and is in an assembly identified in a reference switch, but is not identified in a collectionType switch, it will not be shared between the client and service. The CollectionWithContractNotShared class in the ShareTypes.Common1 assembly demonstrates this. It is marked with the CollectionDataContract attribute, but is not mentioned explicitly in a collectionType switch. Because it is not in a collectionType switch, there is a client side type generated for it.

The following code excerpt shows a portion of the generated client proxy with the attributes omitted for clarity:

public interface IService
{
    ShareTypes.Common.SharedCollection1 UseSharedTypes1(ShareTypes.Common.SharedType1 sharedType);
    ShareTypes.Common.SharedCollection2 UseSharedTypes2(ShareTypes.Common.SharedType2 sharedType);
    ShareTypes.Client.CollectionWithContractNotShared UseCollectionWithContractNotShared(ShareTypes.Common.SharedType1 sharedType);
    int[] UseNonSharedTypes(ShareTypes.Client.NonSharedType nonSharedType);
}

For the two methods using shared types, their return values are from the ShareTypes.Common namespace. For the method returning a CollectionWithContractNotShared, it is referencing the class generated on the client side as described above. The final method, UseNonSharedTypes, illustrates the default behavior when a collection is returned from a service, which is to output the results as an array. So using the CollectionDataContract attribute on the CollectionWithContractNotShared forced a client side class to be generated deriving from List<T>:

public class CollectionWithContractNotShared : System.Collections.Generic.List<string />
{
}

For an in depth discussion of collection types in data contracts, refer to the MSDN article Collection Types in Data Contracts.

Client Code

The client code to call the service follows (with interspersed comments). All types being shared from the common assemblies are prefixed with Common to identify the common namespace. The first two method calls demonstrate usage of shared types, with parameter and return values types prefixed by Common.

private static void Main() {
   EndpointAddress endpointAddress = new EndpointAddress( "net.tcp://localhost:9042/Service" );
   NetTcpBinding binding = new NetTcpBinding();

   using ( ServiceClient proxy = new ServiceClient( binding, endpointAddress ) ) {
      Common.SharedType1 sharedType1 = new Common.SharedType1();
      sharedType1.Item.AddArray(  new string[] { "1", "2", "3", "4", "5" } );
      Console.WriteLine( string.Format( "Calling UseSharedTypes1 with collection values {0}", 
              GetValues( sharedType1.Item ) ) );
      Common.SharedCollection1 sharedCollection1 = proxy.UseSharedTypes1( sharedType1 );
      Console.WriteLine( string.Format( "Returned UseSharedTypes1 values {0}", 
              GetValues( sharedCollection1 ) ) );
      Console.WriteLine( "" );

      Common.SharedType2 sharedType2 = new Common.SharedType2();
      sharedType2.Item.AddArray( new int[] { 3, 2, 1 } ) ;
      Console.WriteLine( string.Format( "Calling UseSharedTypes2 with collection values {0}", 
              GetValues( sharedType2.Item ) ) );
      Common.SharedCollection2 sharedCollection2 = proxy.UseSharedTypes2( sharedType2 );
      Console.WriteLine( string.Format( "Returned UseSharedTypes2 values {0}", 
              GetValues( sharedCollection2 ) ) );
      Console.WriteLine( "" );

The third method call returns an instance of CollectionWithContractNotShared. It does not use a common type as a return value; it uses one generated on the client side. In this case, we can still use the AddArray method on the SharedType1 instance to add values going into the method, but the AddArray method is not available on the returned collection because it is referencing the proxy generated type (not prefaced by Common).

      sharedType1 = new Common.SharedType1();
      sharedType1.ItemWithContractNotShared.AddArray( new string[] { "1", "2" } );
      Console.WriteLine( string.Format( "Calling UseCollectionWithContractNotShared with collection values {0}", 
              GetValues( sharedType1.ItemWithContractNotShared ) ) );
      CollectionWithContractNotShared collectionWithContractNotShared = 
                      proxy.UseCollectionWithContractNotShared( sharedType1 );
      Console.WriteLine( string.Format( "Returned UseCollectionWithContractNotShared values {0}", 
              GetValues( collectionWithContractNotShared ) ) );
      Console.WriteLine( "" );

The last method call shows the standard behavior with types that are not shared between the service and client. This method returns an array of integers. And since the NonSharedType referenced was generated on the client side, the Item collection property is generated an array of integers.

      NonSharedType nonSharedType = new NonSharedType();
      nonSharedType.Item = new int[] { 5, 4, 3, 2, 1 };
      Console.WriteLine( string.Format( "Calling UseNonSharedTypes with collection values {0}", 
              GetValues( nonSharedType.Item ) ) );
      int[] collectionNonShared = proxy.UseNonSharedTypes( nonSharedType );
      Console.WriteLine( string.Format( "Returned UseNonSharedTypes values {0}", 
              GetValues( collectionNonShared ) ) );
      Console.WriteLine( "" );

      Console.WriteLine( "Press enter to continue." );
      Console.ReadLine();
   }
}   

The following screen shot represents the results of running the client program. You must first start the service application before you can run the client (or the batch file to create the client proxy).

A Design Note

As I mentioned at the beginning of the article, sharing types between a WCF service and client can be controversial, and many people frown upon ever doing it. However, as you can see from the code to share types on the client side, the decision to share types is completely controlled by the client. If you omit the reference and collectionType switches in the call to SvcUtil.exe, you are no longer sharing types with the service. There are two important points here:

• There is nothing special in the WCF service interface or implementation to allow type sharing with the client.
• Because you share types between a service and one client, it does not mean you must share types between that service and all clients. So you can have one .NET client that shares types, and other clients that do not share types.

So if you want to share types between the service and client, go ahead, there's little risk in doing so, as long as you do nothing special in the service that assumes types will be shared with the client. You should also isolate the types to be shared between the service and client into separate assemblies, and ensure these assemblies have as few dependencies as possible (for example, these assemblies should probably not contain data access). Otherwise, you may find that you need unwanted assemblies on the client side.

History

• September 4, 2007 - Initial publication

References

• Sharing Types Between WCF Services and Client
• ServiceModel Metadata Utility Tool (Svcutil.exe)
• Collection Types in Data Contracts

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 6 of 6 (Total in Forum: 6) (Refresh) FirstPrevNext

No proxy.cs file getting generated when use /r Jigar B Patel 0:17 24 Apr '08   Well, This is what something i was looking for. But when i use /r (or /refernece) in svcutil, it does not generate Proxy.cs file, but only the config file. I read on other sites that it is a bug with svcutil. Any alternative to this. Regards ~Paras Sign In·View Thread·PermaLink Generating constants using svcutil syamala_1981 20:18 11 Dec '07   Thanks for the post. It was very helpful. I dont know whether this is the correct place to post this but I have a doubt using svcutil to generate the code. I have an application where a class is being shared across the client (WPF) and the server (WCF). I have used svcutil to generate the server proxy. The service interface and the common class were generated but the generated common class does not have constants with it. In other words, svcutil generated only the private data members of the class. I could not generate those constants on the proxy. I need those constants in the UI. How can I generate the constants using svcutil? FYI, I have used the following command to generate the code: svcutil.exe http://localhost:8000/MyService/?wsdl /out:MyServiceClient.cs /noconfig Thanks in advance, Ravi Kumar Sign In·View Thread·PermaLink Well written and insightful. Daniel Vaughan 19:34 6 Dec '07   Thanks for sharing your insight Joe. I like this article. It's well written, detailed, yet not verbose. Gets my 5. Cheers, Daniel Daniel Vaughan LinkedIn Profile ShelfSpy Sign In·View Thread·PermaLink Why not add a reference the types on the client? uwittig 4:28 14 Sep '07   Hi Joe, You say, you have control of both server and client. Why do you use svcutil instead of simply referencing the server types on the client? I do so in my project (windows forms applications with a wcf service as business logic and database server) and I don't see anything wrong with it. Greetings, Uwe Sign In·View Thread·PermaLink Re: Why not add a reference the types on the client? JoeWirtley 4:56 14 Sep '07   Fundamentally, there is nothing to prevent you from doing WCF development without using svcutil at all. To make the types available on the client, I do just end up referencing the assemblies. Svcutil generates the proxy for the client side, and using the reference/collection switches prevents it from creating client side versions of all of the referenced types. I find it convenient to use svcutil to generate the proxy rather than doing it by hand, which is my other choice. If you wanted to create the client side code by hand, then you never need to use svcutil. When the types are shared, there is much less code in the client side proxy, so it's definitely more feasible to write it by hand. From a process perspective, using svcutil also helps keep the client at an arms length from the service. I'm comfortable sharing parameter types between the client and service, but I definitely don't want to share any service implementation. Using svcutil helps me maintain that separation (not a big deal either way, but a factor). Thanks, Joe Sign In·View Thread·PermaLink Re: Why not add a reference the types on the client? Pete O'Hanlon 5:03 14 Sep '07   Fundamentally, in your own applications, this isn't a problem. However, svcutil comes into its own when you want to share definitions with others outside your organisation. Deja View - the feeling that you've seen this post before. Sign In·View Thread·PermaLink

Last Visit: Monday, December 1, 2008 6:40 PM     Last Update:Monday, December 1, 2008 6:40 PM