The Problem Solver

One of the nice new features in Visual Basic 9 are lambda expressions. They where actually added as one of the underlying pieces for LINQ. But besides enabling LINQ you can use them in all sorts of places. One of the places they really help me is in places where I previously needed to declare a delegate and use that.

Take for example the following code where I use the ThreadPool to do some work:

Private Sub btnStart_Click() Handles btnStart.Click
    ThreadPool.QueueUserWorkItem(AddressOf DoWork)
End Sub

Private Sub DoWork(ByVal state As Object)

    For index As Integer = 1 To 100
        SetProgressLabel(index)
        Thread.Sleep(100)
    Next
End Sub

The SetProgressLabel function reports the progress to the user by setting the text on a label. As the work is done in a background thread I need to use Invoke to set the text property.

Before VB9 I would have to implement the SetProgressLabel like this:

Delegate Sub SetProgressLabelDelegate(ByVal percentage As Integer)
Private Sub SetProgressLabel(ByVal percentage As Integer)
    If lblStatus.InvokeRequired Then
        lblStatus.Invoke( _
            New SetProgressLabelDelegate( _
                AddressOf SetProgressLabel), _
                percentage)
    Else
        lblStatus.Text = percentage.ToString() + " %"
    End If
End Sub

First I would need to declare a delegate with the right signature, create an object passing in the address of the function to call and the parameters. Even though I declared the delegate with its parameters the Invoke is not aware of these and I can add make errors with the parameters which don't show until runtime.

So here is a better way to do this in VB9:

Private Function SetProgressLabel(ByVal percentage As Integer) As Object
    If lblStatus.InvokeRequired Then
        lblStatus.Invoke(Function() SetProgressLabel(percentage))
    Else
        lblStatus.Text = percentage.ToString() + " %"
    End If
    Return Nothing
End Function

This time I use an lambda expression to call the SetProgressLabel function. No need for the extra delegate and I get full compile time checking . In fact the only drawback is that I need to declare SetProgressLabel as a function instead of a sub as VB forces a lambda expression to return a value. This makes working with lambda expressions somewhat less powerful than the C# implementation Lets just hope that problem is rectified soon.

One neat thing is that you don't actually need to target the 3.5 framework to use lambda expressions. The previous sample works just fine targeting the .NET 2.0 runtime as long as VB9 is used. The reason for this is that the lambda expression syntax is actually just a compiler trick and it creates an delegate for us behind the scenes. Pretty cool!

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

Last week was pretty interesting and busy

First we had the DevDays on Thursday and Friday. I was there to answer questions from the audience. I didn't get too many questions so I could take my time and actually spend around 90 minutes answering questions from one and around 1 hour with another. Add some more smaller questions and it kept me busy but still left time to check a few sessions.

One notable session I watched was by Neno Loje. It was the first time I saw him speak and he did a session about advanced ClickOnce. He did an excellent job. In general I enjoyed the two days and have to congratulate "mister DevDays" Arie Leeuwesteijn on a job well done

Besides the day program there was a new evening program on the Thursday. This was a lighter program with fun session. The best session was IT Boxing with Hassan Fadili as a referee. He is actually a real referee on his spare time and he did an excellent job!

So Friday evening I went to The Hague Jazz. I was kind of tired by then but it was still great fun. I forgot to take my DSLR so I shot a few, lousy quality, pictures with my phone.

Enjoy!

As I mentioned in my previous blog post adding a custom ActivityValidator class to an activity validates it at runtime as well as at design time.

So when is this runtime validation done and what happens when it fails?

The when part is when the WorkflowInstance object is first created using one of the overloads of the WorkflowRuntime CreateWorkflow function. This means that the activity cannot really validate all properties as they are when it starts executing. After all when it depends on some data provided by another activity it needs to wait until this other activity has executed. And that will not happen at the CreateWorkflow moment but after it is started. So only use it to validate properties that need to be set at compile time. So what is the point of checking at runtime? Well suppose your existing activity changed and has extra requirements. The existing workflow's may not be recompiled so the first opportunity is to detect the error at runtime.

