Skip to content

Releases: temporalio/sdk-dotnet

1.13.0

02 Apr 17:09
a733589

Choose a tag to compare

What's Changed

SDK Core Update

Updated from temporalio/sdk-core@c6b601d to temporalio/sdk-core@24703da

Full Changelog: 1.12.0...1.13.0

1.12.0

18 Mar 15:50
21ab4b0

Choose a tag to compare

Highlights

💥 Standalone Activities (Experimental, Pre-Release)

Activities can now be started directly from a ITemporalClient, independent of any workflow.

As part of this change, some ISerializationContext implementation properties have been made nullable or obsolete.

See https://docs.temporal.io/standalone-activity and #609 for details.

💥 Nexus Changes (Pre-Release)

Rename Nexus Operation Classes Inside a Workflow

In preparation for Stand Alone Nexus Operations we renamed the Nexus classes inside a workflow to help distinguish them from future client classes. All classes are now prefixed by NexusWorkflow instead of just Nexus .

See #619 for details.

Standardize Nexus Operation Input Argument Deserialization

This release changes some of the behavior when a handler fails to deserialize the input arguments for a Nexus operation. Previously the SDK would treat any failure as always retry-able. Now the SDK will treat failures at the payload converter level as non-retryable. This aligns the .NET SDK with the other Temporal SDKs.

See #615 for details.

What's Changed

SDK Core Update

Updated from temporalio/sdk-core@372b270 to temporalio/sdk-core@c6b601d

New Contributors

Full Changelog: 1.11.1...1.12.0

1.11.1

18 Feb 18:56
89a608f

Choose a tag to compare

Highlights

  • Fixed the poller autoscaler to exponentially backoff for ResourceExhausted and other gRPC errors. See PRs temporalio/sdk-core#1110 and temporalio/sdk-core#1111 for more details.
  • Fixed local activity backoff to prevent double encoding of headers. See #611 for more details.

What's Changed

SDK Core Update

Updated from temporalio/sdk-core@372b270 to temporalio/sdk-core@12c656f

Full Changelog: 1.11.0...1.11.1

1.11.0

11 Feb 19:57
392e93e

Choose a tag to compare

Highlights

Linux musl arm64 Support

The .NET SDK now supports running on Linux musl arm64 installations. See PR #598 for more details.

Client Environment Configuration General Availability

The client environment configuration feature is no longer experimental and is now generally available. See PR #605 for more details.

Deployment-Based Worker Versioning General Availability

The deployment-based worker versioning feature is no longer experimental and is now generally available. The older style worker deployment APIs have been marked as obsolete. See PR #605 and documentation at https://docs.temporal.io/worker-deployments for more details.

What's Changed

  • Fix: load TLS certs from path if specified by @THardy98 in #596
  • chore(RID): add musl-arm-64 RID build support #597 by @tomflenner in #598
  • Fix TemporalWorker::ExecuteAsync(Func) swallowing exceptions by @adeal in #600
  • Make search attribute type more lenient when parsing by @cretz in #604
  • Remove experimental warning for worker deployment versioning and envconfig by @THardy98 in #605
  • Add IsReplayingHistoryEvents to allow logging in queries and validators by @cretz in #594
  • Update version to 1.11.0 by @jmaeagle99 in #607

New Contributors

Full Changelog: 1.10.0...1.11.0

1.10.0

13 Jan 17:04
bdf68ba

Choose a tag to compare

Highlights

Plugins

Plugins are a new way of providing easy configuration of workers and clients. See PR #548 and the plugins guide for more details.

Windows arm64 Support

The .NET SDK now supports running on Windows arm64 machines. See PR #541 for more details.

💥 BREAKING BEHAVIOR CHANGE - TLS is assumed if API key is set.

When TemporalConnectionOptions.ApiKey is set, TLS is automatically enabled. To explicitly disable TLS when an API key is provided, set the TemporalConnectionOptions.Tls property to a TlsOption instance with Disabled set to true. See PR #567 for more details.

💥 MINOR BREAKING CHANGE - Core bridge library rename

The core bridge library has been renamed to temporalio_sdk_core_c_bridge.dll on Windows, libtemporalio_sdk_core_c_bridge.dylib on MacOS, and libtemporalio_sdk_core_c_bridge.so on Linux. See PR #570 for more details.

