I’m speaking at Software Architect 2010 in October. I’m going to be delivering two sessions on Windows Workflow Foundation 4.0: the first explains the basic architecture and looks at using workflow as a Visual Scripting environment to empower business users. The second looks at building big systems with workflow concentrating on the WCF integration features.

In addition to that I’ll be delivering two all-day workshops with Andy Clymer: Building Applications the .NET 4.0 Way and Moving to the Parallel Mindset with .NET 4.0. The first of these will take a number of new features of .NET 4.0 and show how they can be combined to create compelling applications. The second will look at the Parallel Framework Extensions (PFx) introduced in .NET 4.0 examining both the rich functionality of the library, how it can be best leveraged avoiding common parallel pitfalls and finally looking at patterns that aid parallelisation of your code

I’ve been working with the Unity IoC container from Microsoft Patterns and Practices recently. Its mostly straightforward as IoC containers go but one thing had me puzzled for a while as its not really documented or blogged as far as I can see; so I decided to blog it so hopefully others looking will stumble across this article

Lets start off with a simple example: I have two interfaces: IService and IRepository that live in the Interfaces class library

               1:
              public
              interface IService

               2: {

               3:
              void DoWork();

               4: }

               1:
              public
              interface IRepository

               2: {

               3:
              string GetStuff();

               4: }

 1:publicclass MyRepository
: IRepository

 2: {

 3:publicstring GetStuff()

 4: {

 5:return"TADA!!";

 6: }

 7: }

and MyService

 1:publicclass MyService
: IService

 2: {

 3:private IRepository
repository;

 4:  

 5:public MyService(IRepository
repository)

 6: {

 7:this.repository
= repository;

 8: }

 9:publicvoid DoWork()

 10: {

 11: Console.WriteLine(repository.GetStuff());

 12: }

 13: }

Notice that MyService needs an IRepository to do its work. Now the idea here is I’m going to wire this together via dependency injection and the Unity IoC container. So I have my application

 1:class Program

 2: {

 3:staticvoid Main(string[]
args)

 4: {

 5: UnityContainer
container = new UnityContainer();

 6: UnityConfigurationSection
section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

 7: section.Configure(container);

 8:  

 9: IService
svc = container.Resolve<IService>();

 10:  

 11: svc.DoWork();

 12: }

 13: }

Notice as we’re using IoC that there are no hard coded dependencies – everything is wired up via the container. However, there must be some information about how the interfaces map to concrete types and this is in the config file

 1:<configuration>

 2:<configSections>

 3:<sectionname="unity"type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,Microsoft.Practices.Unity.Configuration"/>

 4:</configSections>

 5:  

 6:<unity>

 7:<typeAliases>

 8:<!--
Lifetime Managers -->

 9:<typeAliasalias="singleton"type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager"/>

 10:  

 11:<!--
Interfaces -->

 12:<typeAliasalias="IService"type="Interfaces.IService,Interfaces"/>

 13:<typeAliasalias="IRepository"type="Interfaces.IRepository,Interfaces"/>

 14:  

 15:<!--
Implementations -->

 16:<typeAliasalias="service"type="Services.MyService,
Services"/>

 17:<typeAliasalias="repository"type="Services.MyRepository,
Services"/>

 18:  

 19:</typeAliases>

 20:<containers>

 21:<container>

 22:<types>

 23:<typetype="IService"mapTo="service">

 24:<lifetimetype="singleton"/>

 25:</type>

 26:<typetype="IRepository"mapTo="repository">

 27:<lifetimetype="singleton"/>

 28:</type>

 29:</types>

 30:</container>

 31:</containers>

 32:</unity>

 33:</configuration>

Now all of this works fine and is simple Unity stuff. We use constructor injection to get the repository implementation into the service constructor. However, I’ve decided the service needs a timeout that I will generally configure in the config file. However to make Unit Testing simple I’ll add another constructor to MyService so I can pass a specific timeout

 1:publicclass MyService
: IService

 2: {

 3:private IRepository
repository;

 4: TimeSpan
timeout;

 5:  

 6:public MyService(IRepository
repository, TimeSpan timeout)

 7: {

 8:this.timeout
= timeout;

 9: }

 10:

 11:public MyService(IRepository
repository)

 12: {

 13:this.repository
= repository;

 14: timeout
= GetTimeoutFromConfig();

 15: }

 16:  

 17:private TimeSpan
GetTimeoutFromConfig()

 18: {

 19:returndefault(TimeSpan);

 20: }

 21:  

 22:publicvoid DoWork()

 23: {

 24: Console.WriteLine(repository.GetStuff());

 25: }

 26: }

Now I try to run the application and I get a pretty ugly error

