Skip to content

chore(deps): Bump the minor-and-patch group with 4 updates - #349

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/backend/minor-and-patch-75d849a889
Closed

dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/backend/minor-and-patch-75d849a889

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 20, 2026 •

Copy link
Copy Markdown
Contributor

Updated Anthropic from 12.40.0 to 12.42.0.

Updated Aspire.Npgsql from 13.4.6 to 13.5.0.

Release notes

Sourced from Aspire.Npgsql's releases.

13.5.0

Aspire 13.5.0

Aspire 13.5 is a developer-experience release focused on a richer, more interactive AppHost, closer C# and TypeScript parity, sharper tooling, more flexible deployment modeling, and a broad set of runtime-stability improvements.

Highlights

  • 💬 Richer AppHost interactions — The Interaction Service now works across C# and TypeScript AppHosts with stable prompts and dynamic inputs, file uploads, progress dialogs, notifications, and user-defined resource command arguments that surface as dashboard controls and CLI options.
  • 🖥️ Interactive terminal sessions — The experimental WithTerminal() API lets resources host REPLs, shells, TUIs, and other interactive programs directly in the dashboard, with an opt-in aspire terminal CLI command for attaching from your shell.
  • 🌐 TypeScript AppHost is generally available — Polyglot AppHosts no longer require the ASPIREATS001 experimental diagnostic and gain custom health checks, container file copying, HTTPS developer certificates, faster startup, and several reliability fixes that further close the gap with C#.
  • 🛠️ CLI installation and reliability — The Aspire CLI is available through npm and Nix alongside Homebrew, WinGet, mise, and NuGet. New C# AppHosts enable the CLI bundle by default, while aspire stop --force, aspire update --migrate, aspire doctor, docs search, signal handling, and stale-socket cleanup all improve day-to-day workflows.
  • 🎨 Refreshed dashboard — The dashboard adopts official Aspire branding and a new accessible design-token system, with timestamp and exact numeric telemetry filters, console-log text search, clearer reconnect and health-check experiences, and correct telemetry streaming while filters are active.
  • 💻 Rebranded VS Code extension — The extension is now named Aspire and adds an in-editor dashboard, Bun and MAUI debugging, resource commands in the tree view, discovered AppHosts, improved parameter handling, and more efficient workspace discovery.
  • ☸️ More expressive deployments — Kubernetes and AKS gain first-class persistent volumes, Azure Container Apps adds deterministic unique resource naming, Azure environments support delegated subnets, and Docker Compose can publish Blazor gateways and configure shared memory.
  • ☁️ Expanded hosting integrations — Azure resources can be referenced across resource groups, subscriptions, and tenants; the new Aspire.Hosting.Dotnet package models .NET projects by path; Radius deployment arrives in preview; and Foundry Local, Redis modules, dev tunnels, Go debugging, and other integrations gain new capabilities.

⚠️ Breaking changes

Notable changes include hosting context ServiceProvider properties being renamed to Services, PublishAsConnectionString becoming obsolete in favor of AddConnectionString, removal of aspire ps --resources and --include-hidden in favor of aspire describe, earlier proxyless endpoint port allocation, deprecation of the GitHub Models integration, removal of the dashboard AI Assistant, and opt-in rather than automatic dashboard launch from the VS Code extension.

See the full list and migration guidance in the Aspire 13.5 breaking changes.

📖 Learn more

For complete details, examples, migration guidance, and everything new in this release, read What's new in Aspire 13.5.

Thank you to all the community contributors who helped make Aspire 13.5 possible! 💜


Full Changelog: v13.4.6...v13.5.0

Full commit: e076d8e427cb3afb528dbd605acd74c3aea69f94

Commits viewable in compare view.

Updated Marten from 9.25.0 to 9.28.0.

Release notes

Sourced from Marten's releases.

9.28.0

Full Changelog: JasperFx/marten@V9.27.0...V9.28.0

What's Changed

Full Changelog: JasperFx/marten@V9.27.0...V9.28.0

9.27.0

Adopts JasperFx 2.51.0 and the four capabilities it promotes into the shared Critter Stack contracts. One of them is a genuinely new Marten feature; the other three close gaps where Marten had the capability but not under the shared spelling.