💥 MINOR BREAKING CHANGE - ClientEnvConfig namespace change

Moved ClientEnvConfig from Temporalio.Client.EnvConfig to Temporalio.Common.EnvConfig. See PR #545 for more details.

What's Changed

SDK Core Update

Updated from temporalio/sdk-core@079d1f3 to temporalio/sdk-core@372b270

Read more

1.9.0

26 Sep 13:49
d4a0765

Choose a tag to compare

Get from NuGet and read the README

Highlights

Environment Configuration Support (experimental)

Users can now use Temporalio.Client.EnvConfig.ClientEnvConfig to load environment configuration from config files or environment variables. This is the same configuration approach that can be used across other SDKs and CLI. See https://docs.temporal.io/develop/environment-configuration for more details.

⚠️ This is experimental and subject to change.

Nexus Support (experimental)

The Nexus .NET SDK has been released and this release adds Temporal support for implementing Nexus services with Temporal and calling Nexus services from Temporal workflows. See the Temporal SDK Developer Guide, Nexus SDK README, the Temporal SDK README section, and the initial Nexus .NET sample.

⚠️ This is experimental and subject to change.

💥 MINOR BREAKING BEHAVIOR CHANGE - Serialization Context Change in Workflows

For advanced users of custom converters/codecs that were also leveraging the recent serialization context feature, there is a slight change in how they are handled in workflows. Previously, we eagerly created and used the converter/codec for all workflow use with the singular workflow context which meant we "stacked" contexts when they were also used for activities and children and such. Now we are properly not stacking the outer workflow context when making these other calls. So technically if there was a custom converter using advanced serialization contexts that relied on this context stacking, this can be a breaking change. See the PR at #525 for more details.

💥 MINOR BREAKING BEHAVIOR CHANGE - TLS cert override causes native certs to not be used

When a TLS server CA cert is explicitly set in TLS options to override system roots, the system roots will not be loaded. Prior to this version, system roots would still be loaded even if cert overrides were present.

Specific Changes

