Kristian Kristensen’s Blog

I needed to compare two Nullable date values in a workflow service. The way it was organized was as a parameter to a method call (using the InvokeMethod Activity), namely the Sort call on a collection of POCOs. The parameter is of type Comparison with T being MyPOCO, and it’s value was something that had to compare two Nullable dates.

At first the dates couldn’t be null, and hence there wasn’t a problem. I’d just use CompareTo:

Function(d1, d2) d1.MyDate.CompareTo(d2.MyDate)

Once the values are Nullable though it’s a different game. I had an exception because now values in my collection could have null on the MyDate property.

System.InvalidOperationException: Failed to compare two elements in the array.
—> System.InvalidOperationException: Nullable object must have a value.

My solution was to rewrite the function delegate I pass in, and use Nullable.Compare:

Function(d1, d2) Nullable.Compare(d1.MyDate, d2.MyDate)

If you like my writing you should subscribe to my RSS feed.

I got a funky error when I tried to host my workflow services in AppFabric on my developer machine. I run Windows 7 64-bit. As I deployed my web application to AppFabric I got this error:

Cannot create unknown type ‘{clr-namespace:your -namespace}’

Turned out my update was to use some types (Workflow Activites) from another assembly that happened to be an Exe file. However, that wasn’t the main problem. The underlying problem turned out to be that my Exe platform target was set to x86. The project had been created when I ran Windows 7 32-bit and I hadn’t updated it after reinstalling.
Chris Crowe has a good explanation with screenshots about it, Could not load file or assembly ‘name’ or one of its dependencies .
Bottom line: You need to either change your platform target to “Any CPU” or x64, or if that’s not an option allow the application pool to use 32 bit applications (configurable from the IIS Manager’s Advanced Settings on the AppPool).

If you like my writing you should subscribe to my RSS feed.

With .NET 4.0 we also got a new release of Windows Workflow Foundation. It’s a complete rewrite of the Workflow framework that was part of .NET 3.0/3.5. One of the strong points of the new release is in the integration between WF and WCF. Part of this is being able to call web services easily from inside Workflows. This is accomplished using the built in Send Activity. Depending on your integration scenario you might need to have some pretty elaborate service configurations and hence bindings. Once you’ve configured your WCF binding, which is what WF uses to actually call the web service, you should be able to go.

I had to call a service that required a UserNameToken configured. Setting this up in WCF is easy. Configuring WF to call using the WCF binding is moderately easy as well. But specifying the UserName ClientCredentials is not so easy. In regular code calling WCF you could write:

client.ClientCredentials.UserName.UserName = USERNAME;
client.ClientCredentials.UserName.Password = PASSWORD;

Doing this in WF is not so easy since you don’t have access to the client proxy. The next thought might be to specify it in WCF configuration, however unlike other Client Credentials the Username and password is not externally configurable. Obviously because that would put the two in clear text in a configuration file. In an MSDN Forum post a developer from Micrsoft acknowledges that this feature isn’t supported in the initial release. So how do you accomplish this scenario?

One solution is described here Setting UserName ClientCredentials in WF SendActivity. With this in place you attach to the processing pipeline in WCF and can hence set the Client Credentials as you please. Obviously you can retrieve the username and password from where ever you want. When the Send Activity does the call to the web service via WCF this custom extension will be called and you’re set to go.

If you like my writing you should subscribe to my RSS feed.