Archive for the ‘WF’ Category

Windows Workflow Foundation 4.0-related blogs


I’ve compiled a list of bloggers who seem to focus on WF4.0. Please post a comment if you have any blogs I’ve missed.

Matt Winkler [MSFT]
Kushal Shah [MSFT]
Ron Jakobs [MSFT]
The Activity Designer [MSFT]
Request/Reply [MSFT]
Zafar Mohammed [MSFT]
The .NET Endpoint [MSFT]
Cathy Dumas [MSFT]
Say wwhhhaaaat? [MSFT]
Go with the Flow [MSFT]
Maurice de Beijer [MVP]
Alan Smith [MVP]
Richard Seroter [MVP]
Richard Blewett [MVP]
Damir Dobric [MVP]
Zulfiqar Ahmed
Chris Craft [MSFT]
The Workflow Element

Solution: Add Service Reference does not always work properly in WF4 scenarios

No Comments »

Now, the title is a bit cryptic, so let me elaborate; earlier this week, I noticed that when I tried to add a service reference to a WCF Workflow service in the same ASP.NET Web Application, I didn’t get the expected result; custom activities for the service operations in the toolbox (when designing another WF Service).

Investigating further, I created a Workflow Console Application and checked if I got the same behavior; no – it worked perfectly. Same happened when I tried it with WCF Workflow Service Application / Declarative Service Library (Visual Studio templates).

Putting one and one together, I guessed that it had something about the definition of the project template. Visual Studio projects has a concept of ProjectTypeGuids that enables/disables specific features for a project once added. A couple of years ago, I noticed that I had to add a specific GUID in order to wire in the “F5 experience” when debugging WCF libraries.

When comparing the GUIDs set in one of the working projects with the ones in the ASP.NET Web Application, I noticed the following (magic number):


I retrofitted the GUID in the Web Application, added a service reference to a workflow service;


Building the project and presto! — custom activities for the service operations in the toolbox.

Now, this isn’t just a problem that can happen when using Workflow Services, it can also happen (as I’ve already mentioned) to WCF projects, test project et cetera too. My suggestion to Microsoft is that they in the future add an section somewhere in the Options pages where it is possible to turn on/off features like this one, so developers don’t need to turn autistic and start remembering a large set of project type GUIDs :-) (Oh, no offense to devs (or others) that actually are autistic).

Thanks @mwinkle for putting me in touch with the Add Service Reference guys, even though I found the workaround first :-)

Codename “Velocity” WF/WCF Persistence Provider


So, it’s been a bit quiet here lately. The natural cause of it is (in no particular order):

  • A lot of work
  • Spending quality time with my son
  • Hacking on different kinds of technology bits (mainly pieces released at the PDC 2008)

I’ve also tried to get a clear picture of my “blind spots” when it comes to WCF. Even though I feel quite competent, there are still tons of stuff that I don’t touch daily so I still have to “rehearse”.

Since I have “Get to know Workflow Foundation – for real” on my TODO list I spent some time playing with durable services.

The persistence provider mechanism that is located in System.WorkflowServices is not exclusive to to Workflows / Workflow services. It can also be used with “vanilla” WCF Services.

The idea is that the framework can persist the service instance after you have invoked a method and when a future method invocation comes down the wire, it can pull it from the persistence store – revive it and pass the call to the “same” instance. A perfect fit for the scenario of long running services.

So how do you enable durable services? It is quite easy. First, you decorate your service implementation with [DurableService] and one of the mechanisms that specifies that the type is serializable (I chose [Serializable] for the sake of simplicity).


In this code snippet we also see that there is another attribute that can be used to tell the persistence mechanism that a call to an operation creates the instance or tears it down; [DurableOperation].

The next thing you have to do is to wire up a persistence provider using either configuration or programmatically.

Out of the box there exists only one Persistence Provider; One suited for persisting the service instances to SQL Server – System.ServiceModel.Persistence.SqlPersistenceProviderFactory. You will have to set up a SQL Server Database instance with the schema located in C:\Windows\Microsoft.NET\Framework\v3.5\SQL\EN.

But that was a digression – now back to my custom “Velocity” Persistence Provider. If you don’t know what Codename “Velocity” is, I suggest that you head over here and read more about it. The short description:

It is Microsoft’s attempt to create an in-memory, high-performance, distributed caching supporting different scenarios that can suite many needs in both a web farm or other places where caching is needed. The current version that is publicly available is CTP2. We should expect a new CTP in March (around the time of MIX’09) and the RTW/RTM in the mid of 2009.

To implement a custom persistence provider, you will have to create two classes; the persistence provider implementation and its factory. It is the fully qualified type name of the factory that is specified when you set up the configuration.

The following configuration snippet shows how a custom service behavior is set up. You will have to set the behaviorConfiguration attribute on the service element to “defaultServiceBehavior” in this case.


The code for the provider is available here (Licensed under the Apache License 2.0).

Cheers :-)
kick it on