If you’ve been following us here on the .NET Endpoint please be sure to follow the AppFabric Team Blog.

endpoint.tv becomes AppFabric.tv

As part of this change, endpoint.tv will now become AppFabric.tv.  We will continue to bring you the best content about WF and WCF as well as the rest of the AppFabric world. 

If you read to the end the post you will see a bunch of extensions which have been pushed to webapicontrib and make this all MUCH easier (at least I think). If you don’t jump you’ll read below what you need to do if you do it yourself.

It stars with the SetSerializer<T> method which is expose on the XmlMediaTypeFormatter. You can call this method and pass a DataContractSerializer for T. That tells the formatter use this serializer not the default. You need to give it the exact information, for example if you are returning List<Contact> then make T List<Contact> NOT T. If you want to support both, you need to register both.

To allow you to get to the formatter, the MediaTypeFormatterCollection exposes an XmlFormatter property. You might now be thinking, “Oh that’s easy, but how do I get a hold of the formatter collection?”

Good question. It depends on whether you are on the server or on the client.

On the Server

The easiest way to configure things on the server is to annotate your service/resource with a [DataContractFormat] attribute. Once you do then we will automatically use the DataContractSerializer.

If you do not want to annotate your service, the alternative option is to do it in code. If you are using HttpHostConfiguration you can get to the formatters by accessing the OperationHandlerFactory property on the config class. If you are using the fluent API, you’ll want to cast to HttpHostConfiguration in order to access it. For example see the code below

var config = new HttpHostConfiguration();
var formatter = OperationHandlerFactory.XmlFormatter;
formatter.SetSerializer<Contact>(
  new DataContractSerializer(typeof(Contact)));
formatter.SetSerializer<List<Contact>>(
  new DataContractSerializer(typeof(List<Contact>)));

The code above is setting the formatter to use the DCS for Contact and List<Contact> both for reading and writing.

On the client

On the client side how you configure depends on if you are reading or writing. In either case both steps involve calling SetSerializer<T> on the XmlMediaTypeFormatter.

For reading you will create the formatter and pass it to the ReadAs<T> method of the HttpContent which is accessed off of the Content property on HttpResponseMessage.

var formatter = new XmlMediaTypeFormatter();
formatter.SetSerializer<List<Contact>>>(
  new DataContractSerializer(typeof(List<Contact>))));
var contact = response.Content.ReadAs<T>(
  new List<MediaTypeFormatter> { formatter });

If you are writing to the request, you will access the formatters collection on the ObjectContent<T> instance.

var content = new ObjectContent<Contact>();
content.Formatters.SetSerializer<Contact>(
  new DataContractSerializer(typeof(Contact)));
client.Post(content);

New extension methods in webapicontrib to make life easier

Now that we’ve seen how you can do it, we can wrap this up in a bunch of helper extension methods and life gets a whole lot easier. I did that and pushed them to webapicontrib

Check the code below from the new DataContractExample in webapicontrib.

var config = HttpHostConfiguration.Create();
config.UseDataContractSerializer<Contact>();
var host = new HttpConfigurableServiceHost<ContactsResource>(
  config, new Uri("https://localhost:8080/"));
host.Open();
var client = new HttpClient("https://localhost:8080/");
var newContact = new Contact {FirstName = "Brad", LastName = "Abrams"};
var content = new ObjectContent<Contact>(newContact,
  "application/xml").UseDataContractSerializer();
var response = client.Post("contacts", content);
response = client.Get("contacts");
var contacts = response.Content.ReadAsDataContract<Contact[]>();
foreach (var contact in contacts)
{
  Console.WriteLine(string.Format(
    "Contact: FirstName={0}, LastName={1}", 
    contact.FirstName, contact.LastName));
}
Console.ReadLine();

I’ve highlighted the important parts

1. UseDataContractSerializer<T> on the config will set the formatter to serialize T using DCS. In order to make life easier the extension method also registers for List<T> and T[].
2. For reading on the client call the ReadAsDataContract<T> extension method on HttpContent.
3. For writing on the client create an ObjectContent<T> instance and call the UseDataContractSerializer() extension metho

Download the bits in wcfwebapi contrib here

It is recommended that you explicitly specify a name and namespace for the service contract, and an action for each operation to avoid using "https://tempuri.org" and to prevent interface and method names from being exposed in the service’s contract
MSDN Library - Service Contract Versioning

Where is tempuri.org in the WSDL?

If you browse the service WSDL you will see tempuri.org all over the place.  Here is a default WCF service WSDL.

<wsdl:definitions name="Service1" targetNamespace="https://tempuri.org/" xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/" xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="https://schemas.xmlsoap.org/soap/encoding/" xmlns:wsu="https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:soap12="https://schemas.xmlsoap.org/wsdl/soap12/" xmlns:tns="https://tempuri.org/" xmlns:wsa="https://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="https://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="https://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:wsaw="https://www.w3.org/2006/05/addressing/wsdl" xmlns:msc="https://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsa10="https://www.w3.org/2005/08/addressing" xmlns:wsx="https://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsam="https://www.w3.org/2007/05/addressing/metadata">

  <wsdl:types>

    <xsd:schema targetNamespace="https://tempuri.org/Imports">

      <xsd:import schemaLocation="https://localhost:63720/Service1.svc?xsd=xsd0" namespace="https://tempuri.org/"/>

    </xsd:schema>

  </wsdl:types>

  <wsdl:message name="IService1_DoWork_InputMessage">

    <wsdl:part name="parameters" element="tns:DoWork"/>

  </wsdl:message>

  <wsdl:message name="IService1_DoWork_OutputMessage">

    <wsdl:part name="parameters" element="tns:DoWorkResponse"/>

  </wsdl:message>

  <wsdl:portType name="IService1">

    <wsdl:operation name="DoWork">

      <wsdl:input wsaw:Action="https://tempuri.org/IService1/DoWork" message="tns:IService1_DoWork_InputMessage"/>

      <wsdl:output wsaw:Action="https://tempuri.org/IService1/DoWorkResponse" message="tns:IService1_DoWork_OutputMessage"/>

    </wsdl:operation>

  </wsdl:portType>

  <wsdl:binding name="BasicHttpBinding_IService1" type="tns:IService1">

    <soap:binding transport="https://schemas.xmlsoap.org/soap/http"/>

    <wsdl:operation name="DoWork">

      <soap:operation soapAction="https://tempuri.org/IService1/DoWork" style="document"/>

      <wsdl:input>

        <soap:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:service name="Service1">

    <wsdl:port name="BasicHttpBinding_IService1" binding="tns:BasicHttpBinding_IService1">

      <soap:address location="https://localhost:63720/Service1.svc"/>

    </wsdl:port>

  </wsdl:service>

</wsdl:definitions>

Tip: Use a constant to ensure consistency

