Scott Allen pointed out that if you need to declare top level properties in a XAML only workflow, you can subclass the root activity class, add the properties you want, then specify the custom subclass in the XAML workflow. That doesn’t really solve my problem. I’m trying to limit to activity vocabulary that the workflow author has access to. If they can specify their own custom type as the root activity of their workflow, they can also add whatever execution logic they want, which is what I’m trying to avoid.

There is an example in the Advanced Authoring chapter of Essential WF where they describe building a root activity class that generate top level properties as part of the workflow compilation process. The root activity (in the example, it’s called “SequenceWithVars”) where you can specify the top level parameters in the XAML. Here’s an example from the book:

<SequenceWithVars x:Class="Workflow1" xmlns="..." xmlns:x="...">

The SequenceWithVars type includes a custom ActivityCodeGenerator that loops thru the VariableDecls collection and adds a top-level property (via CodeDOM) for each VariableDecl instance. You end up with a workflow class that looks like this:

public partial class Workflow1 : SequenceWithVars
{
  public static DependencyProperty OrderProcConversationProp =
    DependencyProperty.Register("OrderProcConversation",
      typeof(Guid), typeof(Workflow1));

  public Guid OrderProcConversation
  {
    get
    {
      return (Guid)base.GetValue(Workflow1.OrderProcConversationProp);
    }
    set
    {
      base.SetValue(Workflow1.OrderProcConversationProp, value);
    }
  }

  //Remaining WF type declaration goes here
}

In order to use the XAML workflow with the SequenceWithVars activity, you do need to compile the XAML first using the WorkflowCompiler class. WorkflowCompiler.Compile() returns a compiled type which can then be passed to CreateWorkflow. But adding the separate compile step is a small price to pay, in my opinion. This approach lets me limit the workflows to XAML only while still allowing for top level properties which are needed in many data binding scenarios.

• I find Jim Kobielus’ “SOA as 50 square miles of fungus” analogy funny and strangely compelling. The “keep in the dark and feed it shit” jokes practically write themselves. (via Joe McKendrick)
• Politics 2.0 Rising: The number of Americans who got “most of their information” about the 2006 midterm elections was double the number from the 2002 elections.
• Do you use external/flash drives? Do you have issues when you try to “Safely Remove Hardware” with said drive? I do, all the time. Apparently, unlocker is the answer. (via Paul Andrew)
• How come there’s no information about LogToTraceListeners in the WF documentation? As far as I can tell, it’s not in the Windows SDK docs at all and the only reference to it on MSDN is this year-old article and this year-old blog post. I only discovered because someone on the internal WF discussion alias asked about it. I’ve added In my SSB/WF work, I subclassed the built-in SQL persistence service in order to add tracing support. If you’re developing a WF host, you need to turn this on. I find it mind-boggling this isn’t included anywhere in the official WF docs.
• Nice to see Soma bragging about Software Factories. As he writes, our current solution – consisting of the Guidance Automation Toolkit and the DSL Tools - are really just a first step. I’m just starting to experiment with the Web Service Software Factory (WSSF). Aaron Skonnard introduces both the ASMX and WCF version in his two most recent Service Station articles.
• Michael.NET makes Programming Promises and Ted Neward swears the Oath of the Conscientious Programmer. Why stop there? How about the Architect’s Affidavit to actually implement the shit we draw on the white board? The Technologist’s Testimony of understanding and belief in all things geeky and gadget? Come on, isn’t this just called “doing your job”? Do we really need to make promises and swear oaths to take it seriously and do it to the best of our abilities?