All About Interop : WCF

Enable .NET 3.5 goodies in IIS vdir

DotNetInterop — Fri, 05 Dec 2008 20:29:00 GMT

Some of you may be oddballs like me: you like .NET, you program in .NET, but you don't always use Visual Studio. You hand-code everything for some applications. You often open up a text editor and just start writing a source module, with no wizards, no project templates, etc. You hand-code your MSbuild files. You hand-code your web.config files.

Oddballs like us cannot rely on the code-generation that comes with Visual Studio. So when we write a new ASP.NET application, and we want to use the .NET 3.5 goodies in that app - things like var types, and LINQ - we need to explicitly specify that we want .NET 3.5 compilation. Same is true if you are writing a WCF service and want to use REST or any of the var types or LINQ.

I've done this twice now and had to search for the way to do it both times. I'm putting here as a "note to self" and also as a reference for anyone else. These are the custom magic incantations for web.config, if you want to enable .NET 3.5 in your ASP.NET app, or in your WCF Service - eg, the cool REST stuff from .NET 3.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <system.web>
    <compilation debug="false">  
      <assemblies>  
        <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>  
        <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
      </assemblies>  
    </compilation>  
  </system.web>


  <system.codedom>  
    <compilers>  
      <compiler language="c#;cs;csharp" extension=".cs"   
                type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"   
                type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="OptionInfer" value="true"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
    </compilers>  
  </system.codedom> 

</configuration>

Geneva supports OASIS WS-Trust, SAML

DotNetInterop — Fri, 07 Nov 2008 19:09:00 GMT

Last week at the PDC 2008, Microsoft released the public beta of “Geneva”.

“Geneva” is three things:

Geneva Server. This is a security token service (STS), as defined in the OASIS WS-Trust specification. This thing issues and transforms claims, manages user access, and enables automated federation.

Geneva Framework. This is a managed (.NET) Framework that helps developers build claims-aware applications and services, that connect to the STS. You can use it to process claims on either side of an authorization transaction (requestor or responder).

Windows CardSpace Geneva. This is just an extension of the CardSpace thing in Windows you know and love today. chances are, you've seen it, but you don't use it. In a nutshell - CardSpace is a set of Windows features and user-interface that lets users navigate access decisions and control how personal information is used. Everyone has multiple claims as part of their identity: you are a student at UW, you are an employee of BigCorp, you are a member in good standing of a particular club, you have received a particular security clearance, You have a bank account with number 4444-444-44 at BigBank, etc. CardSpace lets you decide which of the many claims you can make about your identity, to disclose to a particular service or server. Rather than disclosing "everything" about you to every server or service, you disclose only what you need to disclose for the particular transaction. That is one aspect of the identity model, and CardSpace is the thing in Windows that makes that possible.

CardSpace technology, and actually, the Identity Metasystem concept, is pretty cool. If you haven't looked at it, you should. The problem with CardSpace and more generally, using claims-based access control (CBAC) in an application, has always been that it was impractical. Microsoft delivered a client (CardSpace), but we didn't deliver an STS! And we didn't deliver an easy way for the server to evaluate and verify claims. Therefore developers didn't have an easy way to employ CBAC in their apps. Geneva will change this.

Now, some of you are thinking, "ok, this sounds interesting but I don't know what you are talking about with this WS-Trust thing and 'claims based access control'. And I can understand that. Here's the thing - instead of hand-crafting access-control logic into your application, instead of managing your own user list and access control list, you can "outsource" this job to an STS. The Authorization Manager (sometimes called AzMan) is similar in philosophy, so if you understand the utility of AzMan, then you will get the idea of CBAC. But AzMan is not standards based, not federated, not truly claims-based (it is role based, which is less general than claims-based), and not usable in Web services transactions. Imagine generalizing AzMan and federating it and using only standard protocols, and that's where we're headed with Geneva. You're gonna want to use this.

I said "Geneva is standards based." The key to standards is support by the vendors, in tools, frameworks, servers, and so on. Currently, WCF from Microsoft supports WS-Trust, as does the WSIT from Sun. WebSphere App Server v7.0 announced support for WS-Trust just last month, but I haven't had the time to test it with Geneva. Not sure of other frameworks. The key is, with Geneva, the server is now here, and people can and will start building on this. I think with the release of the Geneva CTP, we'll start to see broader adoption of WS-Trust and standards-based CBAC among frameworks.

One last thing to point out: In the cloud, the Microsoft Services Connector and the .NET Access Control Service, both announced at PDC as well, are built on “Geneva” technology and share the same claims architecture.

More Information:
Kim Cameron’s blog
Vittorio Bertocci’s blog
Get the Geneva beta
Single stop resource on Geneva

A list of “Geneva” sessions recordings at PDC:

code	Title	Presenter(s)	Link
BB11	Identity Roadmap for Software + Services	Kim Cameron and Vittorio Bertocci	http://channel9.msdn.com/pdc2008/BB11/
BB42	Identity: "Geneva" Server and Framework Overview	Stuart Kwan and Caleb Baker	http://channel9.msdn.com/pdc2008/BB42/
BB43	Identity: "Geneva" Deep Dive	Jan Alexander	http://channel9.msdn.com/pdc2008/BB43/
BB44	Identity: Windows CardSpace "Geneva" Under the Hood	Rich Randall	http://channel9.msdn.com/pdc2008/BB44/

REST in WCF: Varying response content type based on HTTP Request Headers

DotNetInterop — Wed, 05 Nov 2008 00:39:00 GMT

Damian Mehers made a comment on my blog post from April, but I felt it was worth a full reblog.

