The Problem Solver : WF4, DevCenter

Workflow 4 and Visual Basic expressions Survey

Maurice — Wed, 13 Jan 2010 08:42:55 GMT

The topic of Visual Basic expression in Windows Workflow Foundation 4 seems to be a bit of an item for some people as you can see in the comments to my blog posts about it here. Now personally I don’t think it is such a big deal as it only concerns the expressions entered in the workflow, the main project can still be C# if you so desire.

Anyway the team responsible at Microsoft have created a survey asking for feedback on the subject. So if you have an opinion, and many seem to, please take 5 minutes go here and complete survey.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Online presentation: Meet the New Workflow WF4

Maurice — Mon, 30 Nov 2009 08:49:19 GMT

Tomorrow I will be doing an online presentation about Windows Workflow Foundation 4. The meeting lasts 1 hour and starts at 4PM European time, 3PM UTC or 7AM PST.

The goal is to provide an overview of WF4 and how to get started with it in Visual Studio 2010.

I will be doing the meeting using LiveMeeting and you can register here.

During the meeting I will also be tracking the Twitter hash tag #dmwf4 for additional questions and feedback.

“See” you there tomorrow

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

WF4&WCF and message correlation

Maurice — Wed, 02 Sep 2009 15:27:34 GMT

Note: This blog post is written using the .NET framework 4.0 Beta 2

In the previous blog posts, here, here and here, I demonstrated how to use WCF from WF4. This same some more about sending multiple messages to the same workflow, AKA Workflow Correlation.

One of the ugly parts of Windows Workflow Foundation 3 was the message correlation part when you used WCF to send multiple messages to the same workflow.

When using WF3 you where forced to use one of the context bindings like BasicHttpContextBinding or WSHttpContextBinding. Not only that but you also had to retrieve and set the correlation context using the IContextManager and set it to some arcane guid. This guid was the workflow instance ID but having to use that on the client means the client had to be very aware of the server technology used, something that goes against the principals of WCF. Using something in the message itself as to route the message to the correct workflow was just not possible with the build-in activities.

Fortunately the WF4 story is much better. No longer do we need to use the “context” bindings but the standard WCF bindings will do just fine. And the client doesn’t have to work with the workflow instance id but can pass some more logical data, like an invoice number, that will be mapped to the correct workflow. Much better!

To demonstrate this we first need to expand the workflow so it can receive multiple messages for the same workflow. The input for both Receive activities will still be the same person class from the previous example and we will use the persons ID to route the messages.

The new workflow definition looks like this:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<Person>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle1 = new Variable<CorrelationHandle>();

    result.Variables.Add(handle1);

    var handle2 = new Variable<CorrelationHandle>();

    result.Variables.Add(handle2);

    var receive1 = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle1)}

},

        CorrelationQuery = CreateCorrelationQuery(),

        CanCreateInstance = true

};

    result.Activities.Add(receive1);

    var write1 = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write1);

    var reply1 = new SendReply()

        Request = receive1,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply1);

    var receive2 = new Receive()

        OperationName = "Operation2",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle2)}

},

        CorrelationQuery = CreateCorrelationQuery()

};

    result.Activities.Add(receive2);

    var write2 = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called again with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write2);

    var reply2 = new SendReply()

        Request = receive2,

        Value = new InArgument<string>("The second result")

};

    result.Activities.Add(reply2);

    return result;

This is very similar to the previous workflow except we have two Receive activities and only the first is configured to allow the message to create a new instance.

The trick in getting the second message routed to the same workflow is by setting the CorrelationQuery on the two Receive activities. This is done in the CreateCorrelationQuery() function as follows:

private static CorrelationQuery CreateCorrelationQuery()

    var result = new CorrelationQuery();

    var xpath = new XPathMessageQuery()

        Namespaces = new XmlNamespaceManager(new NameTable()),

        Expression = "//sample:Person/sample:Id"

};

    xpath.Namespaces.AddNamespace("sample", "urn:WF4Sample:person");

    var messageQuerySet = new MessageQuerySet()

        Name = "RequestCorrelation"

};

    messageQuerySet.Add("PersonId", xpath);

    result.Select = messageQuerySet;

    return result;

The important part here is that the MessageQuerySet key value and the related Expression XPath must produce the same result for both request. Something that is easy here as I am sending in the same person object twice.

So the regular client has hardly any changes. All that is needed is the addition of the second operation to the ServiceContract like this:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Person request);

    [OperationContract]

    Operation1Response Operation2(Person request);

