Another new WCF feature that's part of .NET 3.5 SP1 has to do with better support for object references. DataContractSerializer has always supported serializing object references and dealing with graphs, including cycles, and not just simple trees. But doing so is not the default behavior -- you have to tell DataContractSerializer that you want it to preserve object references when you instantiate it.

Let's look at a simple example. Supposed that you have the following cyclic object graph (I'm assuming the same Person type that I used in my previous post):

Person p = new Person();

p.Id = "123";

p.Name = "Aaron";

p.Spouse = new Person();

p.Spouse.Id = "456";

p.Spouse.Name = "Monica";

p.Spouse.Spouse = p;

...

And now let's supposed that you want to serialize it. If you create the DataContractSerializer using the default constructor, it will throw an exception when it identifies the cycle during serialization. However, you can tell DataContractSerializer to preserve object references using one of the other constructors:

DataContractSerializer dcs = new DataContractSerializer(typeof(Person),

    null, int.MaxValue, false, true /* preserve object refs */, null);

using (FileStream fs = new FileStream("person.xml", FileMode.Create))

{

    dcs.WriteObject(fs, p);

}

The resulting person.xml file now looks like this:

<Person z:Id="1" xmlns="http://schemas.datacontract.org/2004/07/SerializationSp1" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:z="http://schemas.microsoft.com/2003/10/Serialization/">

  <Id z:Id="2">123</Id>

  <Name z:Id="3">Aaron</Name>

  <Spouse z:Id="4">

    <Id z:Id="5">456</Id>

    <Name z:Id="6">Monica</Name>

    <Spouse z:Ref="1" i:nil="true"/>

  </Spouse>

</Person>

Notice that each reference type has been given an “Id” attribute and the nested Spouse reference refers back to the containing Person via the Ref attribute, thereby preserving the references within the XML.

Now, as of SP1, the definitions for the Id/Ref attributes are now part of the generated schema. If you run SvcUtil.exe /dconly over the assembly containing Person, it will produce a schema file for the “http://schemas.microsoft.com/2003/10/Serialization” namespace. And within that schema, you'll find the following definitions for Id/Ref, which are defined as ID/IDREF types:

...

<xs:attribute name="Id" type="xs:ID" />

<xs:attribute name="Ref" type="xs:IDREF" />

...

ID and IDREF are standard DTD/XSD types that are widely supported across platforms.

One problem with employing this object-reference-preservation technique is that you don't have direct control over how the DataContractSerializer is constructed when defining your WCF services. You can, however, implement a behavior that intercepts the standard serializer creation process so that you can enable this feature. Sowmy provides a complete example of how to accomplish this over on his blog.

One of the new WCF features in .NET 3.5 SP1 is that DataContractSerializer now supports serializing types that aren’t annotated with any serialization attributes like [DataContract] or [Serializable].