So what happens when the workflow is loaded and the runtime validation fails?

In that case an exception of type WorkflowValidationFailedException is raised. The Errors collection contains all validation errors in the form of ValidationError objects. Check the ErrorText property so see what is wrong.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

Modifying already executing workflow's is a very powerful option. Now, as with most advanced options, not something you are going to need every day but certainly something to be aware of and use when the needed.

First lets take a quick look at why we would want to modify an already running workflow in the first place.

Consider the following scenario. You have long running, lets assume a year on average, and part of the workflow has to do with shipping products. And lets assume that the shipping is done by any one of a number op shippers and that this involves multiple steps, sort of a mini workflow itself, which are different for each shipper. Now you could add a big IfElseActivity with a branch for each possible shipper and be done with it. But now suppose the company starts doing business with a new shipper. So you go and add an branch to the IfElseActivity and implement the new shipper, no big deal. But all already running workflow's are based upon the original workflow without the new shipper, so they cannot use the new shipper. And if the new shipper is a lot cheaper that means you have to explain why all the additional shipping costs are made :-(

So how to solve a problem like this?

Well is we decide to add the shipping activity to the workflow at runtime, at the moment we actually need it, we get the flexibility we need. In fact it even makes the workflow simpler as we don't need to implement the big IfElseActivity. And in software development simple is good :-)

So what do we actually need to change an executing WorkflowInstance? The class to start with is the WorkflowChanges. This WorkflowChanges object has a property named TransientWorkflow that lets us get to the actual workflow definition. Now we can use this to add the activities we want. In fact we can also change or remove activities as well.

One easy way is to add a SequenceActivity as a placeholder where you want to add your new functionality like this:

Adding an extra activity is done from codeActivity3 (actually the second in the workflow) with the following code:

WorkflowChanges changes = new WorkflowChanges(this);

SequenceActivity activity = 
    (SequenceActivity)changes.TransientWorkflow.GetActivityByName("dynamicActivity");

NewActivity newActivity = new NewActivity();
newActivity.TextToPrint = "This is a dynamically added activity!";
activity.Activities.Add(newActivity);

ValidationErrorCollection validationErrors = changes.Validate();
if (!validationErrors.HasErrors)
    try
    {
        ApplyWorkflowChanges(changes);
    }
    catch (WorkflowValidationFailedException ex)
    {
        validationErrors = ex.Errors;
    }

foreach (var error in validationErrors)
    Console.WriteLine(error);

The most important thing to notice is that the ApplyWorkflowChanges is the one that actually changes the running WorkflowInstance. And if the update fails for some reason an WorkflowValidationFailedException is thrown with a property Errors that is a collection of ValidationError objects.

Before using the ApplyWorkflowChanges function we van validate the changes. This will catch some, but not all possible, errors so just validating and removing the try/catch is not recommended.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

There are several options for validating properties on a custom activity.

Besides the possibility of using an ActivityValidator as described here we can also use the ValidationOptionAttribute. Now the ValidationOptionAttribute isn't useful all the time and only for a limited set of properties.

First of all the limited set of properties. This will only work for dependency properties defined with DependencyPropertyOptions.Metadata. This makes them metadata and they cannot be changed at runtime, only design time.

The second is the limitation in that is can only enforce a required field. No specific values or even an error tekst.

So using this is a little weird to. With the ValidationOptionAttribute being an attribite the first thing that comes to mind is decorating the property with it. Well that doesn't seem to do anything .

[ValidationOption(ValidationOption.Required)]
public string MyMetadataProperty
{
    get
    {
        return ((string)(base.GetValue(ValidatedActivity.MyMetadataPropertyProperty)));
    }
    set
    {
        base.SetValue(ValidatedActivity.MyMetadataPropertyProperty, value);
    }
}

No in fact what you need to do is add it to the DependencyProperty constructor like this:

public static DependencyPropertyMyMetadataPropertyProperty =
    DependencyProperty.Register("MyMetadataProperty",
    typeof(string),
    typeof(ValidatedActivity),
    newPropertyMetadata(DependencyPropertyOptions.Metadata,
        newAttribute[] { newValidationOptionAttribute ValidationOption.Required) }));

