Repository navigation
Bump Dapr.Client from 1.18.10 to 1.19.0 - #2329
Merged
Merged
Conversation
--- updated-dependencies: - dependency-name: Dapr.Client dependency-version: 1.19.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.sh | bash -s -- 2329Or
iex "& { $(irm https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.ps1) } 2329" |
afscrome
approved these changes
Oct 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated Dapr.Client from 1.18.10 to 1.19.0.
Release notes
Sourced from Dapr.Client's releases.
1.19.0
What's Changed
New Contributors
Full Changelog: dapr/dotnet-sdk@v1.18.10...v1.19.0
1.19.0-rc.6
What's Changed
New Contributors
Full Changelog: dapr/dotnet-sdk@v1.18.10...v1.19.0-rc.6
What's Changed
Full Changelog: dapr/dotnet-sdk@v1.19.0-rc.4...v1.19.0-rc.6
1.19.0-rc.4
What's Changed
New Contributors
Full Changelog: dapr/dotnet-sdk@v1.19.0-rc.3...v1.19.0-rc.4
1.19.0-rc.3
What's Changed
Full Changelog: dapr/dotnet-sdk@v1.19.0-rc.2...v1.19.0-rc.3
1.19.0-rc.2
What's Changed
Full Changelog: dapr/dotnet-sdk@v1.19.0-rc.1...v1.19.0-rc.2
1.19.0-rc.1
What's Changed
Support for Dapr Runtime changes ahead of v1.19:
General Improvements
Bug Fixes
Full Changelog: dapr/dotnet-sdk@v1.18.10...v1.19.0-rc.1
1.19.0-preview.2
Dapr.Actors.Nextis a ground-up re-implementation of the Dapr Actors building block for .NET, shipping as a preview throughout the 1.18 release cycle, with a stable release planned alongside Dapr runtime v1.19. The actor model itself is unchanged: actors remain virtual, addressed by type and ID, and support reentrancy, timers, reminders, proxying, etc. However, the way the SDK connects to the runtime and the way you write actor code have been modernized.Highlights
Actor callbacks (invoke, reminder, timer, deactivate) now arrive over a long-lived bidirectional gRPC stream instead of inbound, per-call HTTP requests into mapped actor-handler endpoints. This is the same pattern already used for Dapr workflows and streaming pub/sub subscriptions. There are no actor handlers to map, though your app will still need to expose a port for inbound gRPC connections from the Dapr runtime.
Source generators produce the proxy, dispatcher, activation factory, registration and actor registry from your interface and implementation. Actors are discovered rather than registered by hand, and the runtime packages can be used in applications building for Native AOT.
The public surface is annotated for nullable reference types, and new analyzers and code fixes catch actor-specific mistakes as you type: non-serializable or non-task-returning methods, blocking calls inside a turn, state changes that would break deserialization, using a callback method in a reminder that doesn't exist in the specified type, reading time from the clock instead of an injected
TimeProvider, and more!This release features per-activation DI scopes, use of the options pattern (
IOptions<DaprActorsOptions>), and the same pluggableIDaprSerializer(System.Text.Json by default) used byDapr.StateManagementandDapr.Workflow.State-envelope schema versioning with upcaster chains, a first-class
StateMachineActor<TState, TData>model, pub/sub-driven actors via[Subscribe]applied to the method to call instead of requiring external startup subscription and invocation, dynamic invocation by type/id/method with no compile-time contract, and an in-memory deterministic test runtime with optional Coyote integration.Performance
Replacing the reflection-based proxy and dispatch machinery with source generators shows up directly in the numbers. In our benchmarks, creating an actor proxy drops from roughly 725 ns and 3.4 KB allocated under
Dapr.Actorsto about 14 ns and 48 B underDapr.Actors.Next: a ~50x improvement in time and ~70x in allocation. A warm actor call is about 20% faster (≈484 ns -> ≈375 ns) and allocates roughly 30% less (1,264 B -> 912 B). The largest end-to-end win is in startup: building the provider, resolving the actor runtime, and dispatching the first call takes ~284 µs underDapr.Actorsversus ~37 µs underDapr.Actors.Next, an ~8x reduction that holds steady as the number of registered actor types grows because registration and dispatch are generated at compile time rather than discovered and emitted on first use. Container construction itself is marginally more expensive on the new SDK (~6.0 µs vs ~4.7 µs) as more is wired up front, but that cost is repaid many times over on the first invocation.We expect further optimizations before the 1.19 GA.
Benchmarks run with BenchmarkDotNet; figures are means from a single machine and are indicative rather than a guarantee. Feel free to run them yourself from here.
Compatibility notes
Dapr.Actors. Because actors are addressed by the same type names, you can migrate one actor type at a time, but it's easier to do that across separate projects than to mix both SDKs in one.IDaprSerializerif you need it). Verify that existing persisted state still deserializes before migrating a type.Dapr.Actorsand its associated packages are now in maintenance mode and will receive security and bug fixes only. No deprecation date has been set.Getting started
Add the package to your project:
Then register it in DI with
builder.Services.AddDaprActors().Documentation is available along with a six-part tutorial spanning different implementation examples.
Please reach out in the .NET channel on Discord or file an issue if you encounter problems, have feature suggestions, or just want to share feedback about this new functionality!
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)