A quick search

July 21, 2007 Leave a comment

I did a quick search today to see if my Pro WF book is receiving any attention from other bloggers. Here’s a few places where it got a mention:

http://www.whiteknighttechnology.com/cs/blogs/bayer_white/archive/2007/05/14/1305.aspx
http://www.platinumbay.com/blogs/dotneticated/archive/2007/06/14/frameworks.aspx
http://community.bartdesmet.net/blogs/bart/archive/2006/08/27/4278.aspx

Advertisements
Categories: .NET, general, technology, workflow

Ode to Solution Explorer expand and collapse

July 12, 2007 Leave a comment

I’ve been using various versions of Visual Studio for a very, very long time. As each new version is released by Microsoft, I look in vain for the one feature that I really want. I want the ability to expand or collapse all projects within the Solution Explorer! Some of my solutions contain 100 or so individual projects. Do you know what a pain it is to manually collapse 100 projects individually? Why is it so difficult to implement this seemingly simple feature? Maybe I’m the only one who would like this, but I think not.

Categories: .NET, general, technology

Orcas Beta 1

June 23, 2007 Leave a comment

I realize this isn’t exactly the latest ground-break news, but the Orcas beta 1 is now available here.  I’ve downloaded and installed the beta but haven’t had the chance to really get into it yet.  I’m looking forward to trying out some of the new WF features, including the WCF/WF integration.

Categories: workflow

Persistence and Tracking together

May 23, 2007 1 comment

A reader of my workflow book recently wrote me with a question about the standard persistence and tracking services. Their question concerned how to use both of these standard services at the same time. Specifically, they wanted to know how to specify two different database connection strings in the App.config.

There’s really two separate questions there. First, how do you specify two different connection strings for the services, presumably pointing to two different databases. Second, is that how you should use these two services together?

To answer the first question, you can specify the connection string in either the CommonParameters section of the App.Config, or inline as an attribute of the service itself.

For example, here is an App.Config that provides two different database connection strings, one for each service:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="WorkflowRuntime"
    type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection,
          System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
          PublicKeyToken=31bf3856ad364e35" />
  </configSections>
  <WorkflowRuntime>
    <Services>
      <add type="System.Workflow.Runtime.Tracking.SqlTrackingService,
          System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
          PublicKeyToken=31bf3856ad364e35"
      ConnectionString="Initial Catalog=WorkflowTracking;
          Data Source=localhostSQLEXPRESS;
          Integrated Security=SSPI;" />
      <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService,
          System.Workflow.Runtime, Version=3.0.00000.0,
          Culture=neutral, PublicKeyToken=31bf3856ad364e35"
      UnloadOnIdle="true" LoadIntervalSeconds="5"
      ConnectionString="Initial Catalog=WorkflowPersistence;
          Data Source=localhostSQLEXPRESS;
          Integrated Security=SSPI;" />
    </Services>
  </WorkflowRuntime>
</configuration>

That answers the first question. However, that’s not the recommended way to use the standard persistence and tracking services at the same time. Instead, you should use the same database for persistence and tracking. One database means one connection string. And WF provides a special service named SharedConnectionWorkflowCommitWorkBatchService that you should also load. This service is optimized for use with the standard persistence and tracking services. It uses the same database connection for both services, avoiding the use of MSDTC that would otherwise be needed.

Here’s a revised App.config that loads the special commit work batch service and uses the same database for persistence and tracking. Since a single connection string is used for both services, it is moved back to the CommonParameters section of the App.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="WorkflowRuntime"
    type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection,
          System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
          PublicKeyToken=31bf3856ad364e35" />
  </configSections>
  <WorkflowRuntime>
    <CommonParameters>
      <add name="ConnectionString"
      value="Initial Catalog=Workflow;
          Data Source=localhostSQLEXPRESS;
          Integrated Security=SSPI;" />
    </CommonParameters>
    <Services>
      <add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowCommitWorkBatchService,
          System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
          PublicKeyToken=31bf3856ad364e35" />
      <add type="System.Workflow.Runtime.Tracking.SqlTrackingService,
          System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
          PublicKeyToken=31bf3856ad364e35" />
      <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService,
          System.Workflow.Runtime, Version=3.0.00000.0,
          Culture=neutral, PublicKeyToken=31bf3856ad364e35"
      UnloadOnIdle="true" LoadIntervalSeconds="5" />
    </Services>
  </WorkflowRuntime>