Not very inuitive at all.

I guess the only benefit of this is not having to include a ActivityValidator but as far as I am concerned this is not a big benefit.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

The current version of SQL Server Compact has no support for 64 bits computing. While this may seem a problem if you want to deploy you application on a 64 bits version of Windows it really isn't most of the time. In fact if you change your assembly from the default AnyCPU to x86 compatible it will work just fine using Windows On Windows (WOW).

But even better there will soon be a native 64bits version of SQL Compact. This isn't in the beta version that is distibrited with Visual Studio 2008 SP1 beta but Steve Lasker promises it will be in the final version when that releases.

Another nice feature that will be added is support for LINQ to Entities. And that includes the designer support we now lack with LINQ to SQL.

More info about the change can be found in this blog post by Steve Lasker.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

Create a derived class from ActivityValidator and add it to your custom activity using the ActivityValidatorAttribute. For example:

[ActivityValidator(typeof(ValidatedActivityValidator))]
public partial class ValidatedActivity : SequenceActivity
{
}

The validator class now look like this:

class ValidatedActivityValidator : ActivityValidator
{
    public override ValidationErrorCollection Validate(ValidationManager manager, object obj)
    {
        ValidationErrorCollection result = base.Validate(manager, obj);

        ValidatedActivity activity = obj as ValidatedActivity;
        if (activity != null && activity.Parent != null)
        {
            if (activity.AValueBetween1And250 < 1)
                result.Add(
                    new ValidationError("The value is to small", 
                        102, false, "AValueBetween1And250"));

            if (activity.AValueBetween1And250 > 250)
                result.Add(
                    new ValidationError("The value is to big", 
                        103, true, "AValueBetween1And250"));
        }

        return result;
    }
}

Note that the object parameter (obj) is the activity to be validated.

The ActivityValidator type contains two virtual function Validate and ValidateProperties. It doesn't really matter which you use as the Validate actually calls the ValidateProperties function. This means they are both called at the same time unless you change the behavior by not calling the base.Validate() function.

To indicate errors or warnings you can add a ValidationError object to the ValidationErrorCollection to be returned. Adding the property name makes life easy on the developer using your activity because it allows the designer to automatically select the property by double clicking the error.

Another thing to keep in mind is that the validator will be called when the activity itself is compiles. To see if this is the case check the activity Parent class which will be null.

The validator is also called when the workflow is executed allowing for runtime property checking.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

 VS2008 SP1 Beta is quite a package. By default the installation downloads the packages as needed and when needed. Now that is just fine if you only need to install a single machine. But when you need to install multiple, possibly virtual, machines like I have to it just wastes a lot of bandwidth and time . Fortunately there is a solution and it can be found here in the blog post by Heath Stewart.

Enjoy! 

The Dutch Microsoft office has posted the first of the Community DevCast we recorded. The host is Alex Thissen who actually does most of the work as he also edits the screencasts so don't forget to thank him next week when you run into him at the Dutch DevDays.

I am happy to say that amongst the first 6 screencasts released are no less that 4 I did with Alex about Workflow Foundation. And there are more to come so stay tuned.

The other two are about C# and done by Dennis Vroegop again with Alex as the host.

You can find the Community DevCast here. Keep in mind they are for a Dutch audience so they where recorded in Dutch!

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

By default every custom workflow activity shows the same icon. And using an icon that help understand what the activity actually does makes life so much easier for the user of your activity. And remember he is a developer so some day he might just return the favor

The default looks like this.

So changing the icon isn't hard there are just a few steps that might catch you if you aren't careful.

This is what my demo project looks like:

1. Add the new image to the project. In my case I added a folder named Images and dropped the PushpinHS.png in there. This PushpinHS.png can be found in the standard VS2008ImageLibrary.zip located in C:\Program Files\Microsoft Visual Studio 9.0\Common7\VS2008ImageLibrary\1033.
2. Change the build action for PushpinHS.png to Embedded Resource.
3. Next go to the Activity1.cs file and add the ToolboxBitmap attribute to the Activity1 class. We need to specify two parameters, the first is a type in which assembly the PushpinHS.png is located and the second is the name of the resource to use. These two are related because the resource name us relative to the namespace of the type used.