I like to use a constant to provide a consistent namespace across my services

public class Constants

{

    // Ensures consistency in the namespace declarations across services

    public const string Namespace = "https://contoso.com/services/";

}

How to eliminate tempuri.org from WCF Services WSDL

Step 1: Declare a namespace on your service contract

The namespace can be anything.  People typically use a URI of some form but it does not have to point to an actual web page.  Often people will use a version identifier in the namsepace but there are no rules about what you should do.

// Eliminate tempuri.org from the contract

// If you don't want to us a constant, put the URI here

// [ServiceContract(Namespace = "https://contoso.com/services")]

[ServiceContract(Namespace = Constants.Namespace)]

public interface IService1

{

    [OperationContract]

    void DoWork();

}

Step 2: Declare a namespace on your service

The service namespace is added with a ServiceBehavior attribute.  Using the constant ensures that the namespace is the same for the contract and the service.

// If you don't want to us a constant, put the URI here

// [ServiceBehavior(Namespace = "https://contoso.com/services")]

[ServiceBehavior(Namespace = Constants.Namespace)]

public class Service1 : IService1

{

    public void DoWork()

    {

    }

}

Step 3: Set the binding namespace

<system.serviceModel>

    <services>

      <service name="EliminateTempUri.Service1">

        <!-- Use a bindingNamespace to eliminate tempuri.org -->

        <endpoint address=""

                  binding ="basicHttpBinding" 

                  bindingNamespace="https://contoso.com/services"

                  contract="EliminateTempUri.IService1"

        />

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name="">

          <serviceMetadata httpGetEnabled="true" />

          <serviceDebug includeExceptionDetailInFaults="false" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

  </system.serviceModel>

How to eliminate tempuri.org from Workflow Services WSDL

For workflow services the process is slightly different.  Workflow services do not have a contract (it is inferred from the activities) so here is the process.

Step 1: Declare a namespace on each receive activity

I wish it were possible to use a constant here but sadly it is not.  For each receive activity you must declare the namespace and contract name using a special syntax of {namespace}IContractName.  In this example I’ve set the ServiceContractName property to {https://contoso.com/services}IService

Step 2: Declare a namespace for the Workflow Service

1. Open the Workflow Service and click in the designer outside of an activity.  This will allow you to set the properties of the service itself. 
2. Set the Name property to use the same namespace as you see below.

Step 3: Set the binding namespace

Many people do not declare a <service> tag for their Workflow Services but if you want to eliminate tempuri.org you will need to declare it.

For a Workflow Service the A,B,Cs of WCF configuration are a little different.

• Service Name – use the ConfigurationName property from the WorkflowService
• A – Address – should be blank when hosted in IIS / AppFabric
• B – Binding – use the binding of your choice.  Typically basicHttpBinding
• C – Contract – use the interface name from the ServiceContractName property (without the namespace)

<!-- For Workflow Services name is the ConfigurationName property -->

<service name="Service2">

  <!-- contract must match the receive activity -->

  <!-- Use a bindingNamespace to eliminate tempuri.org -->

  <endpoint address=""

            binding ="basicHttpBinding"

            bindingNamespace="https://contoso.com/services"

            contract="IService"

  />

</service>

Test It Out

1. Right click on your WCF or Workflow Service in Visual Studio and select View In Browser.
2. Click on the link to view the WSDL
3. Search in the browser for tempuri.org – there should be no matches

Happy Coding!

Ron Jacobs
https://blogs.msdn.com/rjacobs
Twitter: @ronljacobs https://twitter.com/ronljacobs

We’re now entering the realm of the less used extensibility points for the WCF runtime. Operation selectors could well be left as an internal implementation detail for WCF, but for some reason the designers decided to make them public (I think the guideline back then was if anyone can come up with a scenario where a user would use it, then WCF would expose a hook for that). The server selector (IDispatchOperationSelector) is actually interesting to have as a public hook, as the whole UriTemplate model for REST services was built on top of it – basically, the selector knows about the HTTP method and URI templates for each service operation, and based on those properties of incoming messages it can call the appropriate operation. For “normal” (i.e., SOAP) endpoints, the operation selector implementation (which happens to be internal) is based on the addressing of the binding – in most of the cases it simply matches the Action header of the message with a map of action to the operation names.

The client operation selector (IClientOperationSelector) is another story. The client selector receives the method invoked by the client (the System.Reflection.MethodBase object) and it must return an operation name which will be used by the WCF runtime to retrieve the actual client operation from the client runtime. I’ve tried for a while to think of any scenario where one would actually want to call one method in the proxy and have another operation be executed (besides some practical joke scenario where one would swap Add for Subtract in a calculator), but I just can’t think of any. Even searching on Bing or Google doesn’t show any real scenarios where a client selector is used. But well, WCF is extensible, so let’s let people choose their client operations as well .

Public implementations in WCF

• WebHttpDispatchOperationSelector (server): The dispatch implementation where the UriTemplate magic happens for WCF REST endpoints.

There are no public implementations for IClientOperationSelector, only an internal one which simply returns the operation name of the method being called.

Interface declaration

The dispatch operation selector is quite simple – on SelectOperation you get the message, you return the operation name. In most cases the operation can be selected based on information on the message header (e.g., the Action header for SOAP endpoints) or the message properties (e.g., the HTTP request property attached to the message). There are scenarios, however, where the routing to the operation needs to be done based on the message contents, so the message is passed by reference – if it needs to be consumed by the operation selector, it can recreated it to hand it back to the WCF pipeline.

On the client side the AreParametersRequiredForSelection is used to determine whether the response to SelectOperation can be cached or not – if the parameters are not required, the WCF runtime will only call SelectOperation once per method in the proxy, otherwise every time a proxy call is made the selector will be invoked again.

How to add operation selectors

At the server side: the operation selector is a property of the DispatchRuntime object. It’s typically accessed via the endpoint dispatcher in a call to IEndpointBehavior.ApplyDispatchBehavior.

At the client side: the operation selector is a property of the ClientRuntime object, and is typically accessed via the implementation of IEndpointBehavior.ApplyClientBehavior.

Real world scenario: Support for X-HTTP-Method-Override in REST endpoints

This issue came from the forum. REST services we use HTTP verbs (methods) to determine the action to be applied to the resource. For example, a GET request to /Contacts/1 would return the contact with id 1, while DELETE /Contacts/1 would remove that same contact from the repository. This is a great – and simple – model, but there are some browsers, proxies, firewalls or even some web service platforms which don’t support the full set of verbs (rejecting anything other than GET and POST). In order to overcome this problem, some platforms (such as ASP.NET MVC and Google Data) started supporting a new HTTP header or field, called X-HTTP-Method-Override, which contain the actual method which should be used by the service to access the resource. The WCF REST API doesn’t support this override natively, but that doesn’t preclude us from using an extensibility point to enable it.

Implementing the support for X-HTTP-Method-Override is nothing but a matter of replacing the operation selector (based on methods and URI templates) used by REST endpoints with our own, which is aware of this new header. When the IDispatchOperationSelector.SelectOperation method is called, we can check if the incoming request contained the override header, and if so, we can update the incoming message properties to let the original selector chose the appropriate operation.

For this example I’ll reuse the contact manager service from the message inspectors post – it contains the different operations which differ based on the HTTP verb of the incoming request, so it’s perfect for this issue. And before I start, the usual disclaimer – this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would. Also, the contact manager is all stored in memory, a “real” one would have a backing database or something more “persistent”.

One small parenthesis: the link below for the code in this post contains the version shown here in C# and also a version in VB.NET which does the same thing; if you’re a VB developer, you can check the MSDN code samples out.

The contracts and service implementation are exactly the same as the one from before (I removed the version for Text, as it didn’t add any value to this topic):

Now for the behavior used to set up the operation selector. The behavior wraps the original operation selector from the endpoint, so it needs to be added after the WebHttpBehavior (which will add the first selector to the runtime) – see the discussion about wrapping internal objects at the post about formatters).