Aggregate snapshot caching for FetchForWriting (#​5251)

An opt-in, node-local cache of aggregate snapshots that lets FetchForWriting skip loading the stored snapshot and read only the events after it — effectively an identity map for aggregates with a lifetime longer than a session. Off for every aggregate type; enabled per type, because the win is proportional to how often one stream is fetched for writing:

opts.Events.CacheAggregatesForWriting<Order>(sizeLimit: 1000);

The cached snapshot is only ever a baseline. The stream version and every event after the cached version are still read on every call, and the optimistic concurrency assertion on append is untouched — so a stale entry costs a larger delta query, never a wrong aggregate and never a suppressed EventStreamUnexpectedMaxEventIdException. That is what makes a deliberately incoherent, node-local cache the right shape here, and why there is no distributed-cache option: a distributed cache would reintroduce exactly the round trip this exists to remove.

Both the Async and Inline lifecycles are supported, and they genuinely differ. An Inline snapshot is written in the same transaction as the events, so it is always exactly at the stream head — a hit needs an exact version match, and the entry is written back only after a successful commit, because the inline projection mutates the very instance FetchForWriting handed out.

IAggregateWriteCache and friends live in JasperFx.Events.Fetching, so one cache implementation serves Marten, Polecat and Fisher alike. No new package lands on core Marten: the default is backed by JasperFx.Core's existing LRU rather than Microsoft.Extensions.Caching.Memory.

Docs: Optimizing Performance → Caching Aggregate Snapshots for FetchForWriting.

IDocumentSessionOperations.PendingStreams (#​5250)

Store-agnostic code can now read the StreamActions a session has queued but not yet committed — for a listener or a pre-commit hook deciding something from the events the session is about to write — without naming a store.

⚠️ Worth knowing if you are implementing these contracts yourself: this is the same non-covariance trap as 9.26's Events accessor. Marten's PendingChanges.Streams() returns IList<StreamAction>, and IList<T> is not assignable to IReadOnlyList<T>, so the member bound to the interface's throwing default with no compile error anywhere. It now carries an explicit implementation, pinned by PendingStreamActionsCompliance.

In Marten this is the same collection as IDocumentSession.PendingChanges.Streams(), handed back as a live view rather than a copy.

BinaryEventAttribute — one lookup instead of two (#​5248)

Marten.Events.BinaryEventAttribute now derives from the promoted JasperFx.Events.BinaryEventAttribute, which 2.51.0 unsealed for exactly this. EventGraph.ResolveBinarySerializerFor drops back to a single attribute lookup. Entirely non-breaking — existing [BinaryEvent] usages compile and resolve unchanged.

Compliance (#​5249)

DocumentComplianceConfig.StreamIdentity is now replayed by Marten's document compliance fixture rather than inferred, and two new shared suites are enrolled: PendingStreamActionsCompliance and AggregateWriteCacheCompliance (wave 10).

Upgrading

No breaking changes and no migration. Everything new here is opt-in.

Full changelog: JasperFx/marten@V9.26.0...V9.27.0

9.26.0

Consumes JasperFx 2.50.0, which promoted two things into the shared contracts. Both changes here are additive — existing code compiles and behaves identically.

Reach the event store from a store-agnostic session (jasperfx#​669)

JasperFx.Events.Documents gained an Events accessor on its session contracts, so a consumer that opens its own session through IDocumentSessionFactory can now reach the event store without naming Marten:

tier member
IDocumentReadOperations IQueryEventStore Events
IDocumentSessionOperations IEventStoreOperations Events

Marten implements both. This does not affect handlers taking a chain parameter — Wolverine already fills those. It matters for the two shapes where you decide when a session exists: a background or timer publisher that opens a session and appends, and a deliberate second read session opened alongside a chain's writing session.

⚠️ Worth knowing if you maintain a store or a session wrapper. C# interface implementation is not return-type covariant, so a session that already declares an Events property of its own event-store type does not satisfy the contract member — it binds to a default that throws, and the build still succeeds with zero errors. Marten's own IQuerySession.Events returns Marten.Events.IQueryEventStore, a subtype, which is exactly this case; both tiers needed an explicit implementation. The shared compliance suite is what catches it.

IEventBinarySerializer promoted to JasperFx.Events

Binary event serialization (#​4515) was Marten-specific, so a consumer compiling one body of source against several Critter Stack stores needed a separate identical serializer per store. The two-method interface and [BinaryEvent] now live in JasperFx.Events, and one serializer serves every store.

Non-breaking, in both directions:

  • Marten.Events.IEventBinarySerializer still exists and now derives from the core interface, so existing implementations keep compiling and also satisfy the core type.
  • EventGraph.UseBinarySerializer<T>, DefaultBinarySerializer, IEventStoreOptions and EventMapping.BinarySerializer widened to accept the core interface, so a store-agnostic serializer can be registered.
  • Both the Marten and the core [BinaryEvent] attributes are honored.

Fixed: binary serializer registration was order-dependent

EventMapping resolved its binary serializer in its constructor, and AddEventType<T>() builds mappings eagerly. So this threw "no IEventBinarySerializer was registered" out of what reads as a plain type registration:

opts.Events.AddEventType<SomeBinaryEvent>();          // [BinaryEvent]-marked
opts.Events.DefaultBinarySerializer = mySerializer;   // too late

while the same two lines in the opposite order worked. Resolution is lazy now, deferring the failure to first use — which is what the documentation always described. The guard is volatile, because it is read from the append path on many threads and a torn read would route a binary event down the JSON path silently rather than throwing.

Also

  • Enrolled in the two new shared compliance suites, DocumentSessionEventsCompliance and BinaryEventSerializationCompliance.
  • Docs updated: events/binary-serialization.md, documents/sessions.md.

Full changelog: JasperFx/marten@9.25.0...9.26.0

Commits viewable in compare view.

Updated Marten.EntityFrameworkCore from 9.25.0 to 9.28.0.

Release notes

Sourced from Marten.EntityFrameworkCore's releases.

9.28.0

Full Changelog: JasperFx/marten@V9.27.0...V9.28.0

What's Changed

Full Changelog: JasperFx/marten@V9.27.0...V9.28.0

9.27.0

Adopts JasperFx 2.51.0 and the four capabilities it promotes into the shared Critter Stack contracts. One of them is a genuinely new Marten feature; the other three close gaps where Marten had the capability but not under the shared spelling.

Aggregate snapshot caching for FetchForWriting (#​5251)

An opt-in, node-local cache of aggregate snapshots that lets FetchForWriting skip loading the stored snapshot and read only the events after it — effectively an identity map for aggregates with a lifetime longer than a session. Off for every aggregate type; enabled per type, because the win is proportional to how often one stream is fetched for writing:

opts.Events.CacheAggregatesForWriting<Order>(sizeLimit: 1000);

The cached snapshot is only ever a baseline. The stream version and every event after the cached version are still read on every call, and the optimistic concurrency assertion on append is untouched — so a stale entry costs a larger delta query, never a wrong aggregate and never a suppressed EventStreamUnexpectedMaxEventIdException. That is what makes a deliberately incoherent, node-local cache the right shape here, and why there is no distributed-cache option: a distributed cache would reintroduce exactly the round trip this exists to remove.

Both the Async and Inline lifecycles are supported, and they genuinely differ. An Inline snapshot is written in the same transaction as the events, so it is always exactly at the stream head — a hit needs an exact version match, and the entry is written back only after a successful commit, because the inline projection mutates the very instance FetchForWriting handed out.

IAggregateWriteCache and friends live in JasperFx.Events.Fetching, so one cache implementation serves Marten, Polecat and Fisher alike. No new package lands on core Marten: the default is backed by JasperFx.Core's existing LRU rather than Microsoft.Extensions.Caching.Memory.

Docs: Optimizing Performance → Caching Aggregate Snapshots for FetchForWriting.

IDocumentSessionOperations.PendingStreams (#​5250)

Store-agnostic code can now read the StreamActions a session has queued but not yet committed — for a listener or a pre-commit hook deciding something from the events the session is about to write — without naming a store.

⚠️ Worth knowing if you are implementing these contracts yourself: this is the same non-covariance trap as 9.26's Events accessor. Marten's PendingChanges.Streams() returns IList<StreamAction>, and IList<T> is not assignable to IReadOnlyList<T>, so the member bound to the interface's throwing default with no compile error anywhere. It now carries an explicit implementation, pinned by PendingStreamActionsCompliance.

In Marten this is the same collection as IDocumentSession.PendingChanges.Streams(), handed back as a live view rather than a copy.

BinaryEventAttribute — one lookup instead of two (#​5248)

Marten.Events.BinaryEventAttribute now derives from the promoted JasperFx.Events.BinaryEventAttribute, which 2.51.0 unsealed for exactly this. EventGraph.ResolveBinarySerializerFor drops back to a single attribute lookup. Entirely non-breaking — existing [BinaryEvent] usages compile and resolve unchanged.

Compliance (#​5249)

DocumentComplianceConfig.StreamIdentity is now replayed by Marten's document compliance fixture rather than inferred, and two new shared suites are enrolled: PendingStreamActionsCompliance and AggregateWriteCacheCompliance (wave 10).

Upgrading

No breaking changes and no migration. Everything new here is opt-in.

Full changelog: JasperFx/marten@V9.26.0...V9.27.0

9.26.0

Consumes JasperFx 2.50.0, which promoted two things into the shared contracts. Both changes here are additive — existing code compiles and behaves identically.

Reach the event store from a store-agnostic session (jasperfx#​669)

JasperFx.Events.Documents gained an Events accessor on its session contracts, so a consumer that opens its own session through IDocumentSessionFactory can now reach the event store without naming Marten:

tier member
IDocumentReadOperations IQueryEventStore Events
IDocumentSessionOperations IEventStoreOperations Events

Marten implements both. This does not affect handlers taking a chain parameter — Wolverine already fills those. It matters for the two shapes where you decide when a session exists: a background or timer publisher that opens a session and appends, and a deliberate second read session opened alongside a chain's writing session.

⚠️ Worth knowing if you maintain a store or a session wrapper. C# interface implementation is not return-type covariant, so a session that already declares an Events property of its own event-store type does not satisfy the contract member — it binds to a default that throws, and the build still succeeds with zero errors. Marten's own IQuerySession.Events returns Marten.Events.IQueryEventStore, a subtype, which is exactly this case; both tiers needed an explicit implementation. The shared compliance suite is what catches it.

IEventBinarySerializer promoted to JasperFx.Events

Binary event serialization (#​4515) was Marten-specific, so a consumer compiling one body of source against several Critter Stack stores needed a separate identical serializer per store. The two-method interface and [BinaryEvent] now live in JasperFx.Events, and one serializer serves every store.

Non-breaking, in both directions:

  • Marten.Events.IEventBinarySerializer still exists and now derives from the core interface, so existing implementations keep compiling and also satisfy the core type.
  • EventGraph.UseBinarySerializer<T>, DefaultBinarySerializer, IEventStoreOptions and EventMapping.BinarySerializer widened to accept the core interface, so a store-agnostic serializer can be registered.
  • Both the Marten and the core [BinaryEvent] attributes are honored.

Fixed: binary serializer registration was order-dependent

EventMapping resolved its binary serializer in its constructor, and AddEventType<T>() builds mappings eagerly. So this threw "no IEventBinarySerializer was registered" out of what reads as a plain type registration:

opts.Events.AddEventType<SomeBinaryEvent>();          // [BinaryEvent]-marked
opts.Events.DefaultBinarySerializer = mySerializer;   // too late

while the same two lines in the opposite order worked. Resolution is lazy now, deferring the failure to first use — which is what the documentation always described. The guard is volatile, because it is read from the append path on many threads and a torn read would route a binary event down the JSON path silently rather than throwing.

Also

  • Enrolled in the two new shared compliance suites, DocumentSessionEventsCompliance and BinaryEventSerializationCompliance.
  • Docs updated: events/binary-serialization.md, documents/sessions.md.

Full changelog: JasperFx/marten@9.25.0...9.26.0

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

Bumps Anthropic from 12.40.0 to 12.42.0
Bumps Aspire.Npgsql from 13.4.6 to 13.5.0
Bumps Marten from 9.25.0 to 9.28.0
Bumps Marten.EntityFrameworkCore from 9.25.0 to 9.28.0

---
updated-dependencies:
- dependency-name: Anthropic
  dependency-version: 12.42.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: minor-and-patch
- dependency-name: Aspire.Npgsql
  dependency-version: 13.5.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: minor-and-patch
- dependency-name: Marten
  dependency-version: 9.28.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: minor-and-patch
- dependency-name: Marten.EntityFrameworkCore
  dependency-version: 9.28.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: minor-and-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Aug 20, 2026
@github-actions

Copy link
Copy Markdown

Dependency Review

The following issues were found:
  • ✅ 0 vulnerable package(s)
  • ✅ 0 package(s) with incompatible licenses
  • ✅ 0 package(s) with invalid SPDX license definitions
  • ⚠️ 6 package(s) with unknown licenses.
See the Details below.

License Issues

backend/src/RunCoach.Api/RunCoach.Api.csproj

PackageVersionLicenseIssue Type
Anthropic12.42.0NullUnknown License
Aspire.Npgsql13.5.0NullUnknown License
JasperFx2.52.0NullUnknown License
JasperFx.Events2.52.0NullUnknown License
Marten9.28.0NullUnknown License
Marten.EntityFrameworkCore9.28.0NullUnknown License
Allowed Licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, 0BSD, Unlicense, CC0-1.0, CC-BY-4.0, OFL-1.1, Zlib, BSL-1.0, Python-2.0, PSF-2.0, Artistic-2.0, MPL-2.0, WTFPL, PostgreSQL
Excluded from license check: pkg:githubactions/SonarSource/sonarqube-scan-action, pkg:npm/runcoach-frontend

OpenSSF Scorecard

PackageVersionScoreDetails
nuget/Anthropic 12.42.0 UnknownUnknown
nuget/Aspire.Npgsql 13.5.0 UnknownUnknown
nuget/JasperFx 2.52.0 UnknownUnknown
nuget/JasperFx.Events 2.52.0 UnknownUnknown
nuget/Marten 9.28.0 UnknownUnknown
nuget/Marten.EntityFrameworkCore 9.28.0 UnknownUnknown

Scanned Files

  • backend/src/RunCoach.Api/RunCoach.Api.csproj

@dependabot @github

dependabot Bot commented on behalf of github Aug 27, 2026

Copy link
Copy Markdown
Contributor Author

Looks like these dependencies are updatable in another way, so this is no longer needed.

@dependabot dependabot Bot closed this Aug 27, 2026
@dependabot
dependabot Bot deleted the dependabot/nuget/backend/minor-and-patch-75d849a889 branch August 27, 2026 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants