This package provides a C# based durable task framework for writing long running applications.
ServiceBus , Azure , Task , Durable , Orchestration , Workflow , Activity , Reliable
Install-Package Microsoft.Azure.DurableTask.Emulator -Version 2.2.5
The vnext branch has now been merged into master with the follwing PR: https://github.com/Azure/durabletask/pull/104
This merge contains some major refactoring primarily around building a provider model that decouples the core framework from Service Bus. As a result there are breaking changes both in terms of APIs as well as wire format.
To ugprade you will have to drop and recreate durable task artifacts. More details in an upcoming wiki entry soon.
Old master code will always be available in the rel/v1 branch.
Note that the framework is now published as multiple nuget packages bumping up the major version number to 2.x.x.x. Available at:
This framework allows users to write long running persistent workflows in C# using the async/await capabilities.
It is used heavily within various teams at Microsoft to reliably orchestrate long running provisioning, monitoring and management operations. The orchestrations scale out linearly by simply adding more worker machines.
By open sourcing this project we hope to give the community a very cost-effective alternative to heavy duty workflow systems. We also hope to build an ecosystem of providers and activities around this simple yet incredibly powerful framework.
The framework binaries are available as a NuGet package at: https://www.nuget.org/packages/DurableTask
To run unit tests, you must specify your Service Bus connection string for the tests to use. You can do this via the ServiceBusConnectionString app.config value in the test project, or by defining a DurableTaskTestServiceBusConnectionString environment variable. The benefit of the environment variable is that no temporary source changes are required.
Unit tests also require Azure Storage Emulator, so make sure it's installed and running.
Note: While it's possible to use in tests a real Azure Storage account it is highly not recomended to do so because many tests will fail with a 409 Conflict error. This is because tests delete and quickly recreate the same storage tables, and Azure Storage doesn't do well in these conditions. If you really want to change Azure Storage connection string you can do so via the StorageConnectionString app.config value in the test project, or by defining a DurableTaskTestStorageConnectionString environment variable.
The associated wiki contains more details about the framework: https://github.com/Azure/durabletask/wiki
We could have spent a lot of time cleaning up the code and teasing apart various layers but we opted for shipping this earlier and cleaning up post-commit. Consequently there are a lot of TODOs :)
The community is welcome to take a stab and send pull requests on these items (and more):
Please post feedback/comments at gitter.