And the selector itself. As I mentioned before, The first thing the selector will do is to try to fetch the HttpRequestMessageProperty from the message properties – if the message was received using HTTP, it will contain information about the HTTP verb and headers in the request. It will then try to find the X-HTTP-Method-Override header, and if it’s present, it will update the message property with the method override. For completeness sake, this selector also adds a new property to the message with the original HTTP verb from the request (if the service needs this information somehow). Finally, the selector delegates the selection to the original selector, which will then use that information to route the incoming request to the appropriate method.

Finally, the test code to wrap it all together. The code is very similar to the one for the message inspectors post, with a few differences: the new behavior (HttpOverrideBehavior) is added after the REST ((WebHttp) behavior, and after sending requests with the “real” HTTP verb it will send some additional requests using POST, but using the HTTP override method to route it to different operations.

Coming up

Operation invokers, for both synchronous and asynchronous operations.

[Code in this post]

[Back to the index]

Carlos Figueira
https://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira https://twitter.com/carlos_figuei

If the custom activity can only accept a single type, this can be implemented quite simply by setting the WorkflowItemPresenter.AllowedItemType or WorkflowItemsPresenter.AllowedItemType property. In this example, I allow only a WriteLine activity to be dropped:

<sap:WorkflowItemsPresenter HintText="Drop Activities Here" 

Margin="5" MinHeight="100"

Items="{Binding Path=ModelItem.Activities}"

AllowedItemType="{x:Type TypeName=sa:WriteLine}">

Note that to use the above code, you'll need to add a namespace declaration to your designer:

xmlns:sa="clr-namespace:System.Activities.Statements;assembly=System.Activities"

If you need to restrict to a set of allowed activity types, rather than a single type, this can be done by adding a validation error to the validation errors collection during the CacheMetadata phase. Note that this will create a runtime error (though technically the user will experience it in the design phase), which will cause an error icon to be displayed, rather than preventing the activity to be dropped in the first place. In this example, I allow only a WriteLine or Assign activity to be dropped:

protected override void CacheMetadata(NativeActivityMetadata metadata)

{

    base.CacheMetadata(metadata);

    foreach (Activity a in Activities)

    {

        if ((a.GetType() != typeof(System.Activities.Statements.WriteLine)) && (a.GetType() != typeof(System.Activities.Statements.Assign)))

        {

            metadata.AddValidationError("Child activity is not of type WriteLine or Assign");

        }

    }

}

How To Get Microsoft.Activities or Microsoft.Activities.UnitTesting with NuGet

Step 0: Install NuGet

If you don’t already have NuGet, install it now (you will have to restart Visual Studio if it is already running)

Step 1: Create a project

Your project can be any kind of project.  NuGet will automatically add references that are required.  For this example, I’m going to create a Class Library project.

Step 2a: Install the Microsoft.Activities Package (Using the Package Manager Console)

1. Select View / Other Windows / Package Manager Console
2. Type Install-Package Microsoft.Activities

Step 2b: Install the Microsoft.Activities Package (Using Library Package Reference)

If you would rather have a UI to browse packages,

1. Right click on the references folder
2. Select Add Library Package Reference…
3. In the search box type Microsoft.Activities
4. Click the Install button to add a library package reference

What Happens to my Project / Visual Studio when I install this?

Your Project

• Add reference to System.Activities
• Add reference to ($SolutionDir)packages\Microsoft.Activities.1.8.1.506\lib\Net40\Microsoft.Activities.dll) with copy local = true so the assembly will be in your bin directory when you build.

Visual Studio

• Added toolbox icons for the activities in Microsoft.Activities to your toolbox pointing to the last installation location for Microsoft.Activities.dll
• Add a new Workflow to your project to see the two groups (Dictionary and Microsoft.Activities)

What if I want to use .NET 4 Platform Update 1 so I can create a State Machine workflow?

The Microsoft.Activities package includes a version built for .NET 4 Platform Update 1.  As you see in the folder structure there are Net40 and Net401 folders.  NuGet automatically detects which version of the .NET Framework your project is targeting and will add a reference to the appropriate version

What if I change my target framework to .NET 4 Platform Update 1 after installing the Microsoft.Activities Package?

If you change your target framework after installing your project will continue to reference the .NET 4 version of Microsoft.Activities.  You can update the reference manually by browsing the packages folder and adding a reference or you can uninstall / reinstall the package.

What if I create a new project and drag an activity from Microsoft.Activities onto a workflow without first installing Microsoft.Activities?

Toolbox activities remain in the toolbox across projects.  When you create a new project and open the workflow designer you will see the Microsoft.Activities and Dictionary tabs.  When you drag one of these activities onto the workflow designer, Visual Studio will add a reference to the assembly that the toolbox icon is associated with.

If you installed the Microsoft.Activities package to a project named ClassLibary1 and then created another project named WorkflowConsoleApplication1 as soon as you start dragging an activity onto a workflow from WorkflowConsoleApplication1 you will see an assembly reference added to the Microsoft.Activities package installed under the ClassLibrary1 solution.

What if I delete the solution where Microsoft.Activities was installed?

If you try to delete it while Visual Studio is open you will get an error because Visual Studio has the assembly loaded.  If you close Visual Studio and delete the solution, the next time you run Visual Studio and open the Workflow Designer you will see the icons are still in the toolbox.  However when you try to drop an activity from the missing assembly, Visual Studio won’t allow it because it is unable to locate the assembly to add a reference.

How do I fix the toolbox icons if they refer to an assembly that no longer exists?

Each time install the Microsoft.Activities package, if the toolbox icons exist, they are removed and replaced with a toolbox icon that refers to the Microsoft.Activities assembly that is installed with the package in current project.

What if I want to store the Microsoft.Activities assembly in some other location?  How do I keep the NuGet package from updating my toolbox icons?

If you change the name of the Tab group from Microsoft.Activities to something else, the package installation script won’t find the activities and won’t update them.  However it will add a new activity group.

How do I uninstall the Microsoft.Activities package?

1. Open the Package Manager console
2. Type Uninstall-Package Microsoft.Activities
3. In the toolbox, right click on the Microsoft.Activities tab group and select Delete Tab
4. Repeat for the Dictionary Group

Sometimes you will get an error when trying to uninstall because Visual Studio has one of the assemblies open.  In this case you will have to manually delete the package. 

PM> Uninstall-Package Microsoft.Activities
Successfully removed 'Microsoft.Activities 1.8.1.506' from WorkflowConsoleApplication10. 
Access to the path 'd:\ngt\WorkflowConsoleApplication10\packages\Microsoft.Activities.1.8.1.506\lib\Net40\Microsoft.Activities.dll' is denied. 
Access to the path 'd:\ngt\WorkflowConsoleApplication10\packages\Microsoft.Activities.1.8.1.506\tools\Microsoft.Activities.NuGet.dll' is denied. 
The directory is not empty.

What if I install Microsoft.Activities.UnitTesting and I don’t have Microsoft.Activities?

Not to worry.  Microsoft.Activities.UnitTesting has a dependency on the Microsoft.Activities package so NuGet will automatically deploy it as well.

PM> Install-Package Microsoft.Activities.UnitTesting 
'Microsoft.Activities (≥ 1.8.1)' not installed. Attempting to retrieve dependency from source... 
Done. 
Successfully installed 'Microsoft.Activities 1.8.1.509'. 
Successfully installed 'Microsoft.Activities.UnitTesting 1.8.1.509'. 
Successfully added 'Microsoft.Activities 1.8.1.509' to WorkflowConsoleApplication14. 
Successfully added 'Microsoft.Activities.UnitTesting 1.8.1.509' to WorkflowConsoleApplication14.

What if I install Microsoft.Activities.UnitTesting and then try to Uninstall Microsoft.Activities

