Sunday, February 27, 2011

WCF/MSMQ/.Net 4.0 stops processing messages–code fix

I recently upgraded a self hosted WCF service to .Net 4.0. Everything seemed to go well, but a few hours after deploying the service messages started piling up in the queue. I check the service host process and it was idle. It was still executing, but the service had stopped pulling messages. After a bit of trial and error I have discovered the problem and hopefully a solution.

The problem

It seems that .Net 4 has changed the behavior of WCF/MSMQ services slightly. If a problem occurs with the queue, the service host faults and stops.

The solution (I think)

Here is the code I came up with to address the problem. I wrote a class that creates the ServiceHost and attaches an event handlers to the Faulted event. If a fault occurs, I abort the ServiceHost and restart a new instance. (This is for a self-hosted WCF service – if you are hosting your service in IIS/WAS, I think you need to create a ServiceHostFactory class.)  Here is my code:

    /// <summary>
/// In .Net 4, the WCF/MSMQ behavior seems to have changed slightly. Occasionally, the service will fault and not restart causing
/// messages to get stuck in the queue. This class attempts to abort and re-start the service host in the event of a fault.
/// </summary>
/// <typeparam name="T">Your service class</typeparam>
public class RestartingServiceHost<T>
protected static readonly log4net.ILog Log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
ServiceHost _serviceHost;

public void Start()
_serviceHost = new ServiceHost(typeof(T));
_serviceHost.Faulted += new EventHandler(host_Faulted);

private void Restart()

private void host_Faulted(object sender, EventArgs e)
Log.Info("Host faulted. Restarting service.");

To use the class, simply create an instance of this class using the type of your service class:

var host = new RestartingServiceHost<MyService>();

That’s it. It seems to be working so far.

Setting up MVC 3 for Azure with a scripted build


I just spent a little time setting up an Azure project using ASP.Net MVC 3 and a scripted build. I thought I would share the solution. Be warned, I'm not an expert in this stuff -- let me know if you have any ideas on how to improve this.

Step 1: Set up the directory structure.

I like to follow a relatively simple directory structure for my projects. Of course you can use your own structure; I like this one.

\ProjectName\src     <-- source code, project files, etc.
\ProjectName\lib     <-- 3rd party libraries
\ProjectName\tools   <-- tools (FxCop, 3rd party build tool components, etc)

For this post, I will be using the project name "Gamma".

Step 2: Create the VS2010 solution

Start Visual Studio 2010 and create a new solution. I like to start with a blank solution and add projects as needed. Save as "\Gamma\src\Gamma.sln"

Add a new Windows Azure project. When you are prompted to add roles to the Azure project, skip this step. At the time of this post, the VS templates do not include an Azure MVC 3 project. To get around that problem. Add the empty Azure project to the solution. Then add a new project to the solution and select an MVC 3 project. Then, in the Azure project, add a "web role project in solution..." and select the MVC 3 project.

So, now you should have \ProjectName\src\ directory with one solution file, a directory for the Azure project, a directory for the MVC project and possibly a directory for the unit test project if you elected to add one.

Step 3: Create command line build scripts

I like to have a command line builds, especially for automating your build with a tool like Hudson or Jenkins. I found a post a while back about automating .Net builds and I really liked the approach. I will try to search for a link later to give credit. You create 3 files:

  1. a simple MS Build project file that builds your solution,

  2. a script file to kick off the build from the command line and

  3. a batch file that allows you to double-click on a file in windows explorer to produce a build.

Here are the file's I use:

build.ps1 -- powershell script for command line builds

if ($args)
& $env:systemroot\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe build.proj /t:$args /verbosity:minimal
& $env:systemroot\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe build.proj /verbosity:minimal

ClickToBuild.bat -- batch file for kicking off a build from windows explorer

PowerShell -Command ".\build.ps1"

build.proj -- MSBuild file for building your solution.

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


<Target Name="Package" DependsOnTargets="Clean;DebugBuild">
<Message Text="Creating Package for $(ProjectName)" Importance="High" />
<MSBuild Projects="$(ProjectName).sln" Targets="Publish" Properties="Configuration=Debug" />

<Target Name="DebugBuild">
<Message Text="Building $(ProjectName)" Importance="High" />
<MSBuild Projects="$(ProjectName).sln" Targets="Build" Properties="Configuration=Debug" />

<Target Name="Clean">
<Message Text="Cleaning $(ProjectName)" Importance="High" />
<MSBuild Projects="$(ProjectName).sln" Targets="Clean" Properties="Configuration=Debug" />

These are relatively simple. I save them the root of the "src" directory. In Visual Studio, I add a solution folder named "build" and add these 3 files to that solution folder.

The important thing to note is the Targets="Publish" in the package target of the MSBuild file. The "publish" target is what creates the Azure package files that you need for deployment. By default they will be in the \bin\Debug\Publish\ directory of the Azure project.

Note: Azure does not have the MVC binaries by default. You will need to get these to your Azure instance. There are a couple ways to accomplish this. You can either include all the DLLs in your project and set them to "copy local", or you can install MVC3 as part of the Azure startup script. Links to come later.

Let me know if this helped. If I find some time I will add some screen shots.