(WF4.5) Enabling new .Net framework 4.5 features in your rehosted designer application

  • Article

[Minor disclaimer: content in this post is based upon a non-final release candidate build of .Net 4.5]

The workflow designer team had two slightly conflicting goals to tackle in .Net 4.5.

Goal one: Make Workflow Designer more awesome for everyone in .Net 4.5. It should be easier to use, it should look better, and it should let you do some cool new things that will just never work in 4.0.

Goal two: Be completely backwards compatible for applications build on .Net 4.0.

This second goal is a very important one because .Net 4.5 is an in-place upgrade. Basically, as soon as you have installed .Net 4.5 on your machine, there is no ‘separate’ .Net 4.0 on your machine. Every app that was built to use .Net 4.0 will automatically be loading .Net 4.5 assemblies once you make the upgrade. (And it doesn’t matter why you made the upgrade – you might have needed to upgrade in order to install new fancy application X from 3rd party developer Y, and suddenly your workflow designer app stops working – who will you call?)

So the designer team made a decision, and of the two goals, you’ll see the second goal landed on top. So while there are a lot of nice usability features in .Net 4.5 and none of them are turned on by default. They are all opt-in. And so you ask:
How?

Opting in, by using DesignerConfigurationService

In order to opt in to 4.5 features, and likely future framework features (5.0??) we must take advantage of a new Service provided by the workflow designer’s EditingContext (at some point I might even get around to providing a 4.5 comparison version of services available as in this post - not today though – so feel free to beat me to that punch).  It’s called DesignerConfigurationService.

The first thing you want to do with DesignerConfigurationService is turn on all the good stuff!

Here’s a small code snippet enabling all of the little usability enhancements built into the 4.5 version of the rehostable workflow designer. A good time to call this would be before loading a root model item.

    DesignerConfigurationService configService =

        designer.Context.Services.GetRequiredService<DesignerConfigurationService>();

    configService.AnnotationEnabled = true; /* maybe, see explanation of TargetFrameworkName*/

    configService.AutoConnectEnabled = true;

    configService.AutoSplitEnabled = true;

    configService.AutoSurroundWithSequenceEnabled = true;

    configService.BackgroundValidationEnabled = true;

    configService.MultipleItemsContextMenuEnabled = true;

    configService.MultipleItemsDragDropEnabled = true;

    configService.NamespaceConversionEnabled = true;

    configService.PanModeEnabled = true;

    configService.RubberBandSelectionEnabled = true;

The second and third things you probably want to do with DesignerConfigurationService is choose a XAML loading security setting, and identity the target framework that your workflow is intended to run on…

MAYBE like this (emphasis on maybe)

    configService.LoadingFromUntrustedSourceEnabled = false;

    configService.TargetFrameworkName = new FrameworkName(".NETFramework,Version=v4.5");

So what? What do these do?

Well, I haven’t any real source of info on LoadingFromUntrustedSoruceEnabled (the msdn docs are currently no help), but I am making a wild guess that it is something to do with whether you want to enable loading XAML files from ‘untrusted’ places like network shares. Sort of like the powershell set-executionpolicy setting.

Anyway I think the second setting is by far the more interesting of the two – it actually lets you be specific about what target framework you wish your workflow designer to be designing for. Now at the current date, you have only three realistic choices for this setting, and they are:

  1. new FrameworkName(".NETFramework,Version=v4.0");
  2. new FrameworkName(".NETFramework,Version=v4.0,Profile=Client");
  3. new FrameworkName(".NETFramework,Version=v4.5");

Selecting a target framework has various interesting effects, some of which you might not guess.

For instance setting v4.5…

  • is actually a secret requirement for setting Annotation.Enabled = true to work! (because annotation will save stuff in the XAML which only a 4.5 framework XAML loader will understand)
  • makes FlowDecision display names editable in the designer
  • in theory, enables custom language expression editors including C# expression editor - but you must provide the editor – C# editor is not built-in (sadly)

For instance setting v4.0…

  • enables a ‘best-effort’ load of XAML files which contain features found only in v4.5 framework so that later when you save the XAML you don’t accidentally save in any 4.5 features.

[Does setting a Client profile in the target framework actually do anything for a rehosted app? I don’t know!]