Now that’s weird – I have no types that take an Int32! This is caused by Unity’s default behavior where it will try to resolve on the constructor with the most parameters (on the basis that this one will have the most dependencies that can be injected). It tried to resolve the TimeSpan and so looks at the TimeSpan and tries to resolve its constructor which can take an Int32. I actually want to tell it to use a different constructor and I can do this in two ways: annotate the constructor I want to use with the [InjectionConstructor] attribute

 1: [InjectionConstructor]

 2:public MyService(IRepository
repository)

 3: {

 4:this.repository
= repository;

 5: timeout
= GetTimeoutFromConfig();

 6: }

But personally I don’t like this. It forces the services assembly to take a dependency on Unity and the service has knowledge about how its being constructed. What I really want to do is specify this in config. This isn’t very well documented from what I can see but what you do it specify the constructor and how to resolve the parameters against the type mapping in the config – i.e.

 1:<typetype="IService"mapTo="service">

 2:<lifetimetype="singleton"/>

 3:<constructor>

 4:<paramname="repository">

 5:<dependency/>

 6:</param>

 7:</constructor>

 8:</type>

Announced today at TechEd – Windows AppFabric is now available

http://blogs.msdn.com/b/endpoint/archive/2010/06/07/windows-server-appfabric-now-generally-available.aspx

The Visual Studio 2010 Power Tools have just been released. There’s all sorts of goodness in here: new flexible tab handling in the VS shell (vertical tab groups, tabs grouped by project, dropping of rarely used tabs, etc); a new searchable Add Reference dialog; new editor enhancements to make navigation easier and much more

I’ve been playing with it for the last couple of hours and its very neat. Of course I don’t use Resharper or CodeRush (I use too many machines I don’t control to become dependent on them) so some of these features may be available in those tools. But for me the power tools are a welcome addition to the IDE

Rock Solid Knowledge on iTunes is live! We’ve taken the feed to our free screencasts and they are now available through iTunes via the following link

http://itunes.apple.com/gb/podcast/rock-solid-knowledge-screencasts/id365244375

Now you can watch them on the move

Thanks to everyone who attended my sessions at DevWeek 2010. I’ve now uploaded the demos which you can find at the following locations

A Day of .NET 4.0 Demos

Windows Workflow Foundation 4.0 Demos

Creating WCF Services using WF4 Demos

I’ll be around for the rest of the conference so drop by for a chat at our developer clinic in the exhibition area

In my last post I pointed to a screencast I had recorded that showed how to create a custom message filter to plug your own logic into the WCF 4.0 Routing Service. However, the simple custom filter is only the start – you can actually take control of part of the routing table which allows you to make global decisions about which filters match a particular request. On that basis I have created another screencast that shows how to build one of these more complex custom filters. in this case I use the example of a round robin load balancer where you can use a file on the file system to indicate whether a specific endpoint should be considered part of the load balancing algorithm

You can find this last in the series of screencasts on the routing service, along with all the others here, on the Rock Solid Knowledge site

http://rocksolidknowledge.com/ScreenCasts.mvc

I’ve just uploaded a new screencast on the the Rock Solid Knowledge site. This one shows you how to plug your own routing logic into the new Routing Service that is part of WCF 4.0. It uses a custom message filter that can be used to supplement the existing set of filters such as matching on XPath and Action.

You can find the screencast (along with the previous ones in the series) here

http://www.rocksolidknowledge.com/ScreenCasts.mvc

Continuing my screencast series on the Routing Service in WCF 4.0, I have just uploaded one on Data Dependent Routing

You can get to the latest screencast (and all of the others) here http://rocksolidknowledge.com/ScreenCasts.mvc

I have just published my second screencast on one of the new features of WCF 4.0 – the Routing Service. This screencast focuses on enabling multicast and failover with the Routing Service

You can get to the screencast from here http://rocksolidknowledge.com/ScreenCasts.mvc

Thanks to everyone who attended my two sessions at BASTA! – another thoroughly enjoyable conference. I’ve uploaded the demos

What’s new in Workflow 4.0 – this includes the application with the rehosted designer

Building WCF services with Workflow 4.0

I my last post I showed that creating a custom composite activity (one that can have one or more children) requires deriving from NativeActivity. The Retry activity that I showed was fairly simple and in particular didn’t try to share data with its child. There appears to be a catch-22 in this situation when it comes to overriding CacheMetadata: if I add a Variable to the metadata (AddVariable) then it can be used exclusively by its children – i.e. the activity itself can’t manipulate the state; if I add a variable as implementation data to the metadata (AddImplementationVariable) then the children cant see it as its seen as purely used for this activities implementation. How then do we create data that can be both manipulated by the activity and accessed by the parent?