2025-09-18 - 45e61c8 - Activity reset (#521)
2025-09-18 - 95f840a - Fixed error message of BinaryProtoConverter.AssertProtoPayload not filling a placeholder (#520)
2025-09-22 - 2319df1 - Added retry policy to activity info (#511)
2025-09-22 - 8db923c - Env config (#509)
2025-09-22 - da7202a - Nexus support (#517)
2025-09-22 - e29940d - Added summary to local activity options (#524)
2025-09-25 - d4a0765 - Update version to 1.9.0 (#527)
2025-09-25 - f99bca3 - 💥 Fix how serialization context is applied in workflows [MINOR COMPAT BREAK] (#525)
2025-09-25 - fad7fb3 - Fix issue with search attribute keyword list type (#529)

1.8.0

02 Sep 18:42
a5ebdac

Choose a tag to compare

Get from NuGet and read the README

Highlights

💥 BREAKING CHANGE - C bridge has been moved to Core SDK repository, library file names have changed

The C bridge library used to integrate .Net SDK with Core SDK has been moved to facilitate using it for SDKs in other languages. As part of the move, the bridge library, its functions and its artifacts have been given more specific names.

Previously, the C bridge library had the filename temporal_sdk_bridge.dll on Windows, libtemporal_sdk_bridge.so on Linux, and libtemporal_sdk_bridge.dylib on macOS.

The filename has changed to temporal_sdk_core_c_bridge.dll on Windows, libtemporal_sdk_core_c_bridge.so on Linux, and libtemporal_sdk_core_c_bridge.dylib on macOS.

If your build process depends on the exact naming of these files, it needs to be updated to use the new file names. Furthermore, if you were using the C bridge library directly, there have been further breaking changes in the library itself. See the following Core SDK PR for details: temporalio/sdk-core#951

Task Queue Fairness Support (experimental)

This release adds support for Task Queue Fairness. Fairness is a new feature of Temporal's task queues that allows for more control over the order that tasks are dispatched from a backlog. It's intended to address common situations like multi-tenant applications and reserved capacity bands.

This is in addition to "Workflow & Activity Priorities" provided last release.

Specific Changes

2025-06-18 - 165569d - Deprecate VersioningIntent (#491)
2025-06-26 - 99847b5 - Add defaults for Poller automation (#493)
2025-06-30 - d1fedb0 - Fix issue where child workflow starts and completes in same activation (#492)
2025-07-02 - 8e94382 - Moved C Bridge from dotnet-sdk to core-sdk repo (💥 BREAKING CHANGE) (#494)
2025-07-16 - 2a7621c - Remove experimental notices from update with start calls (#497)
2025-07-17 - 5b15fb8 - Missed an UwS experimental warning (#498)
2025-08-04 - f225d76 - Remove CLI version pin for internal tests (#501)
2025-08-07 - b55175e - Made TemporalWorker.ExecuteAsync() keep working even after Dispose() (#503)
2025-08-11 - 6f27e45 - Do not require heartbeating to be done in context (#504)
2025-08-22 - deb2756 - Fairness Keys & Weights (#508)
2025-09-02 - 77f839d - Added FirstExecutionRunId to WorkflowInfo (#516)

1.7.0

09 Jun 15:05
21ae81b

Choose a tag to compare

Get from NuGet and read the README

Highlights

Workflow & Activity Priorities

Users can now set a priority key when scheduling a workflow, activity or child workflows. The priority key will be used to help prioritize certain tasks over others when there is a backlog. Priority is currently not supported in any OSS Temporal release, but support will be coming soon. To experiment with this feature please see the pre-release development server or if you are a Temporal Cloud customer reach out to your SA.

Worker deployment versioning preview

This release introduces a preview of new APIs that gracefully manage code changes and worker pools that support them. The goal is to better control which workers should execute new, and existing, workflows and activities tasks, based on their code and configuration.

VersioningBehavior.AutoUpgrade and VersioningBehavior.Pinned are two Versioning Behaviors that can be specified on a workflow implementation using the VersioningBehavior argument to the Workflow attribute. Pinned workflows are typically short lived, and are never affected by new versions, i.e., they do not need to use the patch API for compatibility. AutoUpgrade workflows are mostly long running, but they need to use patching to safely transition to new versions. The choice of Pinned vs AutoUpgrade ultimately depends on your willingness to keep old worker fleets running vs the complexity of patching.

To manage Worker Deployments please use the Temporal CLI, or Temporalio.Client.WorkflowService

Automatic Poller Scaling

You can configure Workers to automatically adjust the number of concurrent polls they make for tasks! Set the WorkflowTaskPollerBehavior and ActivityTaskPollerBehavior arguments of the Worker options to PollerBehavior.Autoscaling to try it out. You can expect fewer unnecessary polls during low load, and increased polls during high load when they can be used to increase task throughput.

Activity pause support

Activity pausing (not GA currently) will now cancel the activity cancellation token thereby interrupting activity execution similar to how activity cancel and worker shut down does. There is a new CancellationDetails property on the ActivityExecutionContext that provides the reason for cancellation token being set.

Specific Changes

2025-04-28 - 98db10f - Add CODEOWNERS (#467)
2025-04-28 - d48377d - Handle errors with update result serialization (#468)
2025-04-28 - dcf7e1c - Replace BuildJet in build-binary smoke test (#469)
2025-05-08 - 1890573 - Fail the workflow task if a requested local activity is not registered (#472)
2025-05-14 - 4205a59 - Expose poller automation (#477)
2025-05-14 - cbf20f9 - Worker Deployment Versioning (#466)
2025-05-16 - 910fb1c - Improve/verbosify error messages in various ToInteropOptions methods (#481)
2025-05-19 - 8918a31 - Properly restore auto-time-skipping after disabled (#475)
2025-05-19 - b94084b - Add WorkflowInfo.WorkflowStartTime (#476)
2025-05-27 - 864e654 - Activity pause support (#482)
2025-05-29 - fa93167 - Added Category to ApplicationFailureException (#483)
2025-06-06 - 761465d - Updated sdk-core to latest (#485)
2025-06-06 - a7ca5ec - Make static summary/details lazy on workflow description (#486)

1.6.0

21 Apr 13:52
464b895

Choose a tag to compare

Get from NuGet and read the README

Highlights

New Event Loop Algorithm

A significant change was made to the event loop internals to allow for proper expectations on tasks and wait conditions. Specifically for most users, the biggest difference is that only one WaitConditionAsync will be resolved at a time before the tasks continue. So now if you have multiple coroutines/tasks with:

await Workflow.WaitConditionAsync(() => !locked);
locked = true;

That kind of a mutex now works, whereas before it would wake up all wait conditions at once. So before you could not guarantee that the wait condition was satisfied on the line after the wait condition, but now you can.

This change can cause backwards incompatible history, so we took care to make sure past workflows still use the previous algorithm. See #432 for more details.

💥 BREAKING CHANGE - Removed assumed use-worker-versioning in DI when build ID present

This is a breaking change only for those that used non-GA versioning and use build IDs specifically in their AddHostedTemporalWorker calls. We previously assumed that the simple presence of a build ID was enough to opt-in to this non-GA versioning (which is being replaced with a newer form of versioning anyways). We now no longer assume this, so for any users relying on this unstable form of versioning, UseWorkerVersioning worker option will have to be explicitly set to true instead of relying on it being done implicitly when build ID is present.

This only affects a very small subset of users trying out a pre-release form of versioning. See #432 for more details.

MUSL-based Builds Supported

We now publish Linux-musl builds for x64 to NuGet which means users can use Alpine-based .NET docker images.

Serialization Context Available For Converters/Codecs

Payload converters, failure converters, and payload codecs can now implement IWithSerializationContext that will have WithSerializationContext called when needing to do context-specific conversion for workflows or activities. A common use case for this is to allow codecs to have different encryption keys per workflow ID or namespace. See #446 for more details.

Specific Changes

2025-02-28 - bbbfad1 - Add advanced signal-handling tests (#418)
2025-03-17 - 612fe2f - Use RawValue for built-in query response (#424)
2025-03-17 - 7829fd3 - Allow unaltered payload response from codec (#425)
2025-03-18 - 8631656 - add protected constructors for metric instrumentation in Temporalio.Common namespace (#431)
2025-03-18 - fc0fd7b - change readme activity examples from scheduletoclose to starttoclose (#433)
2025-03-19 - bac42d3 - Apply modern event loop algorithm with new SDK flag (#432)
2025-04-09 - 5cb605e - Add Workflow.Unsafe.WithTracingEventListenerDisabled (#443)
2025-04-09 - 9ac9d69 - Increase visibility on some client constructs and minor docs updates (#434)
2025-04-10 - 0ef89ac - Add ActivityDefinition.CreateWithoutAttribute overload (#451)
2025-04-10 - 409e53f - Remove assumed use-worker-versioning in DI when build ID present (#452)
2025-04-10 - 6c2a78f - Provide MUSL-based build (#447)
2025-04-10 - fc4ea01 - Allow absent payloads on some responses (#449)
2025-04-15 - 6dbf752 - Serialization context for converters and codecs (#446)
2025-04-16 - 6a0eb69 - Update Core (with changes needed) and update version to 1.6.0 (#453)
2025-04-17 - 464b895 - Custom histogram metric buckets (#456)
2025-04-17 - 4fed10a - Expose root execution (#454)
2025-04-17 - 5531bfe - proposed readme nits (#455)

1.5.0

13 Feb 15:49
d01bacc

Choose a tag to compare

Get from NuGet and read the README

Highlights

Search Attributes in Dev Server

To make testing easier, Temporalio.Testing.WorkflowEnvironment.StartLocalAsync now accepts SearchAttributes in its options to start the server with pre-created search attributes.

Client in Activity

It is a common use case to use a Temporal client in an activity. TemporalClient is now available on the Temporalio.Activities.ActivityExecutionContext to make this easier.

Activity Service Scope

For those using dependency injection, Temporalio.Extensions.Hosting.ActivityScope is now available which provides access to both the activity instance and IServiceScope to have access to the service provider in the activity or activity interceptor.

Specific Changes

2025-01-16 - 3dd6cca - Expose instance to workflows/activities and client to activities (#393)
2025-01-24 - b5ca854 - Accept search attributes for dev server (#289)
2025-02-03 - 69dfe5a - Updated the docs for IdReusePolicy property (#397)
2025-02-03 - 7b92674 - Fix issue where null timer summary breaks codec (#405)
2025-02-05 - 139a853 - Update Core & add HTTP Otel / Dev UI Port (#407)
2025-02-11 - 2b97703 - Document CA issues in AWS and Azure (#411)
2025-02-11 - f2ba7dd - Reserve __temporal prefix (#410)