CoreWF, the Windows Workflow Foundation runtime running on .NET 6

What the port is, and what it is not

CoreWF is a port of the Windows Workflow Foundation runtime to .NET 6, and the project is explicit about its own status in one sentence: this is not an official Microsoft release of WF on .NET 6, and CoreWF is a derivative work of Microsoft's copyrighted Windows Workflow Foundation. The licence on the port itself is MIT. That combination is the first thing to understand about the project, because it shapes what you can do with it. The runtime code is permissively licensed and you can use it commercially, but the underlying intellectual property is Microsoft's, and the relationship between the two is a derivative work claim rather than a clean-room reimplementation. A reader assessing the project should hold both facts at once: the code is open and usable, and it is a derivative of a proprietary framework. The primary language is C#, the default branch is develop, and the last push to the repository was on 2026-10-15, so the port is being maintained.

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

Activities and workflows, and why the XML analogy holds

The project documentation gives a concise model. Workflows are multi-step processes composed of activities, and activities are single-purpose elements that can be composed of other activities. A workflow has only one root activity in the same way that an XML document has only one root element. That analogy is not decorative, because it is what makes XAML workflows possible. The relationship between an activity and a composite activity mirrors the relationship between an element and a child element, so the tree structure, the serialisation and the designer all fall out of the same idea. In code, the composition is a sequence with a list of child activities, and the example shows a sequence containing a single write-line activity with the text set on it. The model is small enough to read in a minute, which is the point: the complexity in workflow systems is rarely in the model, it is in the runtime around it.

var helloWorldActivity = new Sequence()
{
    Activities =
    {
        new WriteLine
        {
            Text = "Hello World!"
        }
    }
};

Running a workflow is one line

Once you have an activity tree, running it is a single call through the workflow invoker, and the example is exactly that. The interesting consequence is that the same workflow can be written in code, run in code, and serialised, and that the code path and the XAML path converge on the same runtime object. The XAML route loads a workflow through the activity XAML services, reading from a string reader, and then invokes it the same way. So the choice between writing a workflow as C# and writing it as XAML is a choice about authoring ergonomics and about who can edit the workflow later, not about what the runtime does with it. For a team that has people editing workflows directly, that difference matters, and it is the difference CoreWF preserves from the original framework rather than inventing something new.

System.Activities.WorkflowInvoker.Invoke(helloWorldActivity);

XAML workflows, and the designer that is not there

Because the activity model mirrors XML, it is possible to write workflows in XAML, an extension of XML. The example shows the same hello world workflow expressed as an Activity element containing a Sequence with a WriteLine, with the XAML namespaces declared inline. The XAML workflow can then be loaded in CoreWF through the activity XAML services, again with a string reader and a workflow invoker call. The significant limitation is stated plainly: the WF in the .NET Framework includes a visual, drag-and-drop designer for workflows that produces XAML, and that designer experience is not part of CoreWF, though the XAML the designer produces can be run in CoreWF with some limitations. The WF designer itself is available in Visual Studio 2019 by enabling the Windows Workflow Foundation individual component in the installer. The practical reading is that you can keep an existing designer-based workflow estate running, but you will not get the visual editor back on .NET 6.

<Activity 
 x:Class="WorkflowConsoleApplication1.HelloWorld"
 xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <Sequence>
    <WriteLine Text="Hello World!" />
  </Sequence>
</Activity>

Target frameworks, and the copy of System.Xaml that makes it work

CoreWF targets .NET 6 and .NET 6 Windows. The .NET Windows target uses the System.Xaml included in the .NET Desktop Runtime, and to use CoreWF on non-Windows runtimes you use the portable .NET 6 target, which is possible because CoreWF includes a copy of the System.Xaml code. That single design decision is what makes the port viable at all, and it is worth understanding the cost of. The Windows target is the clean one, because the platform supplies the XAML implementation. Everywhere else, the project carries System.Xaml itself, which means a copy of a Microsoft-implementation library travels with your application, and you inherit its behaviour and its quirks rather than a platform guarantee. The project also warns that the designer-produced XAML runs only with some limitations, so the portable path and the XAML path are the two places where fidelity to the original is imperfect.

CoreWF targets .NET 6 and .NET 6 Windows.

How you consume it, and what the project does not give you

Consumption is a NuGet package, and the package name is worth noting because it is not the repository name: to add the library to your project you use the UiPath.Workflow NuGet package. Debugging is supported through Source Link, with the preview builds hosted on an internal MyGet feed, which tells you the project has a continuous integration pipeline producing snapshot packages for contributors. The contributing guide is the entry point for people who want to help, and the project has adopted the .NET Foundation code of conduct. The repository layout is small and says something about the scope: a src/ directory holding the port, an azure-pipelines.yaml for the build, a .pipelines/ directory, CODEOWNERS, and the WfDesignerHelloWorld.png screenshot of the original designer. What you do not get is the designer, the packaging for the .NET Framework, and any release cadence on GitHub, since the repository has no GitHub releases at all and the version you consume comes from NuGet.

UiPath.Workflow

Where it fits, and what to check first

The honest scope of CoreWF is narrow and specific: it is for teams that already have workflows, expressed in WF terms, that need to run somewhere the .NET Framework runtime is not an option. If that is your situation, the port removes a large obstacle, and the activity model, the workflow invoker and the XAML format all carry over rather than being reworked. If it is not, the reasons not to adopt it are worth stating plainly. There is no visual designer, so a workflow estate that depends on non-technical people editing flows by dragging boxes loses its tooling. There are no GitHub releases, so version tracking lives in NuGet and the MyGet preview feed. And the artefact is a derivative work of a proprietary framework, so anyone doing a legal review will want to read the licence file and the derivative work notice together rather than take the MIT badge as the whole story. The two checks to run first are technical and mundane: confirm your workflows are code or XAML, and confirm you can live with the .NET 6 target the project names.

The designer experience is not part of CoreWF but the XAML produced by
the designer can be run in CoreWF (with some limitations).

Editorial conclusion

Adopt CoreWF if you have an existing investment in Windows Workflow Foundation semantics and need to run those workflows somewhere the .NET Framework runtime is not available, and skip it if you are starting a new long-running process system, because you would be adopting a runtime with no designer, no releases and a large surface area. Verify three things before you commit: that your workflows are code or XAML rather than designer artefacts, since the designer experience is not part of CoreWF and the XAML it produces runs only with limitations; that you can accept the .NET 6 target, which is what the project says it targets; and the licensing terms, because CoreWF is a derivative work of Microsoft's copyrighted Windows Workflow Foundation even though the port itself is MIT licensed.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. UiPath/CoreWF on GitHub