The secret to achieving this is a feature called ActivityAction - Matt Winkler talks about it here. The idea is that I can bind an activity to one or more parent defined pieces of data then schedule the activity where it will have access to the data. Its probably best to show this with an example so I have written a ForEachFile activity that you give a directory and then it passes its child the file name of each file in the directory in turn. I’ll show the code in its entirety and then walk through each piece in turn

               1: [ContentProperty("Body")]

               2: [Designer(typeof(ForEachFileDesigner))]

               3:
              public
              class ForEachFile
: NativeActivity, IActivityTemplateFactory

               4: {

               5:
              public InArgument<string>
Directory { get; set; }

               6:  

               7: [Browsable(false)]

               8:
              public ActivityAction<string>
Body { get; set; }

               9:  

               10:
              private Variable<IEnumerator<FileInfo>>
files = new Variable<IEnumerator<FileInfo>>("files");

               11:  

               12:
              protected
              override
              void CacheMetadata(NativeActivityMetadata
metadata)

               13: {

               14: metadata.AddDelegate(Body);

               15:  

               16: RuntimeArgument
arg = new RuntimeArgument("Directory", typeof(string),
ArgumentDirection.In);

               17: metadata.AddArgument(arg);

               18:  

               19: metadata.AddImplementationVariable(files);

               20: }

               21:
              protected
              override
              void Execute(NativeActivityContext
context)

               22: {

               23: DirectoryInfo
dir = new DirectoryInfo(Directory.Get(context));

               24:  

               25: IEnumerable<FileInfo>
fileEnum = dir.GetFiles();

               26: IEnumerator<FileInfo>
fileList = fileEnum.GetEnumerator();

               27: files.Set(context,
fileList);

               28:  

               29:
              bool more
= fileList.MoveNext();

               30:  

               31:
              if (more)

               32: {

               33: context.ScheduleAction<string>(Body,
fileList.Current.FullName, OnBodyComplete);

               34: }

               35: }

               36:  

               37:
              private
              void OnBodyComplete(
NativeActivityContext context, ActivityInstance completedInstance)

               38: {

               39: IEnumerator<FileInfo>
fileList = files.Get(context);

               40:
              bool more
= fileList.MoveNext();

               41:  

               42:
              if (more)

               43: {

               44: context.ScheduleAction<string>(Body,
fileList.Current.FullName, OnBodyComplete);

               45: }

               46:
            

               47: }

               48:  

               49:
              #region IActivityTemplateFactory
Members

               50:
              public Activity
Create(DependencyObject target)

               51: {

               52: var
fef = new ForEachFile();

               53: var
aa = new ActivityAction<string>();

               54: var
da = new DelegateInArgument<string>();

               55: da.Name
= "item";

               56:  

               57: fef.Body
= aa;

               58: aa.Argument
= da;

               59:  

               60:
              return fef;

               61: }

               62:
              #endregion
            

               63: }

Ok lets start with the core functionality then we’ll look at each of the pieces that help make this fully usable. As you can see the class derives from NativeActivity and overrides CacheMetadata and Execute – we’ll look at their implementations in a minute. There are three member variables in the class: the InArgument<string> for the directory; an implementation variable to hold the iterator as we move through the files in the directory; the all important ActivityAction<string> which we will use to pass the current file name to the child activity.

Lets look at CacheMetadata more closely. Because we want to do interesting things with some of the state the default implementation won’t work so we override it. As we don’t call the base class version we need to specify how we use all of the state. We add the ActivityAction as a delegate, we bind the Directory argument to a RuntimeArgument and specify the iterator as an implementation variable – we don’t want the child activity to have access to that directly.

Next lets look at Execute. The first couple of lines are nothing unusual – we get the directory and get hold of the list of files. Now we have to store the retrieved iterator in the implementation variable, fileList. We move to the first file in the iteration, if it returns false the list was empty so as long as MoveNext returned true we want to schedule the child activity passing the current file. To do this we use the ScheduleAction<T> member on the context. However, because we’re going to process each one sequentially, we also need to know when the child is finished so we pass a completion callback, OnBodyComplete.

Now in OnBodyComplete we simply get the iterator, move to the next item in the iteration and as long as we’re not finished iterating re-schedule the child again passing the new item in the iteration.

That really is the “functional” part of the activity – everything else is there to support the designer. So why does the designer need help? Well lets look at what we would have to do to build this activity correctly if we were going to execute it from main

               1: Activity