If you were using DataContractSerializer prior to SP1, you had to follow the rules outline by Sowmy here. These rules illustrate that for custom classes you have a few choices. You can annotate the class with [DataContract] and [DataMember] to define an attribute-based mapping or implement IXmlSerializable to define a custom mapping. Or you can annotate the class with [Serializable] to automatically map all fields (like with .NET Remoting) or implement ISerializable to take things into your own hands (assuming IXmlSerializable wasn't used).

However, as you can see from the rules, there is no allowance for types that haven’t been annotated with one of these serialization attributes or that implement one of the serialization-related interfaces, or in other words, you can't serialize “plain old C# objects“ (POCO for short).

The support for [Serializable] provided a nice migration path for traditional .NET Remoting types, which was nice, but the lack of support for POCO types meant you couldn’t move your ASMX types over to the DataContractSerializer without sprinkling a bunch of new attributes on them.

With .NET 3.5 SP1 you can serialize any C# object even if it doesn’t come with any serialization attributes. For example, the following Person type is now serializable by default:

namespace SerializationSp1

{

    public class Person

    {

        private string id;

        public string Id { get { return id; } set { id = value; } }

        public string Name;

        public Person Spouse;

    }

    ...

}

 

For POCO types, DataContractSerializer only includes the public read/write fields and properties into the resulting XML Infoset. So in our example above, the private “id” field won’t make it into the message. Also, these types must have a public default (no argument) constructor in order to be serialized. The Person type above works find because the compiler gives us a public default constructor but if you were to add a non-default constructor, it would no longer be serializable using this approach.

With this new support, you can use virtually any C# type (with a public default constructor) in your WCF service contracts and you don’t have to worry about changing the serializer back to XmlSerializer using [XmlSerializerFormat]. For example, the following service contract works as-is in .NET 3.5 SP1:

[ServiceContract]

public interface ILookupPerson

{

    [OperationContract]

    Person GetPerson(string id);

}

 

Now let’s take a look at the serialized XML for the Person type shown above. Here’s a simple console program that uses DataContractSerializer to serialize a Person object:

class Program

{

    static void Main(string[] args)

    {

        Person p = new Person();

        p.Id = "123";

        p.Name = "Aaron";

        p.Spouse = new Person();

        p.Spouse.Id = "456";

        p.Spouse.Name = "Monica";

 

        DataContractSerializer dcs = new DataContractSerializer(typeof(Person));

        using (FileStream fs = new FileStream("person.xml", FileMode.Create))

        {

            dcs.WriteObject(fs, p);

        }

    }

}

And here’s what the resulting person.xml file looks like:

<Person xmlns="http://schemas.datacontract.org/2004/07/SerializationSp1"

        xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

  <Id>123</Id>

  <Name>Aaron</Name>

  <Spouse>

    <Id>456</Id>

    <Name>Monica</Name>

    <Spouse i:nil="true"/>

  </Spouse>

</Person>

The mapping algorithm is similar to what’s used with [DataContract] or [Serializable] – it uses the type name for the root element name, member names for the local element names, and it orders them alphabetically. It also produces a reasonable XML namespace based on the .NET namespace. The only difference is how it chooses what to put into the message – in this case it’s based on the public contract of the type. When you use this approach, you must be happy with the XML that DataContractSerializer gives you. In other words, you can’t customize the resulting XML in any way.

As soon as you place the [DataContract] attribute on the class, DataContractSerializer will only include fields/properties annotated with [DataMember] once again. For example, suppose I make the following change to the Person type by annotating it with [DataContract]:

[DataContract]

public class Person

{

    private string id;

    public string Id { get { return id; } set { id = value; } }

    public string Name;

    public Person Spouse;

}

 

If I run my console program again, the resulting person.xml now looks like this:

<Person xmlns="http://schemas.datacontract.org/2004/07/SerializationSp1"  
        xmlns:i="http://www.w3.org/2001/XMLSchema-instance"/>

Notice that none of the fields were serialized because they weren’t annotated with [DataMember]. Once I applied [DataContract] to Person, DataContractSerializer no longer treated it like a POCO type. The same would hold true if I annotated the type with [Serializable]. If it finds the [Serializable] attribute, it falls back to the [Serializable] mapping and only includes the fields.

To summarize, the new DataContractSerializer provides several different mechanisms for defining the serialization mapping:

1.        Simply rely on the public interface and take the default XML mapping

2.        Use [Serializable] to only include fields in the mapping

3.        Use [DataContract] and [DataMember] and apply some basic customization

4.        Use IXmlSerializable or ISerializable for advanced mapping customization

I was actually surprised to learn that they added this feature because it goes against the main reason for the original [DataContract] design (“boundaries are explicit”), at least according to the team in early design reviews. I asked for this feature (an implicit mapping) but my request was dismissed for that very reason. Despite whatever principle it may violate, I like it, because it makes it simpler for folks to get started with WCF and it provides an easier migration path for ASMX.

Scott Guthrie announced the availability of .NET 3.5 SP1 and Visual Studio 2008 SP1 today. If you read his entry, you'll see this release is packed with new features, many of which revolve around the Ajax, MVC, and ADO.NET improvements they've been working on.

However, this release also contains some new WCF nuggets including the following:

• New Hosting Wizard for WCF Service projects.
• Enhancements in Test Client such as support for RM Sessions, Message Contract and Nullable types enables testing of broader set of WCF-based services.
• Expanding reach of DataContract Serializer by relaxing the need of having [DataContract]/ [DataMember] on types and by supporting an interoperable mechanism for dealing with object references.
• Improved Partial Trust Debugging Experience with support for Event Log.
• Support for ADO.NET Entity Framework entities in WCF contracts.
• Improvements in writing REST based services ranging from easily supporting ServiceDocuments publication and consumption to providing greater control and usability of UriTemplate.
• Significant performance improvements on large workflow-based projects in Visual Studio.
• Considerable scalability increases for hosted WCF services in IIS7-integrated mode.

Update: Steve Maine provides more WCF details in this post and Omri gives his take over here.

You can read more about this release and grab the bits from here.

Steve Martin, director of product management for Microsoft's Connected Systems Division (CSD), just announced their plans for the next version of BizTalk Server on his blog. It will be called BizTalk Server 2006 R3.

This new version will be updated to work with Windows Server 2008, SQL Server 2008, and Visual Studio 2008. It will also be updated with the following SOA-related features:

• New web service registry capabilities with support for UDDI v3.0
• Enhanced service enablement of applications through new and enhanced adapters
• Enhanced service enablement of “edge” devices through BizTalk RFID Mobile
• Enhanced interoperability and connectivity support for B2B protocols (like SWIFT, EDI, etc)
• SOA patterns and best practices guidance to assist our customer’s implementations

From reading his blog, it doesn't look like they'll be adding official support for hosting WF workflows in this particular release. It looks like we may have to wait for that until Oslo.

I just wrapped up DevWeek 2008, a wonderful developer conference held each year in London. This show brings in some of the best attendees around...I always really enjoy my time here. I'm sitting in my hotel here decompressing before my long journey home. Here are the demos from my sessions: 

• Programming WCF (workshop)
• The ABC's of Programming WCF
• Message-Oriented WCF
• SOAP, REST, POX, & RSS
• Getting Started with BizTalk Server 2006 R2 (workshop)

Thanks again to the attendees for making this a great event once again, for all the thought provoking questions and discussions along the way. Hope to see you again next year!

I'm going to especially miss the Indian food and running along the Thames each morning. I had some Springbok one night while taking a break from India -- quite good actually.

Richard and Carl had me on .NET Rocks today, show #308. Fun stuff.

This showed up in my inbox yesterday and it was one of those love at first sight moments. How is it that Apple always seems to produce things that I can't seem to live without? They're on a roll. However, I'll probably wait until v2 of this bad boy...hopefully the price of the solid state hard drives will come down a bit by then.

Another nice surprise yesterday -- Apple finally added multi-recipient SMS to iPhone 1.1.3! They also shipped a GPS-like feature into Google Maps that triangulates via cell towers. Plus home screen customization.

My last Service Station column on Extending WCF with Custom Behaviors is online (it's actually been online for a little while now but I missed blogging about it with the holiday craze). Here's the abstract:

Windows^® Communication Foundation (WCF) provides numerous extensibility points that allow developers to customize the runtime behavior for service dispatching and client proxy invocation. You can tap into these extensibility points by writing custom behaviors that can be applied declaratively to your services. This month I'll show you how this process works.

It's that wonderful time of the year again. I have four fundamental career goals for 2008:

1. Provide more value to customers through improved training content and products
2. Increase the effectiveness of our website
3. Publish more technical/training content on this blog
4. Follow the Oslo wave and explore new areas of interest

I also have one crazy personal goal for 2008:

1. Run my first marathon

I have a bunch of other personal goals that I won't bore you with but suffice it to say that 2008 is going to be an interesting year in a lot of ways -- a year of huge change (hmm, perhaps I should run for President).

Microsoft just released a new Web site that aggregates a bunch of BizTalk blogs.  However, I should also point out that when they say “BizTalk“ blogs, they are also covering .NET 3.x and other related technologies. Several of us from Pluralsight are included in the list of aggregated blogs.

This short demo illustrates how to take advantage of the message template feature made available by WCF send ports in BizTalk Server 2006 R2.

This short demo illustrates how to configure a WCF send port to invoke multiple WCF operations by configuring an operation name -> action mapping.

WS-MetadataExchange is a wonderful thing. WCF implements this spec and provides support for it over several different transport protocols including HTTP(S), TCP, and named pipes. All you have to do is choose the appropriate MEX binding.

If you're familiar with how bindings work in WCF, this all makes perfect sense. However, if you pull out .NET Reflector and begin looking for the various System.ServiceModel.Channels.Binding-derived classes, you might be surprised when you don't find any.

I was surprised because when you specify MEX endpoints in configuration, there is a separate binding name for each supported MEX transport (mexHttpBinding, mexHttpsBinding,  mexNamedPipeBinding, and mexTcpBinding). The trick is these binding element names don't map to individual classes but rather to a single class named MetadataExchangeBindings, which provides four public static methods: CreateMexHttpBinding, CreateMexHttpsBinding, CreateMexNamedPipeBinding, and CreateMexTcpBinding, as illustrated here:

public static class MetadataExchangeBindings

{

    // Methods

    public static Binding CreateMexHttpBinding();

    public static Binding CreateMexHttpsBinding();

    public static Binding CreateMexNamedPipeBinding();

    public static Binding CreateMexTcpBinding();

    ...

}

If you inspect the implementation of any of these methods, you'll notice they just create one of the built-in bindings, adjusting some of the defaults, and then they override the binding name and namespace as illustrated here:

public static Binding CreateMexHttpBinding()

{

    return CreateHttpBinding();

}

private static WSHttpBinding CreateHttpBinding()

{

    WSHttpBinding binding = new WSHttpBinding(SecurityMode.None, false);

    binding.Name = "MetadataExchangeHttpBinding";

    binding.Namespace = "http://schemas.microsoft.com/ws/2005/02/mex/bindings";

    return binding;

}

In the case of CreateMexHttpBinding, they use the WSHttpBinding but set the security mode to SecurityMode.None. Because they're basically just using the other built-in bindings, they probably figured it wouldn't make sense to define completely new binding classes just for the MEX scenarios...they're really just slightly different configurations.

Obviously this also means that you don't have to actually use the MEX binding element names (or MetadataExchangeBinding) when configuring endpoints to use MEX. Instead you can use the corresponding built-in binding directly as long as you configure it properly for the MEX scenario (like in the example above, I have to set the security mode to SecurityMode.None when using WSHttpBinding).

This short demo illustrates how to use a custom WCF binding via the WCF-Custom adapter in BizTalk Server 2006 R2 -- in this case I show you how to call a WCF service using HTTP and the binary message encoding.

If you run Microsoft Virtual PC on Windows Vista (running via Bootcamp) on your MacBook Pro (I know, I know), you've probably been frustrated by the lack of a real Right-ALT key, which is what you'd normally use to switchin in and out of full-screen mode (the full-screen key sequence is Right-ALT + Enter).

Well, I finally stumbled across a little gem that allows you to remap the “host key“ in Microsoft Virtual PC. The host key allows the “host“ to capture control of the mouse and keyboard from a virtual machine -- and by default it's configured to be Right-ALT. You can remap the “host key” as follows:

1. In the Microsoft Virtual PC console window, select File | Options
2. Select Keyboard
3. Then in the right pane, click on the “Current host key“ text box and press the new key you want to map. I pressed the Right-Apple key on my machine.
4. Press OK and you're done

Once you've done this, you can press Right-Apple + Enter to toggle full-screen mode on your MacBook.