PM> Uninstall-Package Microsoft.Activities
Uninstall-Package : Unable to uninstall 'Microsoft.Activities 1.8.1.509' because 'Microsoft.Activities.UnitTesting 1.8.1.509' depends on it.
At line:1 char:18
+ Uninstall-Package <<<<  Microsoft.Activities
    + CategoryInfo          : NotSpecified: (:) [Uninstall-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.UninstallPackageCommand

What do you think?

I’m really happy with NuGet so far.  I just updated the uninstall scripts so that they will remove the toolbox tabs (Microsoft.Activities, Dictionary and Unit Testing) created by the install scripts.  Of all the things these packages do the interaction with the toolbox is the one area that I’m not sure about.  Hopefully what I’ve done here will work for you.  If not, tell me how we can do it better.

Ron Jacobs
https://blogs.msdn.com/rjacobs
Twitter: @ronljacobs https://twitter.com/ronljacobs

The best part is that there is an easy way to reproduce the problem. To do this, create a new WCF service application with the .NET 4 framework:

Then trim the default service contract down to only the GetData method:

using System.ServiceModel;

[ServiceContract]
public interface IService1
{
    [OperationContract]
    string GetData(int value);
}

And fill out the GetData method in the service code:

using System;
using System.Threading;

public class Service1 : IService1
{
    public string GetData(int value)
    {
        Thread.Sleep(TimeSpan.FromSeconds(2));
        return string.Format("You entered: {0}", value);
    }
}

The two second sleep is the most important part of this repro. We'll explore why after we create the client and observe the effects. But first, make sure to set the throttle in the web.config:

<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
          <serviceThrottling maxConcurrentCalls="100"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
</configuration>

The Visual Studio web server would probably suffice, but I changed my web project to use IIS instead. This makes it more of a realistic situation. To do this go to the project properties, select the Web tab, and switch to IIS.

Be sure to hit the Create Virtual Directory button. In my case, I have SharePoint installed and it's taking up port 80, so I put the default web server on port 8080. Once this is done, build all and browse to the service to make sure it's working correctly.

To create the test client, add a new command prompt executable to the solution and add a service reference to Service1. Change the client code to the following:

using System;
using System.Threading;
using ServiceReference1;

class Program
{
    private const int numThreads = 100;
    private static CountdownEvent countdown;
    private static ManualResetEvent mre = new ManualResetEvent(false);

    static void Main(string[] args)
    {
        string s = null;
        Console.WriteLine("Press enter to start test.");
        while ((s = Console.ReadLine()) == string.Empty)
        {
            RunTest();
            Console.WriteLine("Allow a few seconds for threads to die.");
            Console.WriteLine("Press enter to run again.");
            Console.WriteLine();
        }
    }

    static void RunTest()
    {
        mre.Reset();
        Console.WriteLine("Starting {0} threads.", numThreads);
        countdown = new CountdownEvent(numThreads);
        for (int i = 0; i < numThreads; i++)
        {
            Thread t = new Thread(ThreadProc);
            t.Name = "Thread_" + i;
            t.Start();
        }
        // Wait for all threads to signal.
        countdown.Wait();
        Console.Write("Press enter to release threads.");
        Console.ReadLine();
        Console.WriteLine("Releasing threads.");
        DateTime startTime = DateTime.Now;
        countdown = new CountdownEvent(numThreads);
        // Release all the threads.
        mre.Set();
        // Wait for all the threads to finish.
        countdown.Wait();
        TimeSpan ts = DateTime.Now - startTime;
        Console.WriteLine("Total time to run threads: {0}.{1:0}s.",
            ts.Seconds, ts.Milliseconds / 100);
    }

    private static void ThreadProc()
    {
        Service1Client client = new Service1Client();
        client.Open();
        // Signal that this thread is ready.
        countdown.Signal();
        // Wait for all the other threads before making service call.
        mre.WaitOne();
        client.GetData(1337);
        // Signal that this thread is finished.
        countdown.Signal();
        client.Close();
    }
}

The code above uses a combination of a ManualResetEvent and a CountdownEvent to coordinate the calls to all happen at the same time. It then waits for all the calls to finish and determines how long it took. When I run this on a dual core machine, I get the following:

Press enter to start test.

Starting 100 threads.
Releasing threads.
Total time to run threads: 14.0s.
Allow a few seconds for threads to die.
Press enter to run again.

If each individual request only sleeps for 2 seconds, why would it take 100 simultaneous requests 14 seconds to complete? It should only take 2 seconds if they're all executing at the same time. To understand what's happening, let's look at the thread count in perfmon. First, open Administrative Tools -> Performance Monitor. In the tree view on the left, pick Monitoring Tools -> Performance Monitor. It should have the % Processor counter in there by default. We don't need that counter so select it in the bottom and press the delete key. Now click the add button to add a new counter:

In the Add Counters dialog, expand the Process node:

Under this locate the Thread Count counter and then find the w3wp instance and press the Add >> button.

If you don't see the w3wp instance, it is most likely because it wasn't running when you opened the Add Counters dialog. To correct this, close the dialog, ping the Service1.svc service, and then click the Add button again in perfmon.

Now you can run the test and you should see results similar to the following:

In this test, I had pinged the service to get the metadata to warm everything up. When the test ran, you can see it took several seconds to add another 21 threads. The reason these threads are added is because when WCF runs your service code, it uses a thread from the IO thread pool. Your service code is then expected to do some work that is either quick or CPU intensive or takes up a database connection. But in the case of the test, the Thread.Sleep means that no work is being done and the thread is being held. A real world scenario where this pattern could occur is if you have a WCF middle tier that has to make calls into lower layers and then return the results.

For the most part, server load is assumed to change slowly. This means you would have a fairly constant load and the thread pool manager would pick the appropriate size for the thread pool to keep the CPU load high but without too much context switching. However, in the case of a sudden burst of requests with long-running, non-CPU-intensive work like this, the thread pool adapts too slowly. You can see in the graph above that the number of threads drops back down to 30 after some time. The thread pool has recognized that a thread has not been used for 15 seconds and therefore kills it because it is not needed.

To understand the thread pool a bit more, you can profile this and see what's happening. To get a profile, go to the Performance Explorer, usually pinned on the left side in Visual Studio, and click the button to create a new performance session:

Right click on the new performance session and select properties. In the properties window change the profiling type to Concurrency and uncheck the "Collect resource contention data" option.

Before we start profiling, let's first go to the Tools->Options menu in Visual Studio. Under Debugging, enable the Microsoft public symbol server.

Also, turn off the Just My Code option under Performance Tools:

The next step is to make the test client the startup project. You may need to ping the Service1.svc service again to make sure the w3wp process is running. Now, attach to the w3wp process with the profiler. There is an attach button at the top of the performance explorer window or you can right click on the performance session and choose attach.

Give the profiler a few seconds to warmup and then hit ctrl+F5 to execute the test client. After the test client finishes a single run pause and detach the profiler from the w3wp process. You can also hit the "Stop profiling" option but it will kill the process.

After you've finished profiling, it will take some time to process the data. Once it's up, switch to the thread view. In the figure below, I've rearranged the threads to make it easier to see the relationships:

Blue represents sleep time. This matches what we expect to see, which is a lot of new threads all sleeping for 2 seconds. At the top of the sleeping threads is the gate thread. It checks every 500ms to see if the number of threads in the thread pool is appropriate to handle the outstanding work. If not, it creates a new thread. You can see in the beginning that it creates 2 threads and then 1 thread at a time in 500ms increments. This is why it takes 14 seconds to process all 100 requests. So why are there two threads that look like they're created at the same time? If you look more closely, that's actually not the case. Let's zoom in on that part:

Here again the highlighted thread is the gate thread. Before it finishes its 500ms sleep, a new thread is created to handle one of the WCF service calls which sleeps for 2 seconds. Then when the gate thread does its check, it realizes that there is a lot of work currently backed up and creates another new thread. On a dual core machine like this, the default minimum IO thread pool setting is 2: 1 per core. One of those threads is always taken up by WCF and functions as the timer thread. You can see that there are other threads created up top. This is most likely ASP.Net creating some worker threads to handle the incoming requests. You can see that they don't sleep because they're passing off work to WCF and getting ready to handle the next batch of work.

The most obvious thing to do then would be to increase the minimum number of IO threads. You can do this in two ways: use ThreadPool.SetMinThreads or use the <processModel> tag in the machine.config. Here is how to do the latter:

<system.web>
  <!--<processModel autoConfig="true"/>-->
  <processModel 
    autoConfig="false" 
    minIoThreads="101" 
    minWorkerThreads="2" 
    maxIoThreads="200" 
    maxWorkerThreads="40" 
    />

Be sure to turn off the autoConfig setting or the other options will be ignored. If we run this test again, we get a much better result. Compare the previous snapshot of permon with this one:

And the resulting output of the run is:

Starting 100 threads.
Press enter to release threads.
Releasing threads.
Total time to run threads: 2.2s.
Allow a few seconds for threads to die.
Press enter to run again.

This is an excellent result. It is exactly what you would want to happen if a sudden burst of work comes in. But customers were saying that this wasn't happening for them. David Lamb told me that if you run this for a long time, like 2 hours, it would eventually stop quickly adding threads and behave as if the min IO threads was not set.

One of the things we can do is modify the test code to give enough time for the threads to have their 15 second timeout and just take out all the Console.ReadLine calls:

using System;
using System.Threading;
using ServiceReference1;

class Program
{
    private const int numThreads = 100;
    private static CountdownEvent countdown;
    private static ManualResetEvent mre = new ManualResetEvent(false);

    static void Main(string[] args)
    {
        while (true)
        {
            RunTest();
            Thread.Sleep(TimeSpan.FromSeconds(25));
            Console.WriteLine();
        }
    }

    static void RunTest()
    {
        mre.Reset();
        Console.WriteLine("Starting {0} threads.", numThreads);
        countdown = new CountdownEvent(numThreads);
        for (int i = 0; i < numThreads; i++)
        {
            Thread t = new Thread(ThreadProc);
            t.Name = "Thread_" + i;
            t.Start();
        }
        // Wait for all threads to signal.
        countdown.Wait();
        Console.WriteLine("Releasing threads.");
        DateTime startTime = DateTime.Now;
        countdown = new CountdownEvent(numThreads);
        // Release all the threads.
        mre.Set();
        // Wait for all the threads to finish.
        countdown.Wait();
        TimeSpan ts = DateTime.Now - startTime;
        Console.WriteLine("Total time to run threads: {0}.{1:0}s.",
            ts.Seconds, ts.Milliseconds / 100);
    }

    private static void ThreadProc()
    {
        Service1Client client = new Service1Client();
        client.Open();
        // Signal that this thread is ready.
        countdown.Signal();
        // Wait for all the other threads before making service call.
        mre.WaitOne();
        client.GetData(1337);
        // Signal that this thread is finished.
        countdown.Signal();
        client.Close();
    }
}

Then just let it run for a couple hours and see what happens. Luckily, it doesn't take 2 hours and we can reproduce the weird behavior pretty quickly. Here is a perfmon graph showing several runs:

You can see that the first two bursts had quick scale up with the thread count. After that, it went back to being slow. After working with the CLR team, they determined that there is a bug in the IO thread pool. This bug causes the internal count of IO threads to get out-of-sync with reality. Some of you may be asking the question as to what min really means in terms of the thread pool. Because if you specify you want a minimum of 100 threads, why wouldn't there just always be 100 threads? For the purposes of the thread pool, the min is supposed to be the threshold that the pool can scale up to before it starts to be metered. The default working set cost for one thread is a half MB. So that is one reason to keep the thread count down.

Some customers have found that Juval Lowy's thread pool doesn't have the same problem and handles these bursts of work much better. Here is a link to his article: https://msdn.microsoft.com/en-us/magazine/cc163321.aspx

Notice that Juval has created a custom thread pool and relies on the SynchronizationContext to switch from the IO thread that WCF uses to the custom thread pool. Using a custom thread pool in your production environment is not advisable. Most developers do not have the resources to properly test a custom thread pool for their applications. Thankfully, there is an alternative and that is the recommendation made in the KB article. The alternative is to use the worker thread pool. Juval has some code for a custom attribute that you can put on your service to set the SynchronizationContext to use his custom thread pool and we can just modify that to put the work into the worker thread pool. The code for this change is all in the KB article, but I'll reiterate here along with with the changes to the service itself.

using System;
using System.Threading;
using System.ServiceModel.Description;
using System.ServiceModel.Channels;
using System.ServiceModel.Dispatcher;

[WorkerThreadPoolBehavior]
public class Service1 : IService1
{
    public string GetData(int value)
    {
        Thread.Sleep(TimeSpan.FromSeconds(2));
        return string.Format("You entered: {0}", value);
    }
}

public class WorkerThreadPoolSynchronizer : SynchronizationContext
{
    public override void Post(SendOrPostCallback d, object state)
    {
        // WCF almost always uses Post
        ThreadPool.QueueUserWorkItem(new WaitCallback(d), state);
    }

    public override void Send(SendOrPostCallback d, object state)
    {
        // Only the peer channel in WCF uses Send
        d(state);
    }
}

[AttributeUsage(AttributeTargets.Class)]
public class WorkerThreadPoolBehaviorAttribute : Attribute, IContractBehavior
{
    private static WorkerThreadPoolSynchronizer synchronizer = new WorkerThreadPoolSynchronizer();

    void IContractBehavior.AddBindingParameters(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        BindingParameterCollection bindingParameters)
    {
    }

    void IContractBehavior.ApplyClientBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        ClientRuntime clientRuntime)
    {
    }

    void IContractBehavior.ApplyDispatchBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.SynchronizationContext = synchronizer;
    }

    void IContractBehavior.Validate(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint)
    {
    }
}