[ToolboxBitmap(typeof(Activity1), "Images.PushpinHS.png")]
public partial class Activity1: SequenceActivity
{

}

And now we have a nice new icon in the activity like this:

One problem is that the resource name is actually relative to the class specified. Using relfector makes it easy to see all the actual names, including the namespace used.

So what to do if your activity is in another namespace and a direct reference to the resource isn't possible?

The easiest way is to add another class outside of all namespaces and fully specify the resource name like this:

using System.Drawing;
using System.Workflow.Activities;

internal class ResourceLoader
{ }

namespace WorkflowConsoleApplication1.MyActivities
{
    [ToolboxBitmap(typeof(ResourceLoader), "WorkflowConsoleApplication1.Images.PushpinHS.png")]
    public partial class Activity1: SequenceActivity
    {
        public Activity1()
        {
            InitializeComponent();
        }
    }
}

Note the ResourceLoader used in the ToolboxBitmap attribute is not included in any namespace to we need to specify the full resource name "WorkflowConsoleApplication1.Images.PushpinHS.png".

Enjoy!

 When I tried I received the following very helpful System.ServiceModel.ProtocolException with Message="The remote server returned an unexpected response: (407) Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied.  )."

And this in turn contained an inner exception of type System.Net.WebException and Message="The remote server returned an error: (407) Proxy Authentication Required.".

Now I cannot find any way to add the required authentication but it turns out that setting the wsHttpBinding useDefaultWebProxy to false works just fine

Enjoy! 

For some reason a lot of people seem to think that only a single WorkflowRuntime object can be created in an AppDomain. And it isn't just the average Joe out there who seems to think so, no even book authors describe this behavior as the Workflow Foundation book I am reading now does so.

Just to set the record straight I will shout this out once more:

You can have multiple WorkflowRuntime objects in a single .NET AppDomain

Now I know where this perception comes from and its the original beta of Workflow Foundation way back before .NET 3.0 was released. Back then the WF team decided that only a single WorkflowRuntime would be enough for an AppDomain and created this restriction. I am not sure if they actually had a requirement or not but when people objected they listened and lifted the restriction.

The removal of this restriction is a good thing as multiple WorkflowRuntime objects can be useful. The main reason is that different workflow's can have different, and conflicting, requirements of runtime services. And as a single WorkflowRuntime can have only a single runtime service configuration, and that should never be changed while the WorkflowRuntime is active. For example just think of one workflow that is long running and needs a WorkflowPersistenceService while a second is short running and should never be persisted.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

The ReplicatorActivity is one of the more interesting Workflow Foundation activities to work with when you have a collection of data and want to iterate over each item. Basically just think of it as a For Each statement in regular code.

To demonstrate the behavior I have created a very small workflow that looks like this in the designer:

Or in case you prefer the XOML like this:

<SequentialWorkflowActivity x:Class="WorkflowConsoleApplication5.Workflow1"
                            x:Name="Workflow1"
                            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
  <ReplicatorActivity x:Name="replicatorActivity1"
                      ChildInitialized="SetupChildData"
                      Initialized="SetupData"
                      ExecutionType="Sequence">
    <ReplicatorActivity.UntilCondition>
      <CodeCondition Condition="RepeatUntill" />
    </ReplicatorActivity.UntilCondition>
    <CodeActivity x:Name="codeActivity1"
                  ExecuteCode="codeActivity1_ExecuteCode" />
  </ReplicatorActivity>
</SequentialWorkflowActivity>

The codebehind file I used looks like this:

Public Class Workflow1
    Inherits SequentialWorkflowActivity

    Private Sub codeActivity1_ExecuteCode(ByVal sender As Object, _
                                          ByVal e As EventArgs)
        Dim current As CodeActivity = sender
        Dim data = GetCurrentData(current.Parent)
        Console.WriteLine("The data is '{0}'", data)
    End Sub

    Private Sub SetupData(ByVal sender As Object, _
                          ByVal e As EventArgs)
        Dim replicator As ReplicatorActivity = sender

        Dim data() As String = _
        {"One", "Two", "Stop here", "Three"}

        replicator.InitialChildData = data
    End Sub

    Private Sub RepeatUntill(ByVal sender As Object, _
                             ByVal e As ConditionalEventArgs)
        Dim replicator As ReplicatorActivity = sender
        Dim data = GetCurrentData(sender)
        Console.WriteLine("Testing with data '{0}'", data)
        If data = "Stop here" Then
            e.Result = True
        ElseIf replicator.AllChildrenComplete Then
            e.Result = True
        End If
    End Sub

    Private Sub SetupChildData(ByVal sender As Object, _
                               ByVal e As ReplicatorChildEventArgs)
        Console.WriteLine("Starting child with '{0}'", _
                          e.InstanceData)
    End Sub

    Private Function GetCurrentData(ByVal sender As Object)
        Dim replicator As ReplicatorActivity = sender
        Dim result = replicator.CurrentChildData(replicator.CurrentIndex)
        Return result
    End Function
End Class

Using the without an UntilCondition is actually quite simple. The main thing to be aware of the ExecutionType property. In this case I didn't set it and it defaults to Sequence. This means that each iteration comes after the next iteration and we can use the CurrentIndex and CurrentChildData to retrieve the piece of data we are working with. When we set the ExecutionType to Parallel the ReplicatorActivity behaves very different. In that case each branch is started at the same time so the CurrentIndex, which is scoped to the ReplicatorActivity, doesn't help you. In fact it will return the last item of the collection every time you try.

In the case of parallel execution the way to get at the data is the ChildInitialized event. This event has a parameter of type ReplicatorChildEventArgs which in turn contains a property InstanceData which is the data this iteration is going to work with. its your responsibility to pass this InstanceData on to the activity inside the ReplicatorActivity. The usual thing to do here is create a custom, possibly sequence, activity with an extra property to hold the data and store it there in the ChildInitialized event.

There are a few interesting, and unexpected, thing to be a aware of when you use an UntilCondition with a ReplicatorActivity. When I run this simple test workflow I receive the following output:

There are a couple of interesting things to note:

1. The first time the UntilCondition is called is before the first ChildInitialized event and when we retrieve the current data it actually returns the last item. As far as I can tell there is no standard way to see this is case so if could be a problem you need to take care of it yourself. As far as I am concerned this is a serious shortcoming of the ReplicatorActivity
2. The UntilCondition fires after and not before each loop is executed. Basically this means it is easy to use the execution result of an iteration and decide to stop further iterations but hard to prevent all remaining iteration, including the current, based on the input data. Again you would need to add some conditional logic inside the ReplicatorActivity. No problem and actually quite a nice behavior but something to be aware of.
3. The ReplicatorActivity never stops if you don't tell it to. This is the behavior I most dislike with the ReplicatorActivity. Instead of just stopping and continuing with the next activity when all data is processed it just stops . Now this isn't the case when you don't have an UntilCondition, in that case every item is processed and when done it proceeds with the next activity just as you would expect. No with an UntilCondition you are responsible for stopping and to do so the UntilCondition is actually called one more time after the last item has been processed. The thing to check for is the AllChildrenComplete property of the ReplicatorActivity. When this is true all the data has been processed and you are responsible for stopping the ReplicatorActivity. Now this might not be hard but it always is a major point of confusion and, I presume, catches everyone at least the first time. And worse I can see no benefit at all for this behavior as the ReplicatorActivity just stops and the next activity is never scheduled. As far as I am concerned this is a big "bug" in the behavior of the ReplicatorActivity.

Removing the test for the "Stop here" in the UntilCondition result in the following output:

As you can see there is one additional UntilCondition at the end at which time the AllChildrenComplete property is set to true.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

