A port of the Windows Workflow Foundation (WF) runtime to the .NET Standard.

This is not an official Microsoft release of WF on .NET Core. Core WF is a derivative work of Microsoft's copyrighted Windows Workflow Foundation.

To add this library to your project, use the NuGet package. ETW tracking provider is in a separate package here.

The Windows Workflow Foundation (WF) handles the long-running work of many companies. It powers SharePoint workflows, PowerShell workflows, Team Foundation Server build processes, and many applications in all types of businesses. As more developers look into adopting .NET Core, some are asking if WF will be officially ported. This project only ports the WF runtime and ETW tracking provider to the .NET Standard. But much more work is needed before it can substitute for the .NET Framework version.

The problem with porting is that WF integrates heavily with other features of the .NET Framework that are not being ported to .NET Core. The most sizable features are:

• XAML - replaced with Portable.Xaml
• VB/C# expression compilation
• WCF services
• WPF - for the WF designer

None of these components are trivial. I'll do my best to describe the options for each one.

A significant portion of XAML workflows use expressions. Expressions can be written in either C# or VB. The TextExpressionCompiler class is responsible for parsing expression strings into activities that the WF runtime can execute. TextExpressionCompiler will use the Microsoft.VisualBasic libraries for VB expressions and the XamlBuildTask MSBuild task for C# expressions. The VB compiler has both managed and native components and operates at build time. The C# compiler is basically just hooking in csc.exe during build time to generate a partial class.

In the .NET Framework, it's not possible to take a dependency on the Roslyn libraries because those are external dependencies. A much better way to handle expressions is to use Roslyn to interpret the expressions and turn them into activities. This could be done either at runtime or build time (perhaps with a .NET SDK tool). The third task for the community is to write a Roslyn module that can turn an expression tree into an activity tree (issue link). It would also need to be integrated with the XAML parser.

WF services can host workflows via web services. The built-in host is a subclass of ServiceHost called WorkflowServiceHost, which is part of the System.ServiceModel.Activities library. ServiceHost hosts WCF services. In order to allow existing customers to port their applications over to .NET Core, we would need the WCF team to implement WCF server-side. Please chime in on this issue.

Many WF users have asked for a REST implementation for WF. This was not really possible with the .NET Framework version since it would need to use Web API, which is not part of the .NET Framework. With .NET Core, we can take this dependency (preferably from a separate assembly). The tricky parts are how to handle sending and receiving messages. With the .NET Framework, you could generate a WCF client for a WF service. There would need to be a substitute for this that works with REST. Unfortunately, anyone porting an existing application that uses WorkflowServiceHost will also have to change their clients to talk to the REST WF service. An optional task then is to create a REST service host for WF (issue link).

The designer for WF workflows is not just a part of Visual Studio. The entire code is actually in the .NET Framework. This allows developers to "re-host" the WF designer in their own applications. A number of software vendors do this and have the WF designer ingrained into their product. Since there is no UI in .NET Core, besides web UI anyway, we won't be able to port the designer.

There has been a long-standing request to build a HTML-based workflow designer and was attempted a few times. Some other products like Node-RED have an excellent HTML designer already. One path is to make a brand new HTML designer for WF. Another is to try and take advantage of one that already exists.

This is where another consideration comes into play. There is an industry standard for defining workflows called BPML. If there was a parser that could convert BPML to activity objects or XAML, then we wouldn't need to create a new designer specifically for WF. We could instead use an existing designer that can produce BPML. That's assuming they're compatible, of course.

This leaves us with two more possible tasks for the community: create a HTML workflow designer using ASP.NET Core or create a BPML to WF converter.

The .NET Framework shipped with the SQL Workflow Instance Store (SWIS). This should be a straightforward port to the .NET Standard (issue link).

It is possible to implement your own instance store by implementing the abstract InstanceStore class. There are other implementations out there and it would be great to port them.