The areas highlighted above show the most important bits for this change. There really isn't that much code to this. With this change essentially what is happening is that WCF recognizes that when it's time to execute the service code, there is an ambient SynchronizationContext. That context then pushes the work into the worker thread pool with QueueUserWorkItem. The only other change to make is to the <processModel> node in the machine.config to configure the worker thread pool for a higher min and max.

<system.web>
  <!--<processModel autoConfig="true"/>-->
  <processModel 
    autoConfig="false" 
    minWorkerThreads="100" 
    maxWorkerThreads="200" 
    />

Running the test again, you will see a much better result:

All of the test runs finished in under 2.5 seconds.

We cannot make a recommendation on this alone though. There are other questions like how does this affect performance and does it continue to work this way for hours, days, weeks, etc. Our testing showed that for at least 72 hours, this worked without a problem. The performance runs showed some caveats though. These are also pointed out in the KB article. There is a cost for switching from one thread to another. This would be the same with the worker thread pool or a custom thread pool. That overhead can be negligible for large amounts of work. In the case that applies here with 2 seconds of blocking work, the context switch is definitely not a factor. But if you've got small messages and fast work, then it's likely to hurt your performance.

The test project is included with this post.

Originally posted on Dustin Metzgar's blog

IOThreadPoolBug.zip

Message formatters are the component which do the translation between CLR operations and the WCF Message object – their role is to convert all the operation parameters and return values (possibly via serialization) into a Message on output, and deconstruct the message into parameter and return values on input. Anytime a new format is to be used (be it a new serialization format for currently supported CLR types, or supporting a new CLR type altogether), a message formatter is the interface you’d implement to enable this scenario. For example, even though the type System.IO.Stream is not serializable (it’s even abstract), WCF allows it to be used as the input or return values for methods (for example, in the WCF REST Raw programming model) and a formatter deals with converting it into messages. Like the message inspectors, there are two versions, one for the server side (IDispatchMessageFormatter), and one for the client side (IClientMessageFormatter).

Among the extensibility points listed in this series, the message formatters are the first kind to be required in the WCF pipeline – a service does not need to have any service / endpoint / contract / operation behavior, nor any message / parameter inspector. If the user doesn’t add any of those, the client / service will just work (some behaviors are automatically added to the operations when one adds an endpoint, but that’s an implementation detail for WCF – they aren’t strictly necessary). Formatters, on the other hand, are required (to bridge the gap between the message world and the operations using CLR types). If we don’t add any behaviors to the service / endpoint / contract / operation that sets a formatter, WCF will add one formatter to the operation (usually via the DataContractSerializerOperationBehavior, which is added by default in all operation contracts).

Public implementations in WCF

None. As with most of the runtime extensibility points, there are no public implementations of either the dispatch or the client message formatter. There are a lot of internal implementations, though, such as a formatter which converts operation parameters into a message (both using the DataContractSerializer and the XmlSerializer), formatters which map parameters to the HTTP URI (used in REST operations with UriTemplate), among others.

Interface declaration

The formatter interfaces each have two methods, one to convert between input outgoing CLR objects into the Message object (serialize), and one to take the incoming message object apart and break it down into incoming CLR objects (deserialize).

At the server side, after the the message was decoded, passed through the channel stack and other extensibility points and is about to be dispatched to the service operation, the method DeserializeRequest is called to deserialize the message object into an array of parameters to be passed to the operation. The object argument “parameters” will have been allocated, so the implementation of the formatter only needs to read the message and set the operation parameters in their correct order in the array passed to it. After the operation is invoked (and any parameter inspector has a chance to change the operation outputs), SerializeReply is called, to take the operation return, plus the final value of any out/ref parameters which the operation may have, and package them into a Message object to be sent down the WCF channel stack.

At the client side the mirror happens: when the operation is called (and after the parameter inspector has a chance to change the inputs), SerializeRequest is called to package all the input parameters into the outgoing message object. After the message is sent to the server and the response is decoded by the client’s encoder, DeserializeReply is called to open the message object and populate the return value and any possible out/ref parameters.