And calling the second operation like this.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Person()

        Id = 23,

        FirstName = "Joe",

        LastName = "Regular",

        BirthDate = new DateTime(1975, 7, 1)

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    //request.Id = 99;

    request.FirstName = "Maurice";

    request.LastName = "Chevalier";

    request.BirthDate = new DateTime(1888, 9, 12);

    result = proxy.Operation2(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

Note that I cam completely free to change the person object as long as I use the same Id. Should I change the Id the WorkflowServiceHost would try and find an existing workflow with the changed person Id, fail and throw a FaultException with message “The requested operation could not complete because instance key '4d7e998a-4cff-4743-3dd4-2afd5578383c' could not be found.”. Not quite sure where the Guid comes from but there is no workflow with that instanceId.

The good thing here is that the client doesn’t need to be aware of the workflow implementation on the server and the server can use “regular” message data to determine the correct workflow to send the message to.

The Workflow client has about the same change. In this case the Send activity is duplicated but other that that there is very little change and certainly no code that makes the client workflow aware of the service workflow.

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var person = new Person()

        Id = 7,

        FirstName = "Maurice",

        LastName = "de Beijer",

        BirthDate = new DateTime(1962, 8, 24)

};

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write);

    var delay = new Delay()

        Duration = TimeSpan.FromSeconds(5)

};

    result.Activities.Add(delay);

    var request2 = new Send()

        OperationName = "Operation2",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request2);

    var reply2 = new ReceiveReply()

        Request = request2,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply2);

    var write2 = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write2);

    return result;

Conclusion.

The WF3/WCF marriage in Wf3.5 left quite a bit to be desired and fortunately live has become a lot simpler with WF4.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Sending your own objects to a WF4 workflow

Maurice — Thu, 20 Aug 2009 13:11:00 GMT

In the previous two blog posts (here and here) I showed how to create and expose a Windows Workflow Foundation 4 workflow via WCF and have both a workflow and a regular C# client work with it. But the parameter and return value where real simple with just a string each. So how about passing some more complex data.

To show how to do so I will replace the singe string with a person object. Admittedly not the most complex person with only an id, first and last name and their birth date but enough to demonstrate the principal.

The main of the service, which uses a WorkflowServiceHost, stays exactly the same so see the first blog post for that part. The CreateWorkflow() function will change now reflecting the fact that the service will no longer expect a string but a person object.

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<Person>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var receive = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        CanCreateInstance = true

};

    result.Activities.Add(receive);

    var write = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write);

    var reply = new SendReply()

        Request = receive,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply);

    return result;

Not a big change really as we only have to change the input variable from Variable<string> to Variable<Person> and do the same with the Value property of the Receive activity which goes from new OutArgument<string>(input) to new OutArgument<Person>(input).

That leaves the Person class and this is just straightforward WCF work by turning the basic class into a data contract.

[DataContract(Namespace = "urn:WF4Sample:person")]

public class Person

    [DataMember]

    public int Id { get; set; }

    [DataMember]

    public string FirstName { get; set; }

    [DataMember]

    public string LastName { get; set; }

    [DataMember]

    public DateTime BirthDate { get; set; }

    public override string ToString()

        return string.Format("{0} {1} was born on {2} (ID: {3})", FirstName, LastName, BirthDate, Id);

Again no big deal

So with the service done we need to make the same changes to the two client applications. First the workflow client using the Send activity.

The Person class is exactly the same as on the server so just copy the code as is. Again the main in the workflow client doesn’t change, see the first blog post for that part. The part that does change a little is the CreateWorkflow() function so it creates and sends a Person instead of a string. The code goes as follows:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var person = new Person()

        Id = 7,

        FirstName = "Maurice",

        LastName = "de Beijer",

        BirthDate = new DateTime(1962, 8, 24)

};

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write);

    return result;

Again a very minor change.

So how about the C# console client from the second blog post?

The service contract changes a little and is now:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Person request);

The person class is very different from the service though and looks like this:

[MessageContract(WrapperNamespace = "urn:WF4Sample:person")]

internal class Person

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public int Id { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public string FirstName { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public string LastName { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public DateTime BirthDate { get; set; }

But besides the difference from using a message contract as opposed to a data contract this isn’t a big deal.

The main program changes a bit but not a whole lot. Again the only changes are due to the fact we are passing in a Person instead of a string.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Person()

        Id = 23,

        FirstName = "Joe",

        LastName = "Regular",

        BirthDate = new DateTime(1975, 7, 1)

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

All together not bad.

But so far we have only used a very simple workflow with a single message send to it. Suppose you want to send multiple messages to the same workflow? Well in that case we need to use message correlation as we will see next time.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

What does Windows Workflow Foundation 4 mean for existing workflow developers?

Maurice — Fri, 03 Jul 2009 20:12:54 GMT

The question of what Windows Workflow Foundation version 4 means for developers currently developing using WF recently came up. As I mentioned before WF 4 is a complete rewrite and doesn’t use any of the existing WF 3 classes. The design of WF 4 is even quite different from the design of WF 3.

So are WF 3 developers completely left in the dark and have to start from scratch? And what about their existing applications, will they still run on .NET 4 or are they stuck in .NET 3.5 until the end of times?

Fist of all let me address why I believe Microsoft could make such a radical change. Keep i mind this is just my personal opinion and I might be completely wrong .

WF 3 was never widely adopted so I believe the team felt they could do this and not create too much of a problem. Personally I don't think the low adoption of WF 3 had anything to do with the technology. Sure it has its problems but most people never got to the point that they ran into real technical issues. Instead most people looked, didn't understand and quit. So IMHO the main problem was far more a question if evangelism that technology.

So what is the big issue with a migration from WF 3 to WF 4?

One big issue with WF 4 is that Microsoft decided not to release a state machine implementation. In WF 3 there was a choice between state machine and sequential workflows. In WF 4 there is a choice between sequential and flow chart. And in WF 3 a state machine turned out to be far more flexible and useful and quite a few cases are not really covered by the WF 4 model. There are a few workarounds to do something like a state machine in WF 4 but they are not pretty. That said, a number of state machine workflows could very well be done using a flow chart.

As far as backward compatibility the story is a bit more complicated. WF 4 ships with an interop activity you can use to host custom WF 3 activities in a WF 4 workflow. How good or bad this is? I really don't know yet but given how different the two designs are I fear it is very limited.

But WF 3 developers need not worry about their existing projects!

There is however a second side to the compatibility story. .NET 4 will ship both with the WF 3 and the WF 4 runtimes. The WF 3 runtime will not be prominent but it will still be there so all existing WF 3 applications will continue to run as is. And because it is part of the current .NET framework I suspect this is a legal requirement (but then I am no lawyer so could be wrong here). So there is no reason for existing workflow developers to panic just yet .

So existing workflow developers should start learning WF 4 for future projects but can continue to keep using their existing WF 3 solutions for the foreseeable future.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Passing data into a Windows Workflow Foundation 4 workflow

Maurice — Tue, 30 Jun 2009 13:51:03 GMT

Passing parameters into a workflow is similar in WF4 as it was in WF3.

In both case a Dictionary<string, object> is passed in when creating the workflow instance object. Alternatively when using the WF4 WorkflowInvoker you can pass it into the Invoke() method.

This is quite simple but I have never been a fan of the very loose coupling here. basically on the outside you have to create a dictionary with as key something inside of the workflow. No compile time checking. No improvement where, unless you consider the somewhat easier unit testing with the WorkflowInvoker.

The actual behavior between WF3 and WF4 is quite different however.

In Wf3 if you pass in a key that doesn’t match up you get a System.Reflection.TargetInvocationException with a System.InvalidOperationException inner exception with the text: “This operation can not be performed at runtime.”. Great help in debugging

In WF4 on the other hand you get no error at all. The value is just ignored so it is even harder to detect typos. Well I guess not every change can be an improvement. And just in case you where thinking “But a unit test will take care of that right?” keep in mind that workflows tend to be complex and long running things not very well suited to unit testing.

Starting a workflow with a parameter:

Shared Sub Main()

    Dim inArgs As New Dictionary(Of String, Object)

    inArgs("Name") = "Maurice"

    Dim myInstance As WorkflowInstance = New WorkflowInstance(New Sequence1(), inArgs)

    myInstance.OnCompleted = AddressOf OnWorkflowCompleted

    myInstance.OnAborted = AddressOf OnWorkflowAborted

    myInstance.OnUnhandledException = AddressOf OnWorkflowUnhandledException

    myInstance.Run()

    syncEvent.WaitOne()

End Sub

So where is this Name value actually stored?

Well in WF3 that would have been stored in a property, possibly a dependency property, or a field. The types must match, exactly.

In WF4 the notion of properties and fields is gone. No more dependency properties to tie everything together. So instead we have Variables and Arguments. Basically a variable is just like a variable in a function, only here it holds some value for an activity. Big difference is that a Variable is in scope, i.e. visible, to all nested activities as well. So basically it is a way of sharing state between different activities.

To allows us to pass data into a workflow, or get something out, we need to use an Argument.

In this case I have defined two arguments, the Name to pass into the workflow and the Greeting that will be the result of the workflow.

Getting the result out is done in the OnCompleted delegate. This delegate is passed a WorkflowCompletedEventArgs which in turn contains another dictionary with all out argument.

Shared Sub OnWorkflowCompleted(ByVal e As WorkflowCompletedEventArgs)

    Dim greeting As String = e.Outputs("Greeting")

    Console.WriteLine(greeting)

    syncEvent.Set()

End Sub

Again not very different from WF3 where we used the WorkflowCompleted event and the OutputParameters dictionary from the WorkflowRuntime.

Conclusion

While there are quite a few differences in the details the basic approach remains the same. And as the old approach with dictionaries was rather error prone I consider this a missed chance

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

The new Windows Workflow Foundation 4 runtime

Maurice — Tue, 23 Jun 2009 09:20:04 GMT

With WF3 there was a central workflow runtime environment called the WorkflowRuntime and used to manage the lifetime of workflow instances. In WF4 this central class no longer exists and we manage individual workflows.

To compare the two, this is what a minimal console application looks like in WF3. It basically runs a workflow and prints a message when done:

static void Main(string[] args)

    using (WorkflowRuntime workflowRuntime = new WorkflowRuntime())

        workflowRuntime.WorkflowCompleted += delegate(object sender, WorkflowCompletedEventArgs e)

            Console.WriteLine("The workflow has completed.");

};

        WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(WorkflowConsoleApplication1.Workflow1));

        instance.Start();

        Console.WriteLine("Waiting for the workflow to complete.");

        Console.ReadLine();

The same functionality in WF4 looks very different:

static void Main(string[] args)

    WorkflowInstance myInstance = new WorkflowInstance(new Sequence1());

    myInstance.OnCompleted += delegate(WorkflowCompletedEventArgs e)

        Console.WriteLine("The workflow has completed.");

};

    myInstance.Run();

    Console.WriteLine("Waiting for the workflow to complete.");

    Console.ReadLine();

