Durable Task Framework: C# orchestrations without a Microsoft support ticket

What DTFx solves: resumable workflows written as ordinary C#

Durable Task Framework is a library for writing long running persistent workflows, which the project calls orchestrations, in C# using ordinary async and await constructs. An orchestration is a method that survives process restarts, machine failures and long idle periods without losing its position.

The programming model lives in the DurableTask.Core package. What makes it usable rather than an academic exercise is that the workflow shape stays readable: you write a method, you await calls to other activities, and the framework persists state between steps. The orchestration primitives are described as similar to those in the modern Durable Task SDKs, which matters because it means the concepts transfer even if the package does not.

The audience is a .NET team that needs durable orchestration without moving its execution model to a serverless function host. That is a real and specific group: shops with existing worker processes, on-premises or VM based deployments, and applications where functions are not a natural fit.

Documentation for the repository sits in the docs folder rather than a docs site, and the samples directory holds four sets: DurableTask.Samples, Correlation.Samples, DistributedTraceSample and ManagedIdentitySample. The last two tell you something about what breaks in production, distributed tracing and identity being the two concerns teams hit after the happy path works.

The backend table is where the real decision gets made

Since v2.x, persistence is pluggable and each backend ships as its own NuGet package. The repository states that the latest version of all packages is signed and available from nuget.org. The list is not decorative, because the choice determines both your failure modes and whether Microsoft is still working on it.

Service Bus keeps orchestration messages and runtime state in Service Bus queues with tracking state in Azure Storage. The project's description calls its strength maturity and transactional consistency, and its status production ready but not actively maintained. It is also the package that keeps shipping: DurableTask.ServiceBus v5.0.0 came out on 2026-10-13 and v4.0.4 on 2026-10-02.

Azure Storage keeps everything in queues, tables and blobs, and is described as minimal in service dependencies, efficient, and feature rich. It is the backend available for Durable Functions, and it is listed as production ready and actively maintained.

Service Fabric stores state in Azure Service Fabric Reliable Collections, which is the reason to pick it: if you already host on Service Fabric you avoid taking on an external state store at all.

Netherite is the research line, developed by Microsoft Research, keeping state in Azure Event Hubs and Azure Page Blobs using FASTER technology. SQL Server keeps state in indexed tables and stored procedures for direct interaction, which is the most inspectable option when your operations people know how to open a database.

And there is a trap. DurableTask.Emulator is an in-memory store for testing only, explicitly not designed or recommended for production workloads, and not actively maintained. The README separately warns that it is not the same as the Durable Task Scheduler emulator, which is a supported local development tool.

Reading the support posture before you commit

The most important paragraph in this repository is the notice at the top, and it deserves to be quoted rather than paraphrased. DTFx is described as a community maintained open source project that is actively used in production by many teams, including engineering teams within Microsoft, but that does not come with official Microsoft support. The consequence is stated plainly: you cannot open a Microsoft support ticket for DTFx issues, and bugs and feature requests are addressed on a best effort basis.

That is a different thing from abandonment. The repository is not archived, and the last push was on 2026-10-16. DurableTask.Core v3.10.0 shipped on 2026-09-22, ahead of the Service Bus v5 release. So the code is moving; what is missing is a contract about what happens when you report a problem at 02:00 during an incident.

The project also names its own successors, which is unusual and useful. For a new project, or when official support is a requirement, it recommends Durable Functions for serverless orchestration on Azure Functions, or the Durable Task SDKs with the Durable Task Scheduler backend for self hosted orchestration on any compute platform, naming Azure Container Apps, AKS and VMs as examples. Both routes come with the ability to open a support ticket.

A second cost the README names explicitly: DTFx requires you to manage hosting and operational infrastructure yourself. There is no platform underneath it doing the patching.

Setting up a local project without inventing install steps

The repository does not give a dotnet new template or a package install line, so there is nothing here to copy for a first run. What it does say is that the programming model is contained in the DurableTask.Core package and that every backend is a separate NuGet package, signed and downloadable from nuget.org. That is enough to describe the shape of a first project honestly: reference the core package, reference exactly one backend package, register a persistence client for that backend, and write an orchestrator plus the activities it calls.

For local runs the repository points at the emulator entry, with the caveat above attached. Treat that as a test harness: it is in memory, so state does not survive the process, which is precisely the property durable orchestration exists to prevent.

Repository structure suggests how the work is organised. DurableTask.sln is the solution, with Directory.Build.targets and Directory.Packages.props for central build and package version settings, which is the pattern to expect in a repository with this many packages. Source lives in src/, tests in both Test/ and test/, tooling in tools/, engineering scripts in eng/, and samples in samples/. There is also SECURITY.md and es-metadata.yml, and a NuGet.config in the root, so package sources are pinned by the repository rather than left to machine defaults.

The project has adopted the Microsoft Open Source Code of Conduct.

Failure modes worth planning around

The first limitation is operational rather than technical. Because DTFx runs on infrastructure you own, the reliability of your orchestrations is bounded by the reliability of the machines and the store underneath them, and by whoever is on call. There is no platform team absorbing it.

The second is backend drift. The table itself shows two packages with no active development: Service Bus, which is the most mature and most widely deployed option, and the Emulator. A team that picks Service Bus for its transactional consistency is choosing the store Microsoft has stopped developing, and the mitigation is that the package still ships releases, with v5.0.0 landing days before the last push.

The third is the naming trap around emulators, which is the kind of mistake that produces an environment where nothing is durable and nobody noticed. DurableTask.Emulator and the Durable Task Scheduler emulator share a word and nothing else, and the README calls this out explicitly, which means people have confused them.

The fourth is version spread. Core at v3.10.0 alongside Service Bus at v5.0.0 means the major versions across packages do not move together. Planning a version matrix is part of adopting this library, and the central package management files in the repository help inside the repository but not across yours.

How Durable Functions and the Durable Task SDKs differ in approach

The alternatives named by the project are not worse versions of the same thing. They differ in where the orchestration runtime lives and who operates it.

Durable Functions runs orchestration as part of Azure Functions. The difference in approach is that you give up the ability to run the orchestrator as a plain library inside a worker process you already operate, and you gain a managed runtime and a support contract.

The Durable Task SDKs with the Durable Task Scheduler backend keep the self hosted model. Orchestration runs on self-hosted compute, with Azure Container Apps, AKS and VMs listed as examples. That is the closest thing to DTFx with an official contract behind it, and it is the route to compare against if hosting flexibility is what you are actually after.

The other contrast is the SDK layer.

For an existing DTFx deployment the migration question is not urgent, since the framework is still maintained and used in production. For a greenfield project, the project's own recommendation is the clearer guide.

Editorial conclusion

Stay on Durable Task Framework if you already run DTFx in production and want to keep a proven backend while the Service Bus package reaches its v5 line, or if you specifically need the Service Fabric Reliable Collections store that nothing else in the table covers. Do not start a new project on it, because the repository itself recommends Durable Functions or the Durable Task SDKs with the Durable Task Scheduler backend when official support matters, and hosting and operations are yours to run. Verify first which backend you are on: DurableTask.ServiceBus is described as production ready but not actively maintained, and DurableTask.Emulator is an in-memory store for testing only that is not the same thing as the Durable Task Scheduler emulator.

Frequently asked questions

Official sources

1. Azure/durabletask on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases