Browse by Tags

• Answers
• Messages
• Proxies
• Service Model

• Differences in Guid Serialization

  Why do the guids in my contract turn into strings when generating a client? You're probably mixing different types of serializers between the client and service. There's nothing wrong with this and the generated client will work correctly but you don't get the user-friendly types. To see why, let's look at the metadata. A guid in a contract with the DataContractSerializer generates a type in the http://schemas.microsoft.com/2003/10/Serialization/ namespace that looks like this: < xs:element name ="guid" nillable ="true" type ="tns:guid" /> < xs:simpleType name ="guid" > < xs:restriction base ="xs:string" > < xs:pattern value ="[\da-fA-F]{8}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{12}" /> </ xs:restriction > </ xs:simpleType > On the other hand, a guid in a contract with the XmlSerializer generates a type in the http://microsoft.com/wsdl/types/ namespace that looks like this: < xs:simpleType name ="guid" > < xs:restriction base ="xs:string" > < xs:pattern value ="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}" /> </ xs:restriction > </ xs:simpleType > These generated types are needed because a guid is not a primitive type. DataContractSerializer came after XmlSerializer so it recognizes both definitions but XmlSerializer has to rely on the schema when it sees a DataContractSerializer guid. Since the schema is based on a string type, the generated client field is a string. The same thing happens with other serializers that don't know how to map a particular schema pattern to a user-friendly type. Next time: TCP Throttling Read More... Posted Thursday, January 31, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Service Model, Contracts, Proxies, Serialization

• ContractNamespaceAttribute

  Back when I did an overview of custom namespaces , I omitted any namespace declarations that wouldn't appear in the final metadata. One of those declarations is the default namespace for data contracts. I had two example data contracts, one for faults and one for normal messages, although they actually work exactly the same in practice. [DataContract(Namespace = "http://example.com/faultcontract/datacontract" )] public class MyFault { [DataMember] public string detail; } [DataContract(Namespace = "http://example.com/datacontract" )] public class MyData { [DataMember] public string data; } These data contracts include an explicitly declared XML namespace. However, you can modify the test program in the earlier article to see what happens when those namespace declarations are removed. What you end up with is an ugly looking namespace based on a fixed prefix http://schemas.datacontract.org/2004/07/ and a suffix that is the CLR namespace. If you want to get rid of that default namespace for every data contract you define, then you can add a ContractNamespaceAttribute to the assembly. This attribute defines the default XML namespace for data contracts that are located in a particular CLR namespace. You can retrieve a ContractNamespaceAttribute in the standard way for assembly attributes by calling GetCustomAttributes on the assembly with the ContractNamespaceAttribute type. Next time: Configuring SSL Certificates for Vista Read More... Posted Wednesday, October 10, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 1 Comments Filed under: Indigo, Service Model, Contracts, Serialization

• Serializing UniqueId

  Why can't UniqueId be serialized? Data contracts only have native support for a limited set of types. If you use a type that is not in this native set, then you'll get an exception that the data contract is invalid unless you decorate the type with attributes that explain how the type should be serialized. Adding attributes requires you to change the type, which means that there are going to be many types in the world that can't be used with data contracts. This includes types in the framework. System.Xml.UniqueId is an example of a type that lacks native support in the data contract implementation. It doesn't mean that there's anything wrong with that type, just that it can't be used with the data contract serialization mechanism. Other serializers will still work with the UniqueId type. For instance, XmlDictionaryWriter has native support to turn a UniqueId into a string, so the UniqueId type can be used with XML serialization. Next time: Service Contract Generation Read More... Posted Friday, August 10, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Service Model, Contracts, Serialization

• Custom Namespaces

  If you've ever looked at a generated WSDL file, you may be wondering how all of the different parts of the service description are reassembled to form WSDL. Today's article is about the namespaces in the WSDL file. Here's an example service that provides a unique custom namespace to each of the most common parts of the service description. using System; using System.ServiceModel; using System.ServiceModel.Channels; using System.ServiceModel.Description; using System.Runtime.Serialization; [DataContract(Namespace = "http://example.com/faultcontract/datacontract" )] public class MyFault { [DataMember] public string detail; } [DataContract(Namespace = "http://example.com/datacontract" )] public class MyData { [DataMember] public string data; } [MessageContract(IsWrapped = true , WrapperNamespace = "http://example.com/messagecontract" )] public class MyMessage { [MessageHeader(Namespace = "http://example.com/messageheader" )] public string header; [MessageBodyMember(Namespace = "http://example.com/messagebodymember" )] public string member; } [ServiceContract(Namespace = "http://example.com/servicecontract" )] public interface IService { [FaultContract( typeof (MyFault), Namespace = "http://example.com/faultcontract/operationcontract" )] [OperationContract] void Operation1(MyData data); [OperationContract] void Operation2(MyMessage message); } [ServiceBehavior(Namespace= "http://example.com/servicebehavior" )] public class Service : IService { public void Operation1(MyData data) { } public void Operation2(MyMessage message) { } } class Program { static void Main( string [] args) { ServiceHost host = new ServiceHost( typeof (Service), new Uri( "http://localhost:8000/" )); Binding binding = new CustomBinding( new TextMessageEncodingBindingElement(), new HttpTransportBindingElement()); binding.Namespace = "http://example.com/binding" ; host.AddServiceEndpoint( typeof (IService), binding, "" ); host.Description.Behaviors.Add( new ServiceMetadataBehavior()); host.AddServiceEndpoint( typeof (IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex" ); host.Open(); Console.ReadLine(); host.Close(); } } You can run svcutil against this service to generate all of the WSDL and schema files. Now, we have a way to work backwards from the elements in the WSDL file to find where they are defined in the service description. Running svcutil gives me three WSDL files and seven schema files. One of the schema files covers the standard serialization types that are Read More... Posted Monday, August 06, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Service Model, Contracts, Serialization

• Data Contract and Message Contract

  I have an existing web service that I need to replace with a WCF web service. How do I choose between using a data contract and a message contract? There are actually three choices to consider for describing the messages that your service uses: data contracts, message contracts, and XML serialization. You will be forced to use XML serialization in some cases because you have an existing message format with precise specification of XML elements and attributes that you need to replicate. In these cases, it may simply be impossible to duplicate this exact XML schema with a message or data contract-based description, forcing you to use XML serialization to describe the messages. However, let's assume that the existing message format is not so unreasonable and you have a choice between the various options for describing messages with contracts. How do you choose between data contracts and message contracts? The choice may not always seem clear if both types of contracts are capable of describing your messages. A rule of thumb though is that data contracts are generally portable between different kinds of XML encodings, making this option preferable if you might choose to project the Infoset differently in the future. Message contracts are more limited in the projections that they can support but are reasonably adept at mimicking the most common types of XML messages produced today. Therefore, there is a preference to use data contract, followed by message contract and XML serialization. However, the ability to adapt to a preset form is ranked in the reverse order. When you're required to conform to an existing message layout, you are more likely to be forced to use message contracts. When you are designing new message layouts, you almost always want to use data contracts. Next time: Message Disposal Read More... Posted Wednesday, July 25, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Messages, Service Model, Contracts, Serialization