The most important thing to note is that there is no longer a WorkflowRuntime object, instead we create a new WorkflowInstance object passing in a workflow instance (compared to a workflow type before).

There are some benefits as well as drawbacks to not having a WorkflowRuntime.

The main benefit is that it makes creating and running workflows much easier. No longer do we need to keep track of a singleton and use that to do everything. Another benefit is we can register event handler per workflow instance, makes it easier to do different things for different types of workflows. In fact the OnCompleted isn’t an event but a delegate so you can add only a single handler.

The drawback is that general configuration. Like recording workflow errors, tracking execution or workflow persistence must be done for each instance while before we could just do it on the workflow runtime.

Some things haven’t changed. In both WF3 and WF4 running the workflow is done asynchronously so we need to wait, in both cases done using a Console.ReadLine().

Synchronous execution

With WF3 it was hard to have a workflow execute synchronously. Basically we had to add a different scheduler to the workflow runtime and explicitly tell the scheduler to execute the workflow. Of course this would affect every workflow created through the same WorkflowRuntime.

With WF4 there is a much easier model using the WorkflowInvoker class. All we need to do is call WorkflowInvoker.Invoke() passing in the workflow object and the workflow will execute synchronously on the same thread. Not only very useful for running the odd workflow but also for unit testing as any WorkflowElement, the base class for all activities, can be executed this way.

static void Main(string[] args)

    WorkflowInvoker.Invoke(new Sequence1());

    Console.WriteLine("The workflow has completed.");

    Console.ReadLine();

Nice right!

Enjoy.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Getting started with Windows Workflow Foundation 4

Maurice — Mon, 22 Jun 2009 13:18:11 GMT

As you may have heard Windows Workflow Foundation 4 is not an upgrade from Windows Workflow Foundation 3 (or 3.5). The version numbers might suggest that the previous version was quite mature but in fact it refers to the version of the .NET framework. In fact Windows Workflow Foundation 3 was the first version and 3.5 added only very few features and some bug fixes. And as WF 4 is a complete rewrite we should approach it as a new product and forget just about everything we already know about WF 3.

That might be a bit surprising, after all we still have activities and a workflow runtime right?

Well wrong actually!

There no longer is a class named WorkflowRuntime. Creating workflows is done by creating a WorkflowInstance object. This object is raises events for that workflow and only for that specific workflow.

But surely there is still an Activity base class?