Damian's used the same WCF extensibility points I used to produce some boilerplate that varies the response content type from JSON to XML, based on the Accept or Content-Type header of the GET request. He extends WebHttpBehavior to return an IDispatchMessageFormatter that does either JSON or XML.

    class WebHttpBehavior2Ex : WebHttpBehavior
    {
        protected override IDispatchMessageFormatter GetReplyDispatchFormatter(OperationDescription operationDescription, 
                                                                               ServiceEndpoint endpoint)
        {
            WebGetAttribute webGetAttribute = operationDescription.Behaviors.Find<WebGetAttribute>();
            DynamicResponseTypeAttribute mapAcceptedContentTypeToResponseEncodingAttribute = 
                operationDescription.Behaviors.Find<DynamicResponseTypeAttribute>();
 
            if (webGetAttribute != null && mapAcceptedContentTypeToResponseEncodingAttribute != null) {
                // We need two formatters, since we don't know what type we will need until runtime
                webGetAttribute.ResponseFormat = WebMessageFormat.Json;
                IDispatchMessageFormatter jsonDispatchMessageFormatter = 
                    base.GetReplyDispatchFormatter(operationDescription, endpoint);
                webGetAttribute.ResponseFormat = WebMessageFormat.Xml;
                IDispatchMessageFormatter xmlDispatchMessageFormatter = 
                    base.GetReplyDispatchFormatter(operationDescription, endpoint);
                return new DynamicFormatter() { 
                    jsonDispatchMessageFormatter = jsonDispatchMessageFormatter, 
                    xmlDispatchMessageFormatter = xmlDispatchMessageFormatter };
            }
            return base.GetReplyDispatchFormatter(operationDescription, endpoint);
        }
    }

And then in the DynamicFormatter code, he just picks the formatter as appropriate:

    class DynamicFormatter : IDispatchMessageFormatter
    {
        public IDispatchMessageFormatter jsonDispatchMessageFormatter { get; set; }
        public IDispatchMessageFormatter xmlDispatchMessageFormatter { get; set; }
 
        public void DeserializeRequest(System.ServiceModel.Channels.Message message, object[] parameters)
        {
            throw new NotImplementedException();
        }
 
        public System.ServiceModel.Channels.Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result)
        {
            Message request = OperationContext.Current.RequestContext.RequestMessage;
 
            // This code is based on ContentTypeBasedDispatch example in WCF REST Starter Kit Samples
            // It calls either 
            HttpRequestMessageProperty prop = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
 
            string accepts = prop.Headers[HttpRequestHeader.Accept];
            if (accepts != null)
            {
                if (accepts.Contains("text/xml") || accepts.Contains("application/xml"))
                {
                    return xmlDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                }
                else if (accepts.Contains("application/json"))
                {
                    return jsonDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                }
            }
            else
            {
                string contentType = prop.Headers[HttpRequestHeader.ContentType];
                if (contentType != null)
                {
                    if (contentType.Contains("text/xml") || contentType.Contains("application/xml"))
                    {
                        return xmlDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                    }
                    else if (contentType.Contains("application/json"))
                    {
                        return jsonDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                    }
                }
            }
            return xmlDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
        }
 
    }

It's pretty nifty and it requires no changes to the app logic. You need to use a custom ServiceHost and use a custom attribute on each Operation. Because it uses the HTTP headers and not the URI itself to determine content-type of the response, I think it has some nice benefits over the approach I described in April.

Damian's got a full VS2008 solution will all the boilerplate code.

check it out.

It just got easier to build REST apps in .NET

DotNetInterop — Thu, 30 Oct 2008 00:48:00 GMT

The REST starter kit that we launched at PDC is now live! :: http://www.msdn.com/wcf/rest .

The WCF REST Starter Kit is a set of features, Visual Studio templates, samples and guidance that help people build REST apps using WCF. WCF, part of the .NET Framework, got some enhancements for REST support in the .NET 3.5 release. This starter kit is a bunch of blueprints and supporting material to make it easier to use what is in the Framework for REST.

Like, blueprints and guidelines for how to do caching, security, error handling, help page support, conditional PUT, push style streaming, type based dispatch and semi-structured XML support. Whoa!

The WCF REST Starter Kit also provides Visual Studio templates for creating REST style services such as an Atom feed service, a REST-RPC hybrid service, Resource singleton and collection services and an Atom Publishing Protocol service. In addition, there are samples, documentation and other guidance that help to use these new capabilities.

The goal is to provide a toolset that simplifies building RESTful services today, and to take feedback from the developer community on the features provided in the WCF REST Starter Kit that will shape future REST capabilities in WCF 4.0.

Interop sessions at Oracle Open World

DotNetInterop — Sat, 27 Sep 2008 06:43:00 GMT

Jesus and my collegue Kent Brown both spoke at Oracle Open World recently, on interop between WCF and WebLogic.

http://weblogs.asp.net/gsusx/archive/2008/09/19/speaking-at-oracle-open-world.aspx

But I found out after the fact! nice!

WSDL-First in WCF, versus WSDL-First in ASMX

DotNetInterop — Thu, 25 Sep 2008 18:25:00 GMT

I wanted to point something out regarding the WSDL-First item I posted yesterday.

This is a look at the interface generated by the SvcUtil.exe tool for WCF.

    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
    [System.ServiceModel.ServiceContractAttribute(Namespace="urn:Microsoft.Search",
         ConfigurationName="Ionic.Samples.Webservices.Sep21.IResearchServiceSoap")]
    public interface IResearchServiceSoap
    {
 
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Registration",
           ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Registration(string registrationXml);
 
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Query",
           ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Query(string queryXml);
 
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Status",
           ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Status();
    }

It looks quite similar to the interface that you can generate using the appropriate wsdl.exe tool if you would prefer to use the ASMX (or System.Web.Services) stack that first shipped in .NET v1.1, and continues to be available in .NET 3.5.