workflow = new ForEachFile

               2: {

               3: Body
= new ActivityAction<string>

               4: {

               5: Argument
= new DelegateInArgument<string>

               6: {

               7: Name
= "item",

               8: },

               9: Handler
= new WriteLine

               10: {

               11: Text
= new VisualBasicValue<string>("item")

               12: }

               13: },

               14: Directory
= @"c:\windows"

               15: };

As you can see, its not a matter of simply creating the ForEachFile, we have to build the internal structure too – something needs to create that structure for the designer - this is the point of IActivityTemplateFactory. When you drag an activity on to the design surface normally it just creates the XAML for that activity. However, before it does that it does a speculative cast for IActivityTemplateFactory and if the activity supports that it calls the interface’s Create method instead and serializes the resulting activity to XAML.

So going back to the ForEachFile activity, you can see it implements IActivityTemplateFactory and therefore, as far as the designer is concerned, this is the interesting functionality – lets take a look at the Create method.We create the ForEachFile and wire an ActivityAction<string> to its Body property. ActivityAction<string> needs a slot to store the data to be presented to the child activity. This is modelled by DelegateArgument<string> and this gets wired to the Argument member of the ActvityAction. We also name the argument as we want a default name for the state so the child activity can use it. Notice, however, we don’t specify the child activity itself (it would be a pretty useless composite if we hard coded this). The child will be placed on the Handler property of the ActivityAction but that will be done in the ActivityDesigner using data binding.

Before we look at the designer lets highlight a couple of “polishing” features of the code: the class declared a ContentProperty via an attribute – that just makes the XAML parsing cleaner as the child doesn’t need to be specified using property element syntax; the Body is set to non-browsable – we don’t want the activities user to try to set this value in the property grid.

OK on to the designer. If you read my previous article there are a couple of new things here. Lets look at the markup – again there is no special code in the code behind file, everything is achieved using data binding

               1:
              <
              sap:ActivityDesigner
              x:Class
              ="ActivityLib.ForEachFileDesigner"
            

               2:
              xmlns
              ="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            

               3:
              xmlns:x
              ="http://schemas.microsoft.com/winfx/2006/xaml"
            

               4:
              xmlns:s
              ="clr-namespace:System;assembly=mscorlib"
            

               5:
              xmlns:conv
              ="clr-namespace:System.Activities.Presentation.Converters;assembly=System.Activities.Presentation"
            

               6:
              xmlns:sap
              ="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
            

               7:
              xmlns:sapv
              ="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation"
            

               8:
              xmlns:me
              ="clr-namespace:ActivityLib"
              >
            

               9:
              <
              sap:ActivityDesigner.Resources
              >
            

               10:
              <
              conv:ArgumentToExpressionConverter
              x:Key
              ="expressionConverter"
              />
            

               11:
              </
              sap:ActivityDesigner.Resources
              >
            

               12:  

               13:
              <
              Grid
              >
            

               14:
              <
              Grid.RowDefinitions
              >
            

               15:
              <
              RowDefinition
              Height
              ="Auto"
              />
            

               16:
              <
              RowDefinition
              Height
              ="*"
              />
            

               17:
              </
              Grid.RowDefinitions
              >
            

               18:
            

               19:
              <
              StackPanel
              Orientation
              ="Horizontal"
              Margin
              ="2"
              >
            

               20:
              <
              TextBlock
              Text
              ="For
each file "
              />
            

               21:
              <
              TextBox
              Text
              ="{Binding
ModelItem.Body.Argument.Name}"
              MinWidth
              ="50"
              />
            

               22:
              <
              TextBlock
              Text
              ="
in "
              />
            

               23:
              <
              sapv:ExpressionTextBox
              Expression
              ="{Binding
Path=ModelItem.Directory, Converter={StaticResource expressionConverter}}"
            

               24:
              ExpressionType
              ="s:String"
            

               25:
              OwnerActivity
              ="{Binding
ModelItem}"
              />
            

               26:
              </
              StackPanel
              >
            

               27:
              <
              sap:WorkflowItemPresenter
              Item
              ="{Binding
ModelItem.Body.Handler}"
            

               28:
              HintText
              ="Drop
activity"
            

               29:
              Grid.Row="1"Margin="6"/>

               30:  

               31:
              </
              Grid
              >
            

               32:
            

               33:
              </
              sap:ActivityDesigner
              >
            

Here’s what this looks like in the designer

So the TextBox at line 21 displays the argument name that our IActivityTemplateFactory implementation set up. The ExpressionTextBox is bound to the directory name but allows VB.NET expressions to be used. The WorkflowItemPresenter is bound to the Handler property of the Body ActivityAction, This designer is then associated with the activity using the [Designer] attribute.

So as you can see, ActivityAction and IActivityTemplateFactory work together to allow us to build rich composite activities with design time support