Yes there is. But this is a completely new class that has nothing to do with the class Activity that was used with WF 3. In fact the new Activity class is in a new assembly and namespace, the full name is System.Activities.Activity in the assembly System.Activities.dll. The “old” activity class was System.Workflow.ComponentModel.Activity in the System.Workflow.ComponentModel.dll assembly. The old class still exists in .NET 4 so old workflows will still run but the new classes have no relation with the old classes.

So basically forget all you knew about the behavior of WF 3

So lets take a brief look at creating a new workflow 4 style workflow.

When we start Visual Studio 2010 and select File/New/Project we get the new project tab. Select the Workflow node and you will see the four new project types

More about the different types in another blog post. For now just select the “Sequential Workflow Console Application”.

What we end up with is a simple project with just 2 files, the program.cs and the Sequence1.xaml. The latter contains the workflow. Note there is no choice between code or xaml workflows, the designer only works with xaml based workflows. Also note that the extension is no longer XOML but has changed to XAML.

The Sequence1.xaml workflow is still empty and looks like this:

When we open the Toolbox we see the new collection of basic activities. These are also completely new. For now just drag a WriteLine activity onto the Sequence in the designer. The goal of the WriteLine activity is just what the name suggest: write a line of text to some form of output stream. When we open the property sheet with the WriteLine activity selected we see there are just three properties: the DisplayName, the Text and the TextWriter.

The DisplayName is actually the name used on the design surface and used during the design of the workflow.

The Text property contains the text we want to print. In the property sheet we see a textbox with the text “<Enter an expression>”. This really is an expression editor where you can type in code. So if you want to enter a simple fixed text you must use quotation marks around it. This must always be a valid Visual Basic statement. yes that isn’t a typo Visual Basic, not C#, even if you are developing a C# project.
So in this case just add “Hello Workflow 4” including the quotation marks.

The TextWriter property is the text stream to write the text to. This is also an expression, just like the Text, and is optional. When not specified the text will be written to Console.Out which will do fine for now.

These expression windows in VB are completely new and a big change from WF3. Where we previously had to bind to property binding or something similar to add custom code we can now type it directly into the designer.

With this in place we are ready to run the workflow. Press Ctrl+F5 and with a bit of luck you should see the output appear in the console window. You might need a bit of luck because it appears the current bits are still a bit unstable and on my laptop running Windows 7 the designer tends to lock up quite a bit

In the next post more about how the workflow is created and started at runtime.

Looking back at the MVP Summit

Maurice — Sat, 07 Mar 2009 11:08:09 GMT

Last week lots of MVP, myself included, where in Redmond visiting Microsoft on our yearly MVP pilgrimage. The MVP Summit is always a great event. Not only do we get to talk to the MS team members who actually design and build all the software we love and use but we also get to meet each other. And with MVP’s being located around the world that is kind of rare as well.

Despite this being a great event I still have very mixed feelings about this last MVP summit. The problem isn’t the events itself or the people I met, that was al great . No the problem was in some of the technological decisions made in product groups. Unfortunately I can’t divulge details yet because I have signed an NDA but as soon .NET 4.0 as beta 1 is made public I will be able to blog about some of these decisions. And rest assured I will!

The reason we really need to is the way these important changes are communicated. Or should I say not communicated. Some very important changes where not communicated at all and could only be derived by bullet points missing from PowerPoint slides. Only when directly asked about the missing bullet point would someone say “Yes that is right, we decided to …. NDA … because … NDA …”. Sorry about the NDA part .

I can only say that these decisions are a big problem and I know several MVP’s who decided to skip other sessions on the same product as a result. I didn’t, as far as I am concerned ignoring a problem is not going to make it go away, but I really think this product team needs to reevaluate this decision and the general future trend.

Despite this hiccup I am very exited about lots of the things I got to see and am really looking forward to .NET 4 and Visual Studio 2010. Now if we only could have a beta today . When we will have a first beta is still a big question though. If a date was announced I missed it, the best I heard was a quarter and is quite a time span.

Enjoy.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Goodbye XOML, hello XAMLX

Maurice — Tue, 11 Nov 2008 19:37:58 GMT

In the next version of workflow we are going to leave the XOML extension behind us. Creating workflow's or custom activities using markup will create a XAML file instead of the now familiar XOML file. That doesn't mean we are moving to exactly the same same format as WPF as WF is quite different in its nature.

But at the same time we seem to getting a new file extension named XAMLX. So what is this XAMLX all about? Well it turns out this is a markup file containing both the WCF service declaration as well as the WF service implementation. Is this a good thing? Well I am really not sure yet. XAML markup works great for hierarchical items like WPF forms or nested WF activities but a service interface is a different thing.

Guess I will have to think about this one some more.

Enjoy the CTP!