[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.42")]
[System.Web.Services.WebServiceBindingAttribute(Name="ResearchServiceSoap", Namespace="urn:Microsoft.Search")]
public interface IResearchServiceSoap {
 
    /// <remarks/>
    [System.Web.Services.WebMethodAttribute()]
    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("urn:Microsoft.Search/Registration", 
        RequestNamespace="urn:Microsoft.Search", 
        ResponseNamespace="urn:Microsoft.Search", 
        Use=System.Web.Services.Description.SoapBindingUse.Literal, 
        ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
    string Registration(string registrationXml);
 
    /// <remarks/>
    [System.Web.Services.WebMethodAttribute()]
    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("urn:Microsoft.Search/Query", 
        RequestNamespace="urn:Microsoft.Search", 
        ResponseNamespace="urn:Microsoft.Search", 
        Use=System.Web.Services.Description.SoapBindingUse.Literal, 
        ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
    string Query(string queryXml);
 
    /// <remarks/>
    [System.Web.Services.WebMethodAttribute()]
    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("urn:Microsoft.Search/Status", 
        RequestNamespace="urn:Microsoft.Search", 
        ResponseNamespace="urn:Microsoft.Search", 
        Use=System.Web.Services.Description.SoapBindingUse.Literal, 
        ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
    string Status();
 
}

So as you can see, it is a very similar model. Different attributes support the different runtimes (System.Web.Services versus WCF), but it is very parallel.

WSDL-First development with WCF

DotNetInterop — Wed, 24 Sep 2008 18:36:00 GMT

A couple weeks ago I mentioned that you could do WSDL-First development with WCF, but I didn't go into detail as to how that would work. Somebody asked, so I guess I'll describe the specific steps. I want to use a real scenario, so for a WSDL, I will use the WSDL that Microsoft defines for Microsoft Office Research Services.

Did you get that? Microsoft Office defines a WSDL for Research Services. Any Microsoft Office program, Office 2003 or Office 2007, can call out to any service that implements the given Research Service wire contract. Office programs are web services clients. Ok, we're all clear on that, right?

And this it may be counter intuitive for some people. The client application, in this case, Microsoft Office, specifies the on-the-wire contract, the WSDL. Lots of people have a server-centric design perspective, and assume that the server defines the contract. That often makes sense, but not in this case. Because there are so many deployments of Microsoft Office out there, it makes sense for the client to define the contract.

Back to the WSDL. But let me be straight with you: on the website I referenced, I did not actually see a WSDL specifically defined for the Office Research Service. I'd expect to find it in the Schema Reference, but that reference includes XML Schema, not web services contracts. On the other hand, the Research Service SDK includes sample applications built on .NET and ASMX, and running those you can generate the WSDL that is being used. So... effectively the WSDL is implicitly published. I took some liberties with the WSDL available in that way and I came up with my own WSDL, like so:

<definitions
  xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:s="http://www.w3.org/2001/XMLSchema"
  xmlns:s0="urn:Microsoft.Search"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
  targetNamespace="urn:Microsoft.Search"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
>

  <types>
    <s:schema elementFormDefault="qualified" targetNamespace="urn:Microsoft.Search">

      <s:element name="Registration">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="registrationXml" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="RegistrationResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="RegistrationResult" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

      <s:element name="Query">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="queryXml" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="QueryResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="QueryResult" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

      <s:element name="Status">
        <s:complexType />
      </s:element>
      <s:element name="StatusResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="StatusResult" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

    </s:schema>
  </types>


  <message name="RegistrationSoapIn">
    <part name="parameters" element="s0:Registration" />
  </message>
  <message name="RegistrationSoapOut">
    <part name="parameters" element="s0:RegistrationResponse" />
  </message>

  <message name="QuerySoapIn">
    <part name="parameters" element="s0:Query" />
  </message>
  <message name="QuerySoapOut">
    <part name="parameters" element="s0:QueryResponse" />
  </message>

  <message name="StatusSoapIn">
    <part name="parameters" element="s0:Status" />
  </message>
  <message name="StatusSoapOut">
    <part name="parameters" element="s0:StatusResponse" />
  </message>

  <portType name="IResearchServiceSoap">
    <operation name="Registration">
      <input  message="s0:RegistrationSoapIn"  wsaw:Action="urn:Microsoft.Search/Registration" />
      <output message="s0:RegistrationSoapOut" wsaw:Action="" />
    </operation>

    <operation name="Query">
      <input  message="s0:QuerySoapIn"  wsaw:Action="urn:Microsoft.Search/Query" />
      <output message="s0:QuerySoapOut" wsaw:Action="" />
    </operation>

    <operation name="Status">
      <input  message="s0:StatusSoapIn"  wsaw:Action="urn:Microsoft.Search/Status" />
      <output message="s0:StatusSoapOut" wsaw:Action="" />
    </operation>

    </operation>

  </portType>

  <binding name="ResearchServiceSoap" type="s0:IResearchServiceSoap">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

    <operation name="Registration">
      <soap:operation soapAction="urn:Microsoft.Search/Registration" style="document" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
    </operation>

    <operation name="Query">
      <soap:operation soapAction="urn:Microsoft.Search/Query" style="document" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
    </operation>

    <operation name="Status">
      <soap:operation soapAction="urn:Microsoft.Search/Status" style="document" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
    </operation>


  </binding>

</definitions>

Ok, starting with that WSDL, given to us by Microsoft Office, we now want to build a service that implements that WSDL, and we want to build it in WCF. We start with the svcutil.exe tool, which is shipped with the .NET SDK v3.0 , or later.

Continuing on with the thought from above: most people have a server-centric design perspective when it comes to web services; most people think the server comes first, then you build the clients...The svcutil.exe tool is also guilty of that. In fact there is documentation that describes how to build a client using the svcutil.exe tool, but as far as I know there is no doc that describes how to create a WCF service from a WSDL file using the svcutil.exe tool. We're going to fix that. Despite the fact that there is no doc for this, it is in fact a supported scenario. Constructing the service starting from the WSDL works.

Here's how you generate a server-side "stub" and the interface for that WSDL:

c:\netsdk3.0\bin\svcutil.exe /language:C# /out:IResearchService.cs /n:*,Ionic.Samples.Webservices.Sep24 ResearchService.wsdl

On the command line, I specify the output file, the language, and also the WSDL file itself. If there are external XSD files, you will need to specify those, too. In this case, the entire contract is contained within a single WSDL file. The last interesting bit is the /n switch, which I use to specify the namespace for all the generated classes. Without this switch the interface and the Data Access Objects are all generated into the default (global::) namespace, which I don't like.

You can see that I reference the .NET SDK v3.0 directory for the svcutil.exe tool. WCF first shipped in the .NET SDK v3.0. Even if you have .NET SDK 3.5 installed, (or Visual Studio 2008), you will still use the svcutil.exe from .NET 3.0. This is because of the russian-doll model of releases that .NET 2.0, 3.0 and 3.5 are.

Now, this is a command line, which is definitely not a GUI. But you can teach Visual Studio to do this for you. To do this, you need to go to the Tools menu, and select External Tools. Then click Add, and specify these settings for the svcutil tool:

Of course you have to specify the relevant path for the .NET SDK V3.0, for your installation. Regardless whether you run svcutil.exe from an MSbuild file, or from Visual Studio, here's what the generated interface looks like:

    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
    [System.ServiceModel.ServiceContractAttribute(Namespace="urn:Microsoft.Search",
        ConfigurationName="Ionic.Samples.Webservices.Sep24.IResearchServiceSoap")]
    public interface IResearchServiceSoap
    {
        
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Registration",
            ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Registration(string registrationXml);
        
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Query",
            ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Query(string queryXml);
        
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Status",
            ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Status();
        
    }

The Office Research Service interface is a bit of a bummer, because the operations on this service interface just exchange strings. No complex types here. But trust me, it works the same if you use complex types in the interface. In that case, the output source file will include a .NET DataContract definition for the various complex types, along with XML namespace settings and so on. The silly thing is that the Office Research Service does actually send back XML. But rather than use xsd:anyType to allow any XML, or even a strictly-specified XML element, the office app just specifies a string. In effect, the XML is encoded as a string. When implementing the service, you would actually instantiate an XmlDocument and load in the string you get passed, if you know what I mean. This is normally something the web services runtime would do for you, if you specify your WSDL that way. But Office did not do that.

Ok, moving on.... Now, If you are sharp-eyed, you will notice that the command line to generate the server-side stub and interface is the same command line you would use for the Client proxy. And you're right. In fact if you look in the generated file you will find some client-specific proxy classes. No problem with any of that. For the client we need those proxy classes, but for the server we don't. In a server-specific project, that generated code will remain unused, or of course you could manually remove it from the generated file.

At this point, you have the interface. Now you need the implementation. In Visual Studio, if you begin to type in a class definition, and then type in a colon and specify the name of an interface, you can right click on that interface and ask Visual Studio to generate method stubs for all the interface methods. Perfect. As well, you will need to decorate your WCF Service class with the ServiceBehavior attribute. It looks like this:

    [ServiceBehavior(Name="WcfResearchLibrary",
                     Namespace="urn:Microsoft.Search",
                     IncludeExceptionDetailInFaults=true)]

After that, you fill in the implementation for those methods. Then you need to consider the service host for your app. If it will run in IIS, then you code up a .svc file; if you want to host it in a console app, then you use some of the boilerplate I mentioned in a previous post. And so on.

Then you need to deal with the configuration settings, another issue I dealt with in the previous post. And that's pretty much it.

You have now coded a WCF Service using WSDL-First design principles.

Flatten your WSDL with this Custom ServiceHost for WCF

DotNetInterop — Tue, 23 Sep 2008 18:32:00 GMT

Yesterday I mentioned using a custom service host to flatten the WSDL that is generated by a WCF service. This is something Christian showed us all how to do a long while ago, to improve interoperability between WCF-implemented services and consumers written on other technology stacks. Flattening WSDL is important for Interop purposes becausse many tools don't digest modular WSDL very well. When I say modular WSDL, I mean WSDL that imports other WSDL's or XSDs.

I realized that I had never actually published the code for my custom WCF service host that flattens WSDL.

So here it is. [updated 146pm US/Pacific time based on Natasa's comment]

using System;
using System.Collections;
using System.Collections.Generic;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.Xml.Schema;
using ServiceDescription = System.Web.Services.Description.ServiceDescription;
 
namespace Thinktecture.ServiceModel
{
    public class FlatWsdl : IWsdlExportExtension, IEndpointBehavior
    {
        public void ExportContract(WsdlExporter exporter, WsdlContractConversionContext context) { }
 
        public void ExportEndpoint(WsdlExporter exporter, WsdlEndpointConversionContext context)
        {
            XmlSchemaSet schemaSet = exporter.GeneratedXmlSchemas;
            foreach (WsdlDescription wsdl in exporter.GeneratedWsdlDocuments)
            {
                List<XmlSchema> importsList = new List<XmlSchema>();
                foreach (XmlSchema schema in wsdl.Types.Schemas)
                    AddImportedSchemas(schema, schemaSet, importsList);
 
                if (importsList.Count == 0)
                    return;
 
                wsdl.Types.Schemas.Clear();
                foreach (XmlSchema schema in importsList)
                {
                    RemoveXsdImports(schema);
                    wsdl.Types.Schemas.Add(schema);
                }
            }
        }
 
        private void AddImportedSchemas(XmlSchema schema, XmlSchemaSet schemaSet, List<XmlSchema> importsList)
        {
            foreach (XmlSchemaImport import in schema.Includes)
            {
                ICollection realSchemas =
                    schemaSet.Schemas(import.Namespace);
 
                foreach (XmlSchema ixsd in realSchemas)
                {
                    if (!importsList.Contains(ixsd))
                    {
                        importsList.Add(ixsd);
                        AddImportedSchemas(ixsd, schemaSet, importsList);
                    }
                }
            }
        }
 
        private void RemoveXsdImports(XmlSchema schema)
        {
            for (int i = 0; i < schema.Includes.Count; i++)
            {
                if (schema.Includes[i] is XmlSchemaImport)
                    schema.Includes.RemoveAt(i--);
            }
        }
 
        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { }
 
        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { }
 
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { }
 
        public void Validate(ServiceEndpoint endpoint) { }
    }
 
 
 
    public class FlatWsdlServiceHost : System.ServiceModel.ServiceHost
    {
        public FlatWsdlServiceHost() { }
 
        public FlatWsdlServiceHost(Type serviceType, params Uri[] baseAddresses)
            : base(serviceType, baseAddresses) { }
 
        public FlatWsdlServiceHost(object singletonInstance, params Uri[] baseAddresses)
            : base(singletonInstance, baseAddresses) { }
 
        protected override void ApplyConfiguration()
        {
            Console.WriteLine("ApplyConfiguration (thread {0})",
                              System.Threading.Thread.CurrentThread.ManagedThreadId);
            base.ApplyConfiguration();
            InjectFlatWsdlExtension();
        }
 
        private void InjectFlatWsdlExtension()
        {
            foreach (ServiceEndpoint endpoint in this.Description.Endpoints)            
                endpoint.Behaviors.Add(new FlatWsdl());
        }
    }
 
 
 
    public sealed class FlatWsdlServiceHostFactory : System.ServiceModel.Activation.ServiceHostFactory
    {
        public override System.ServiceModel.ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
        {
            return base.CreateServiceHost(constructorString, baseAddresses);
        }
 
        protected override System.ServiceModel.ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            return new FlatWsdlServiceHost(serviceType, baseAddresses);
        }
    }
}

And to use this, you would specify something like this in your .svc file:

<%@ ServiceHost
    Language="C#"
    Factory="Thinktecture.ServiceModel.FlatWsdlServiceHostFactory"
    Service="Ionic.Samples.Webservices.WcfService1"%>

Custom Config file for a WCF Service hosted in IIS

DotNetInterop — Mon, 22 Sep 2008 17:14:00 GMT

I am constantly developing new WCF services to try out various techniques, ideas, scenarios.

Many times for these quickie WCF applications I will just use a text editor to write the code. As you know there are multiple options for hosting your WCF services. For these quick apps, I will typically write a simple custom console host for the WCF service, what is sometimes called "self-hosting" the WCF service. You've seen some form of this boilerplate code many times:

        public static void Main()
        {
            string addressRoot= "http://localhost:5555/";
            string endpointSuffix= "MyWcfService";
            string endpointAddress= addressRoot + endpointSuffix;

            // get the type we are hosting 
            System.Type t1 = typeof(Ionic.Samples.Webservices.MyWcfService);

            var host = 
                new System.ServiceModel.ServiceHost(t1,
                                                    new System.Uri(endpointAddress));

            // Create the binding
            var basicBinding = new System.ServiceModel.BasicHttpBinding();
            basicBinding.Namespace = "urn:Ionic.Samples";

            host.AddServiceEndpoint
                (typeof(IService),
                 basicBinding, 
                 "");

            // add the "get metadata" behavior 
            // This will allow the service to emit WSDL when tickled at the proper HTTP endpoint
            var smb= new System.ServiceModel.Description.ServiceMetadataBehavior();
            smb.HttpGetEnabled = true;
            smb.HttpGetUrl = new System.Uri(endpointAddress);
            host.Description.Behaviors.Add(smb);

            System.Console.WriteLine();

            // Open the ServiceHost to create listeners and start listening for messages
            host.Open();
            System.Console.WriteLine("Service implementation: " + t1.ToString());
            System.Console.WriteLine("Service Address: {0}", endpointAddress);
            System.Console.WriteLine("The service is ready.");
            System.Console.WriteLine();
            System.Console.WriteLine("Press <ENTER> to terminate the service.");
            System.Console.WriteLine();
            System.Console.ReadLine();

            // Close to shutdown the service
            host.Close();
        }

But sometimes I need the WCF service to run for a longer period of time, maybe permanently. This is where the IIS host makes sense - for security and lifecycle purposes. And the ASP.NET deployment stuff works nicely for WCF services - I copy the Interface (IService.cs) and the Service Implementation code to the App_Code directory of IIS, and then copy the .svc file over, and I'm nearly there. The only thing the IIS-hosted service lacks now is the service configuration.

Deploying to IIS, I don't get to use my boilerplate ServiceHost code as above. Which means I don't have the programmatic control over the endpoint and the ServiceMetadataBehavior, and I don't get to specify an endpoint and any behaviors. So of course I have to embed the relevant configuration information in the .config file, which in the case of IIS hosting, is the web.config file.

A problem comes in when hosting multiple WCF services in a single IIS virtual directory: Each Service gets its own individual .svc file, but all services share a single web.config file. If I update a service, then I need to modify that single file. If I add a service, I need to edit the file. If I remove a service, I need to edit the file. And in each case the edits and changes for one service could affect the other services, if the edits are not done properly.

Ideally I'd like the IIS-hosted WCF service to have its own configuration, independent of any other services running from that same vdir. The .svc file is completely independent. Why can't the configuration also be independent? How can I do this?

I looked around and found the ServiceHostBase.ApplyConfiguration method. If I construct a custom service host, then I can override the ApplyConfiguration method and load my service configuration from... anywhere. I decided to establish a simple convention - I will look for a file in the server directory called <ServiceName>.config. This is not <AssemblyName>.config, which is the .NET default. In this case the assembly is likely going to be dynamically generated and named. So using the assembly name to find the config file is probably not right. The next option is to use the Service Name; this is something you specify in code in the [ServiceBehavior] attribute. Assuming you select a unique name for each service, that name ought to be useful for uniquifying the configuration file.

Then, it is a simple matter of loading in the configuration file, within the custom ServiceHost. This bit of black magic does the trick for me:

        protected override void ApplyConfiguration()
        {

            // generate the name of the custom configFile, from the service name:
            string configFilename = System.IO.Path.Combine ( physicalPath,
                                                             String.Format("{0}.config", this.Description.Name));
            
            if (string.IsNullOrEmpty(configFilename) || !System.IO.File.Exists(configFilename))
                base.ApplyConfiguration();
            else
                LoadConfigFromCustomLocation(configFilename);

        }

Then there is some supporting logic, to get the physical path and to actually load the configuration:

        private string _physicalPath = null;
        private string physicalPath
        {
            get 
            {
                if (_physicalPath == null)
                {
                    // if hosted in IIS
                    _physicalPath = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;
                    if (String.IsNullOrEmpty(_physicalPath))
                    {
                        // for hosting outside of IIS
                        _physicalPath= System.IO.Directory.GetCurrentDirectory();
                    }
                }
                return _physicalPath;
            }
        }

        private void LoadConfigFromCustomLocation(string configFilename)
        {
            var filemap = new System.Configuration.ExeConfigurationFileMap();
            filemap.ExeConfigFilename = configFilename;
 
            System.Configuration.Configuration config = 
                System.Configuration.ConfigurationManager.OpenMappedExeConfiguration
                (filemap, 
                 System.Configuration.ConfigurationUserLevel.None);
 
            var serviceModel = System.ServiceModel.Configuration.ServiceModelSectionGroup.GetSectionGroup(config);
 
            bool loaded= false;
            foreach (System.ServiceModel.Configuration.ServiceElement se in serviceModel.Services.Services)
            {
                if(!loaded)
                    if (se.Name == this.Description.ConfigurationName)
                    {
                        base.LoadConfigurationSection(se);
                        loaded= true;
                    }
            }
            if (!loaded)
                throw new ArgumentException("ServiceElement doesn't exist");         
        }

And of course to make this work, you will need to specify a custom ServiceHostFactory in the .svc file. The custom service host approach is useful for lots of things; in the past I used it for WSDL-Flattening or for modifying namespaces on SOAP payloads. Of course you can have a single custom service host that combines all those capabilities, if you like. For this post I am focusing only on the config file.

<%@ ServiceHost
    Language="C#" 
    Debug="true" 
    Service="Ionic.Samples.Webservices.Sep20.CustomConfigService" 

    Factory="Ionic.ServiceModel.ServiceHostFactory"

%>

For now, the logic that reads in a unique file per service will do, but in the general case I'd like to be able to read the configuration from a remote centralized repository, like a network share or a database. That is something left for the future.

I've attached all the code here in a zipfile.

Using the WSDL-First design approach with WCF services

DotNetInterop — Fri, 05 Sep 2008 17:07:00 GMT

Couple of helpful posts from the archives for you.

If you are care about interop, then you probably want to use a contract-first or WSDL-first design for your web services. In other words, you will not simply decorate server-side code annotations (in Java) or attributes (in .NET) and generate WSDL dynamically from that running code. That approach works in demonstrations, but it does not lend itself to good interoperability in the long run.

So you start with WSDL. Since you are WCF-savvy, you are confining yourself to the subset of XML Schema that is friendly to WCF. The restriction isn't too onerous, though, especially as it improves interoperability significantly, and also simplifies your life since you don't have to read and understand all of the XML Schema spec! Ok, so following those rules, you write the WSDL. And then you generate from that WSDL the server-side stub code, and the client-side proxy code, using the web services toolkits of your choice. On the .NET side, that toolkit is obviously WCF (and the tool itself is svcutil.exe); on the Java side, maybe the JAXWS reference implementation, or AXIS2, and so on. But the trick is, the generated code on the .NET side is muy bueno if you write your WSDL following a few additional simple rules, which are not mentioned in the above linked doc.

For example, if you want to pass a collection in your interface, and you will be using WCF on one or both ends of the wire, then you want to use an explicit complexType for the array in the WSDL/XSD. This is not required by WSI Basic Profile, nor is it mentioned anywhere in the official WCF doc as far as I know. Nonetheless, follow this rule for best results. Do not define your arrays with an element and a @maxOccurs="unbounded" attribute in your schema; if you do, you will get the XmlSerializer with WCF, rather than the DataContract serializer, and that is probably not what you want. More on this tip here.

Also, use only one part in each wsdl:message (to comply with WS-I Basic Profile) and set the message part attribute @name = "parameters" to make the messages document/literal wrapped, versus bare. If you're not sure, you want wrapped.

Finally, another tip: when using collections in service interfaces (or more specifically, data contracts), you can use the svcutil.exe tool to specify that collections be represented in the generated .NET code as one of the Generic collection types, rather than a vanilla array. This is done with the /collectionType option on the svcutil.exe command line. See this post for more detail on that idea.

I think there might be a similar codegen hint on other web services toolkits but I could not find the right switch on AXIS2.

Web services interop with WCF - Relevant Forum Questions

DotNetInterop — Thu, 04 Sep 2008 17:45:00 GMT

I was just browsing the WCF forum on MSDN. Here's a summary of the recent interesting threads dealing with interop:

Check it out.

How to Build REST apps on .NET using WCF

DotNetInterop — Fri, 22 Aug 2008 19:03:00 GMT

There's a new screencast series on building services using the WCF part of .NET.

The first few are already available. The first one is the basic "Hello World" example, the next couple cover REST:

How to build a WCF Service using Visual Studio 2008, and .NET 3.5. (10 minutes)

Creating a HI-REST GET Service with WCF 3.5 sp1 (15 minutes)

Consuming a HI-REST GET Service From Silverlight 2 (Beta 2)

How to Shape the URI in REST services built on WCF (See also, the accompanying blog post.)

There will be more to come, too, covering Content Negotiation, Atom, and more. Stay tuned!

Facebook Thrift, Google ProtoBufs, and Interop

DotNetInterop — Thu, 10 Jul 2008 21:49:00 GMT

Dare had an en-pointe analysis of the emergence of various new non-standarcd communications protocols, such as Facebook Thrift and Google Protocol buffers, and how they compare to the standards-based comms protocols like RSS, ATOM or even WS-*. Dare correctly points out that these tools can be useful if you tightly control the endpoints involved in the communication, and, if you're certain the set of communicating endpoints will never expand to include anything you don't tightly control (acquisition? partner?).

[I updated this blog entry a couple days after it was first published. The text added is enclosed in square brackets.]

After one is accustomed to fire and police protection, and very smooth roads, and storm sewers that keep the roads clear when it rains, it can be easy to forget, and to chafe under the income tax burden that keeps all those government systems functioning.

In the same way, paying the angle-bracket-tax can get annoying after a while, too. Starting in 1999 or so, we, as an industry, moved away from binary [remote-procedure call] protocols such as those dragged in by DCE RPC, CORBA IIOP, Microsoft DCOM, or Java RMI. Instead we have invested heavily in the development of tools and frameworks that use an XML-based message-passing paradigm to improve interop. We achieved critical mass on [message-based]communication standards, and everyone was happy. Except now some of us are not, and we apparently want RPC again.

We want binary serialization because it is so darn efficient. We want opaque data formats because those angle brackets are just so tiresome.

Well, we embrace those efficiencies at our peril. We have been here before! I am not saying that there is no place for Protocol Bugg^H^Hffers. What I am saying is that we as an industry shifted to XML-based message passing for a good reason, and that reason has not disappeared. We're used to the smooth roads and working sewers. Let's not have a revolution and toss all that aside. Use optimized communications where it makes sense. [And don't drag in RPC when all we want is binary serialization.] Dare shows the way.

Last thing - just dreaming a bit here... wouldn't it be cool for developers if there was a single programming framework that could do angle brackets as well as optimized binary transfers? [And everything was a message? Not a remote procedure call in sight?] Wouldn't it be cool if you could code it once, and then select the serialization mechanism at configuration time, in metadata. Wait, wouldn't it be even coooler if .. this is gonna sound crazy, but.... wouldn't it be cool if we could have multiple communication endpoints running at the same time, each dedicated to a different wire protocol, but using the same backing business logic. One endpoint could speak XML, another could speak binary, and they could run at the same time. That would be cool, wouldn't it?

New WCF + WF blog: Endpoint

DotNetInterop — Mon, 07 Jul 2008 18:49:00 GMT

A New Blog started last week, aggregating WCF and WF topics. If you're like me you have really good intentions about reading blogs, you have your subscriptions all organized, you download the content through outlook daily... but then when it comes down to it, it's hard to keep up with reading them all.

Now there's one blog to subscribe to for WCF and WF stuff. Endpoint.

This one is run by my colleague, Cliff Simpkins, but it's not a one-man-show. He posts his own stuff, but he also aggregates content from other places and brings in guest posters. This should be really good.

Varying Content-Type according to the URL in a WCF REST Service

DotNetInterop — Thu, 03 Apr 2008 18:20:00 GMT

My buddy Justin wrote about how to set the Content-Type headers in a WebGet method in a WCF REST app. Doing this would allow each WebGet method to specify its own Content-Type at runtime.

After I summarized how to build a WCF REST app in a post a couple weeks ago, Kyle Beyer asked if there was a way to avoid hard-coding the Content-Type in the WebGet attribute on the method.

One question ... Do you know of a way to get a WCF service to honor the 'Content-Type' HTTP header instead of hard coding the content type via an attribute on the method? I would really like to create a service that has a single set of methods which returns JSON/XML based on the HTTP header(s) ... suggestions?

Taking a page from the White House Press spokesperson, rather than answering Kyle's question, I'm going to answer a different question, a question I would like to answer. The question I will answer is, how can I create a service that has a single set of methods that returns JSON or XML depending on the URL tickled (and not on the Accept header)?

This is a little different than what Kyle wants, but it may be good enough. What I mean is this: a single method decorated with [WebGet] can deliver JSON or XML, depending on the URI. We can specify http://server/Foo/3782982/json and get json, or specify http://server/Foo/3782982/xml and get plain-old-XML.

We can do this without any extra code in the Operation method itself. In fact the operation method doesn't care whether it is JSON or XML. How do we pull this off?

My trick was to use a custom ServiceHost. It automagically enables Content-Type selection by URL, for all WebGet
operations that are decorated with a special marker attribute. (ionic.samples.WcfRest.DynamicContentType).

The service host works its magic by cloning the OperationDescription for all operations in the service contract that are specially marked. One copy of the OperationDescription gets WebMessageFormat.Xml and the other gets WebMessageFormat.Json. They get differing UriTemplates so WCF can disambiguate (double word score). Both clones point to the same method in the service class, so there is no duplication of application code.

Here's what the service host looks like:

    1     public class MagicContentTypeSelectingServiceHost : ServiceHost
    2     {
    3 
    4         public MagicContentTypeSelectingServiceHost(Type t, params Uri[] baseAddrs) : base(t, baseAddrs) { }
    5 
    6 
    7         public MagicContentTypeSelectingServiceHost(object singletonInstance, params Uri[] baseAddresses)
    8             : base(singletonInstance, baseAddresses) { }
    9 
   10 
   11         public MagicContentTypeSelectingServiceHost() : base() { }
   12 
   13 
   14         protected override void OnOpening()
   15         {
   16             TraceMe("");
   17             TraceMe("");
   18             ServiceEndpointCollection sec = this.Description.Endpoints;
   19             foreach (ServiceEndpoint se in sec)
   20             {
   21                 TraceMe("Endpoint: ");
   22                 TraceMe("  Address: {0}", se.Address.ToString());
   23                 TraceMe("  Contract: {0}", se.Contract.ToString());
   24 
   25                 var opsToAdd = new List<OperationDescription>();
   26                 foreach (OperationDescription opDesc in se.Contract.Operations)
   27                 {
   28                     object[] attrs = opDesc.SyncMethod.GetCustomAttributes(typeof(ionic.samples.WcfRest.DynamicContentType), false);
   29                     if ((attrs != null) && (attrs.Length == 1))
   30                     {
   31                         TraceMe("  operation: {0}", opDesc.Name);
   32                         TraceMe("    Marked with {0} attribute", typeof(ionic.samples.WcfRest.DynamicContentType));
   33 
   34                         WebGetAttribute wga =
   35                           opDesc.Behaviors.Find<WebGetAttribute>();
   36 
   37                         if (wga != null)
   38                         {
   39                             if (wga.IsResponseFormatSetExplicitly)
   40                             {
   41                                 throw new System.Exception
   42                                   (String.Format("On method '{0}', there are conflicting attributes. When using the " +
   43                                                   "custom service host {1}, on a method that is marked with {2}, the " +
   44                                                   "ResponseFormat in the WebGet attribute must be omitted.",
   45                                                   opDesc.Name,
   46                                                   this.GetType().ToString(),
   47                                                   typeof(ionic.samples.WcfRest.DynamicContentType)));
   48 
   49                             }
   50 
   51                             TraceMe("    Cloning this operation ...");
   52 
   53                             // Now, clone this OperationDescription.
   54                             // We can copy references to all properties, except those we are changing. 
   55                             // The only thing that is changing is the WebGetAttribute, so 
   56                             // we must actually new up one of those. 
   57 
   58                             OperationDescription od = new OperationDescription(opDesc.Name + ".clone", opDesc.DeclaringContract);
   59 
   60                             string rootTemplate = wga.UriTemplate;
   61                             WebGetAttribute wga2 = null;
   62                             foreach (System.ServiceModel.Description.IOperationBehavior b in opDesc.Behaviors)
   63                             {
   64                                 if ((b as System.ServiceModel.Web.WebGetAttribute) != null)
   65                                 {
   66                                     wga2 = new WebGetAttribute();
   67                                     if (wga.IsBodyStyleSetExplicitly)
   68                                         wga2.BodyStyle = wga.BodyStyle;
   69 
   70                                     if (wga.IsRequestFormatSetExplicitly)
   71                                         wga2.RequestFormat = wga.RequestFormat;
   72 
   73                                     // Now, differentiate the two WebGetAttribute instances with the ResponseFormat.
   74                                     // The original OperationDescription gets XML, the clone gets JSON
   75                                     wga.ResponseFormat = WebMessageFormat.Xml;
   76                                     wga2.ResponseFormat = WebMessageFormat.Json;
   77                                     wga.UriTemplate = rootTemplate + "/xml";
   78                                     wga2.UriTemplate = rootTemplate + "/json";
   79 
   80                                     od.Behaviors.Add(wga2);
   81 
   82                                 }
   83                                 else
   84                                     od.Behaviors.Add(b);
   85                             }
   86 
   87                             foreach (System.ServiceModel.Description.MessageDescription md in opDesc.Messages)
   88                                 od.Messages.Add(md);
   89 
   90                             foreach (System.ServiceModel.Description.FaultDescription fd in opDesc.Faults)
   91                                 od.Faults.Add(fd);
   92 
   93                             od.SyncMethod = opDesc.SyncMethod;
   94 
   95                             // remember to add this OperationDescription to the service contract
   96                             opsToAdd.Add(od);
   97                         }
   98                     }
   99                 }
  100 
  101                 // add the cloned operation descriptions to the ServiceContract
  102                 foreach (OperationDescription od in opsToAdd)
  103                     se.Contract.Operations.Add(od);
  104             }
  105             base.OnOpening();
  106 
  107             TraceMe("");
  108             TraceMe("");
  109         }
  110 
  111     }

You can see on lines 58 through 96, the OperationDescription for a marked operation gets cloned. Then on line 103, the cloned operation gets added into the ServiceContract.

The operation in the service interface looks the same as any operation, except it is marked with an attribute, like this:

    1       [OperationContract]
    2       [ionic.samples.WcfRest.DynamicContentType]
    3       [WebGet(
    4           BodyStyle = WebMessageBodyStyle.Bare,
    5         UriTemplate = "dyn/{orderId}")]
    6       ReplyMsg GetOrderInfoEx(string orderId);

The UriTemplate gets changed transparently at runtime by the custom service host. The effective UriTemplate is "dyn/{orderId}/json" for the JSON flavor, and "dyn/{orderId}/xml for the plain-old-XML flavor.

This service host works in self-hosted apps as well as those hosted within IIS. Not exactly what Kyle asked for but this could do the trick for some of you. The code is attached to this post.

Be sure to test thoroughly before you use this in production apps.

Cheers!

[Addendum: I think you may be able to modify this custom ServiceHost idea slightly to do Content-Type negotiation based on the Accept header. You may be able to use the a slightly modified version of this ServiceHost, that clones specially marked OperationDescriptions. Along with that, add an IEndpointBehavior that sets a modified OperationSelector. Then, within your own selector you could examine the request headers and then choose the operation you want.]