The recent release of the .NET 3.5 and Visual Studio 2008 beta Service Pack 1 has started an interesting discussion over on Microsoft Watch. Joe Wilcox writes about how some of these posts seem predated and about seeing some blog post before being published, under embargo, just as previously happened with press releases. he raises an interesting question: are blog posts degraded to just just another marketing outlet and, possibly, not even written by the people under whose name they are published?

There may well be some truth in this as blog are an important communication feature. And why would a pr or marketing person ignore such an obvious opportunity. So I am sure that some blog posts are really just PR. But than again I also believe that the vast majority is real and, other that the writers conviction that MS is the best thing since sliced bread, is trying to be objective.

Read the full article by Joe Wilcox here.

Enjoy!

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

I recently received a copy of Pro WCF: Practical Microsoft SOA Implementation so I could review it. So did I like the book? Not really

The problem with the book is that it wants to cover far too much and diverse material. Now covering a lot of material in a book isn't a bad thing per se but in this case it resulted in a book that doesn't really server a purpose.

Basically the book is divided into three parts. The first part is titled Introducing Windows Communication Foundation. In fact quite a large section is not about WCF but about SOA. Now there is nothing bad about discussing SOA but WCF isn't SOA or vice versa so starting a WCF book with a SOA discussion isn't a good thing as far as I am concerned.

The second part is titled Programming with WCF and this is the part that actually introduces the reader to the basics of WCF and how to use it. I found the examples and text not all that clear. For example the chapter about hosting has a section about self hosting a WCF service and another about hosting the service inside of IIS. The self hosting section seemed to be more concerned with writing a Windows service and the accompanying installer that the actual use of WCF. And the IIS hosting part seems to be more about the differences of all the IIS versions. Admittedly something that is important but I would have preferred more coverage of the WCF specific issues.

The third part is titled Advanced topics in WCF and is actually half the book. The authors cover quite a lot of material in these chapters. The result is that, although a lot is covered, most of the material is not covered to the level needed when actually doing advanced work. So basically the authors let us know about the possibilities without giving a full coverage.

Another, although minor issues, is that the book is written using Visual Studio 2005. This means that for those readers using Visual Studio 2008 some of the steps described are no longer valid.

One thing that did surprise me where the names of the technical reviewers named in the book. It appears two of the three are also part of the team of authors. So much for pear reviews

So can I recommend this book? No not really as I don't think this one is up to the standard I have come to expect from the Apress  Pro series. Both for the novice and experienced WCF developer there are better books out there.

www.TheProblemSolver.nl
wiki.WindowsWorkflowFoundation.eu

Attached are the session slides and samples from my Visual Studio Tools for Office session I did in Galway earlier today. Hope you enjoyed the presentation as much as I did

Download them here.

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

Attached are the session slides and samples from my Workflow Foundation in a Service Oriented world I did earlier today in Galway, Ireland. Hope you enjoyed the presentation as much as I did

Download them here.

www.TheProblemSolver.nl
http://wiki.WindowsWorkflowFoundation.eu

Wat gebeurt er allemaal voor .NET ontwikkelaars in Nederland? Best veel geloof dat maar. En niet alleen de opvallende zaken als een DevDays of een SDC maar er zijn veel meer bijeenkomsten. Alleen hoe weet je wat er allemaal georganiseerd word en door wie?

Tot nu toe moest je daar een hele serie websites en blogs voor nalopen, niet echt handig als je het mij vraagt. Daarom heb ik besloten die informatie te verzamelen op een enkele plaats. Zeg maar een one stop shop voor .NET bijeenkomsten die interessant zijn voor Nederlandse .NET ontwikkelaars. EN waar kan je dat dan wel vinden? Op de site www.DotNetEvents.nl! Mooi in een overzicht per maand dus de manier om te zien of er iets interessants georganiseerd wordt waar je ook naar toe wil.

Uiteraard kan het zijn dat er bijeenkomsten zijn waar ik ook niets van weet. Als je er een weet die niet op het overzicht staat stuur me dan even een berichtje zodat ik die toe kan voegen aan de lijst.

Tot de volgende bijeenkomst!