</configuration>
Categories: workflow

Exposing Nullable fields to .NET 1.1 Web Service Clients

March 23, 2007 Leave a comment

I recently ran into an interesting problem exposing a set of WCF services to .NET 1.1 web service clients. I was able to correctly generate the web service proxy class using the 1.1 version of the wsdl.exe utility. However at runtime, I ran into Xml serialization errors when I tried to access my WCF service from a .NET 1.1 web service client.

The problem was that the service method was returning an object that contain several nullable properties (System.Nullable<>). Specifically, they were nullable DateTime fields that were defined similar to this in my .NET 3.0 source:

private System.DateTime? _myTimestamp;
[DataMember]
public System.DateTime? MyTimestamp
{
    get { return this._myTimestamp; }
    set { this._myTimestamp= value; }
}

In a .NET 3.0 web service client, this isn’t a problem since the wsdl.exe utility generates the web service proxy class using System.Nullable<>. But this is a problem with .NET 1.1 clients since nullable types are not supported in .NET 1.1. The generated proxy class actually included two fields:

public DateTime MyTimestamp;
public bool MyTimestampSpecified;

The second xxxxSpecified field is generated when there is the possibility that the value for the field may not be transmitted. The xxxSpecified field is normally set to true, but it should be set to false for one of these nullable fields when it contains null. So the generated proxy class at least looks like it should support the concept of nullable fields. But it chokes when it actually tries to handle a DateTime that doesn’t contain a real value (a System.Nullable<> field without a real value in the .NET 3.0 world).

Although I searched for a solution to this problem, I didn’t find a direct answer. I finally stumbled upon the EmitDefaultValue property of the DataMember attribute. By default, EmitDefaultValue is true, meaning that even if a field contains the default value for that data type, it is transmitted. This means that an Int32 will transmit a value of zero (it’s default value) and so on. My System.Nullable<DateTime> field had a default value of null so null was transmitted. By setting EmitDefaultValue to false for my nullable fields, my problems were solved. My DateTime property now looks like this:

[DataMember(EmitDefaultValue = false)]
public System.DateTime? MyTimestamp
{
    get { return this._myTimestamp; }
    set { this._myTimestamp= value; }
}

Now when this field has a default value of null, it is not emitted to the caller. However, the MyTimestampSpecified field is correctly set to false in this case, indicating that the underlying field doesn’t contain a real value. All is good again and I can access my WCF services from .NET 1.1 and 3.0 web service clients.

I don’t know if this is the best approach to this problem, but so far, it does seem to work for me.

Categories: general

Sample Workflow Persistence chapter

March 19, 2007 Leave a comment

Apress has made Chapter 8 of my Pro WF book available for download in PDF format. This is the chapter that covers workflow persistence. You can obtain this sample chapter from the Apress page for this book, or directly from this site.

Categories: workflow

They’re Here!

February 14, 2007 Leave a comment

The official ship date of my WF book is next Monday (Feb 19), so I’ve been eagerly awaiting arrival of my copies of the book. The wait is now finally over. My wife called this afternoon to tell me that there were two rather heavy boxes that UPS dropped off in our driveway. As soon as I got home (yes, I did work the full day), I immediately opened the boxes to see the result of my almost-year-long project.

When you’re working on the book, writing, testing, editing and reviewing, you do get a sense of accomplishment. But it’s much different to actually hold a physical copy of the book in your own two hands. It looks great!

I checked Amazon and B&N, and it looks like it’s now in stock at both outlets. I’ll have to make a trip to the local B&N and see if they have it on the shelf.

Categories: workflow