One small parenthesis about out/ref parameters: all parameters in WCF calls are passed by value – a copy of the value is sent across the wire. If an operation declares a parameter with a ref modifier (ByRef in Visual Basic), the service will receive a copy (i.e., by value) of that parameter, and then return another copy of the value of the parameter at the end of the method. This second copy will be deserialized at the client into a new instance of that type. So even if you pass an instance of your type by reference to a WCF service, and the service doesn’t change it at all, the value at the end of the call at the client side the reference will point to a different object.

Going back to the formatters, the list of “input” parameters (those in the *Request) operations are either the input (ByVal) parameters or reference (ByRef without <Out>). The list of “output” parameters are ones marked with ref (ByRef) and out (<Out> ByRef). In the operation InOutRef above, the parameters x and y are considered to be input parameters, so the parameters array in the *Request operations will have two objects). The parameters y, z and w are considered to be output parameters, so the parameters array in the *Reply operations will have three elements.

How to add message formatters

At the server side: the formatter is a property of the operation runtime, so at the server side it’s available at the DispatchOperation object. This object is typically accessed via an operation behavior, or by traversing the operation list from an endpoint behavior. both in the ApplyDispatchBehavior method. Another way is if you’re creating a REST endpoints (i.e., one with a behavior which inherits from WebHttpBehavior). WebHttpBehavior exposes two protected methods, GetRequestDispatchFormatter and GetReplyDispatchFormatter, which can be overridden to to return the formatter to be used by the operation.

At the client side: Similarly, the operation formatter at the client side is available at the ClientOperation object, typically accessed via an operation or endpoint behavior. And for behaviors inheriting from WebHttpBehavior, there are two protected methods, GetRequestClientFormatter and GetReplyClientFormatter, which can be used to return the operation formatter as well.

A quick note about wrapping the default WCF formatter. As I mentioned before, the default formatter is usually added by the DataContractSerializerOperationBehavior when it’s executed. If we want to use that default formatter, and wrap it in our own formatter, we need to make sure that the DataContractSerializerOperationBehavior is a position in the operation behavior list which is executed before our own operation behavior is. Take this seemingly problem-free example:

The call to CreateChannel in the channel factory will fail – the constructor of MyClientFormatter will throw. That’s because the order of the operation behaviors (printed in the code) is the following:

System.ServiceModel.Dispatcher.OperationInvokerBehavior
MyOperationBehaviorAttribute
System.ServiceModel.OperationBehaviorAttribute
System.ServiceModel.Description.DataContractSerializerOperationBehavior
System.ServiceModel.Description.DataContractSerializerOperationGenerator

I have no idea why attribute-based operation behaviors are added in this position, but the fact is that this doesn’t work. So for this scenario we cannot use attribute-based behaviors, we need to add it “manually”, as shown below.

After doing that, the code runs and works fine.

Real world scenario: supporting different data and serialization formats

The first version of WCF (.NET Framework 3.0) supported essentially SOAP endpoints – an XML payload following some rules defined in the SOAP specification (you actually could do POX/REST, but it was awfully hard). On the next version (.NET Framework 3.5), the REST programming model was added and that started supporting a whole new set of formats, mostly notably POX (plain-old XML, no SOAP involved), JSON (based on the DataContractJsonSerializer) and a special “raw” mode, where one could declare a single Stream parameter in an operation for receiving arbitrary data, or returning a Stream value for returning arbitrary data. The raw mode can be used to support essentially all data and serialization formats, but that comes at a price that the operation itself has to deal with serializing / deserializing the parameters. Also, there are scenarios (from the forums) where the user needs to expose the same operation in non-REST endpoints (or even non-HTTP, as in the scenario described in the forum post), where the Stream trick won’t work. This example will expand on the answer to the forum question and provide formatters which will use a custom serializer (in this case, the JSON.NET one, available from codeplex at https://json.codeplex.com).

And the usual disclaimer: this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would, and it isn’t fully integrated with the WCF REST pipeline (i.e., it doesn’t support UriTemplates, it doesn’t integrate with the REST help page, doesn’t support out/ref parameters,, etc.).

First, some data contracts to set up the scenario. The service will process people and their pets. The data contracts are decorated both with WCF serialization attributes (DataContract, DataMember), and with the JSON.NET serialization attributes (JsonObejct, JsonProperty, JsonConverter) so that it can be mapped according to both formats.

Next the interface definition, and the service implementation. It’s not very interesting, but I added operations using both GET and POST methods, and operations with single and multiple parameters (the goal of this sample is to demonstrate the formatter, not a specific service, so I think I can slack off on the service example a little ).

Now the behavior which will set everything together. Since this is a REST endpoint, instead of writing a new endpoint, I’ll simply inherit from WebHttpBehavior, and override the protected methods to return the client and server formatters. Notice that in some cases when there are no parameters or for GET requests (where the parameters are in the query string, not in the request body), so in those cases I’ll simply reuse the default formatter from the base class. Another logic which is implemented at the behavior is validation – we know what our formatter doesn’t support, so we’ll simply throw while the service (or the client channel) is being opened, giving the user a clear message explaining why the behavior failed the validation (some of the validation code is not in the snippet below, but it can be found in the source code for this post).

On to the formatters. I’ll start with the dispatch formatter. As the new formatter was only added for POST operations with at least one parameter, we can safely assume that the messages will not be empty, and the request will be stored in the message body. But the message body is always represented in XML, so in order to support a custom format, we need to either define a mapping between that format and XML (which is what was done internally for supporting JSON in 3.5) – and implement XML readers and writers to support this mapping – or reuse one of the existing formats for which we already have a mapping for. And as in the raw programming model, the raw format (described in the post about message inspectors) is a great candidate for it – we can get the raw bytes from the request (and write raw bytes in the response) and parse them using our custom format. We must ensure, however, that the incoming message actually was read with the raw encoder (by default messages with JSON content type are read with the JSON encoder, we need a custom content type mapper to ensure that they are read as raw messages).

When the formatter is serializing the reply of the message , it will create a new message using a “raw” body writer, which is a simple implementation of the BodyWriter class. It will then set the body format property to ensure that the raw encoder will be used when converting that message into bytes on the wire.

The client formatter is similar to the service one. On reply, since it doesn’t support multiple return values (no out/ref support implemented), it simply gets the bytes from the message and feeds them to the JSON.NET deserializer. When serializing the request, the formatter will either simply serialize a single parameter if it’s the only one, or it will wrap it in a JSON object with properties named by the operation parameter name. The last thing it does on serialization is to again set the body format property (to ensure that the raw encoder will be used for that message) and also set the “To” header of the message (which is required for REST messages, since it uses manual addressing on the transport).

Now for testing the formatters. The first thing we need is the content type mapper, to ensure that all incoming requests will be read by the raw encoder. Its implementation is quite simple.

Now for the test itself. I’m using a helper method (SendRequest) to send arbitrary HTTP requests to the server, but I’ll skip it here (it’s just setting up HttpWebRequest and displaying the results from HttpWebResponse). The test code sets up a service and adds two endpoints, one “normal” (SOAP) and one JSON.NET enabled

And that’s it for the formatter example!

New WCF Web API

One note that I want to leave here is that it’s not too easy to integrate any new formats in the existing WCF REST pipeline. In the example above I had to deal with formatters, Message objects, take a dependency on a content type mapper, just to be able to use this different serializer. And even after all of this, it’s not completely integrated with the pipeline – UriTemplates aren’t supported, for example. In an upcoming release, however, the WCF team is working hard to make WCF really a great platform for hosting HTTP services, and that includes a new platform (built on top of the current one) for HTTP services specifically. In the new WCF Web API (you can preview the bits on the Codeplex site) implementing such a scenario is a lot simpler, and other features (such as UriTemplate) will just continue to work after the new formatter is plugged in. Glenn Block has posted a formatter that does exactly that on the thread https://wcf.codeplex.com/discussions/255873, you decide which one is easier :)

Coming up

Operation selectors.

[Code for this post]

[Back to the index]

Carlos Figueira
https://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira https://twitter.com/carlos_figueira

Go to Control Panel / Programs / Programs and Features / View Installed Updates

Use the Search Box to search the updates for

• KB2495593
• KB2478063

Or if you prefer, search the list your self

Microsoft .NET Framework 4 Platform Update 1 - Runtime Update

1. Look for .NET Framework 4 Extended
2. Look for Update for Microsoft .NET Framework 4 Extended (KB2478063)
3. Click on the Help Link to see what you get with this update

Microsoft .NET Framework 4 Platform Update 1 – Design-time Package for Visual Studio 2010 SP1 (KB2495593)

1. Look for Microsoft Visual Studio 2010 (<Your Edition) – (<Language>) (KB2495593)
2. Click on the Help Link to see what this update contains

Programs

Look in the registry for the following keys

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\SKUs\

.NETFramework, Version=v4.0.1

.NETFramework, Version-v4.0.1, Profile=Client

Ron Jacobs
https://blogs.msdn.com/rjacobs
Twitter: @ronljacobs https://twitter.com/ronljacobs

The message inspectors, described in the previous post of this series, allows you complete control over the message going through the WCF stack. They’re very powerful, but you have to know how to deal with the Message object, which is not the most desirable way of programming. If the service model in WCF hides all the messaging framework by allowing us to define our services in terms of strongly-typed operations (i.e., using nice primitive and user defined types), there should be a way of intercepting requests / responses after all the processing to extract those parameters from incoming messages (or before they’re packaged in outgoing messages) is done. The IParameterInspector is exactly that – before and after each call, the inspector gets a chance to inspect the operation inputs, outputs and return value, in the same types as defined by the operation contract, no conversion needed (the only thing needed is a cast, since the parameters are passed as objects).

Public implementations in WCF

None. There aren’t also any internal implementations of this interface in WCF, this is really a user (as opposed to system) extensibility point.

Interface declaration

Unlike the message inspector, the parameter inspector interface is the same for both client and server side. At the server side, right before the call is dispatched to the user code, BeforeCall is invoked, where the inspector can look at the inputs to the operation. When the operation returns, AfterCall is invoked to let the inspector look at the return value of the operation, and any out/ref parameters which the operation may have set. At the client side, right after the call on the proxy is made, and before it’s handed down to the WCF stack, BeforeCall is invoked to let the inspector look at the outgoing parameters before they’re packaged into a message object. Finally, when the call returns from the server and the result is about to be returned to the client (either by returning the synchronous invocation or in an asynchronous callback), AfterCall is called at the client side.

Like in the message inspector case, if the operation contract being called by the client is marked with IsOneWay=true, the call to AfterCall on a client inspector does not happen (it does happen at the server, though). And unlike the message inspector case, if an exception is thrown during the processing of the call (e.g., the server returned a fault), AfterCall will also not be called on the client – it makes sense, since there is no guarantees that the return value or any out/ref parameters have valid values at that point.

How to add parameter inspectors

At the server side: the list of parameter inspectors is available at the DispatchOperation object – each operation has its own list of parameter inspectors. It is typically accessed via an operation behavior in a call to ApplyDispatchBehavior:

At the client side: the list of client parameter inspectors is available at the ClientOperation object, and typically accessed via an operation behavior’s ApplyClientBehavior method..

Real world scenario: simple profiler

One usage which I’ve seen a couple of times for the parameter inspector is to create a simple profiler / statistics page for WCF services. The parameter inspector interface methods are called really close to the actual method invocation (as can be seen in the example of the WCF Runtime post), both on the client and on the server, so they can fairly accurately record starting and ending times of arbitrary method calls. The example below is implemented as an endpoint behavior which adds the statistic collection logic for all the operations in the endpoint. In this example, we need to call a method on a class to show the statistics, but a more realistic scenario would save the profiling information in a file or database for further analysis.

And here comes the usual disclaimer: this is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Also, for simplicity sake it doesn’t have a lot of error handling which a production-level code would. Also, as I mentioned before, the statistics are all stored in memory, a better profiler would save the profiling information in a file or database, and possibly even expose it as a service itself.

As with all of the runtime examples, it starts with a behavior. I’ll use an endpoint behavior here, but a contract (or even service) behavior would do.

The behavior takes a “manager” as a parameter. The manager is the entity which will, in this example, store the call information for all the operations in the contract. It can then be invoked to display a summary of the statistics for the calls (I’ll omit most of the formatting methods here, you can find them in the code for this post, linked below).

Notice that there are two methods to add information about an operation call. For “normal” operations, we provide the duration of the call, but for one-way operations, this information cannot be retrieved (esp. at the client side, since the control will return to the caller almost as if the call was made asynchronously). Next we’ll get to the inspector itself. It’s implementation is actually fairly simple, as it registers the time in which BeforeCall was invoked, and returns it as the correlation state to be passed to the AfterCall method (unless the operation is one-way, in which case we simply register such a call in the manager). There, we again register the time and take the difference between the two times to calculate the duration of the method, then store it in the manager.

And that’s it – this nothing else needed. Now for testing I’ll define a service with some operations which take a certain amount of time (simulated using a random generator), and some “fast” ones (again I’ll skip the definition of the data contracts used in the service, as they’re not relevant to the topic, but they can be found in the code for this post, linked below).

And finally, hosting the program to see the simple profiler in action:

Coming up

Client and server (dispatch) message formatters, with an example showing how to send / receive arbitrary data without using the WCF REST Raw programming model – this issue came up at the forums a few weeks back.

[Code for this post]

[Back to the index]

Carlos Figueira
https://blogs.msdn.com/carlosfigueira
Twitter: @carlos_figueira https://twitter.com/carlos_figueira