Bump the nuget group with 2 updates

[dependabot]

Updated Microsoft.NET.Test.Sdk from 18.9.0 to 18.10.1.

Release notes

Sourced from Microsoft.NET.Test.Sdk's releases.

18.10.1

What's Changed

• Isolate code coverage files in published output by @​azat-msft in [rel/18.10] Isolate code coverage files in published output microsoft/vstest#16476

Full Changelog: microsoft/vstest@v18.10.0...v18.10.1

18.10.0

What's Changed

• Drop Mono fallback, run .NET Framework tests on Windows only by @​nohwnd in Drop Mono fallback, run .NET Framework tests on Windows only microsoft/vstest#16158
• Run Microsoft.Testing.Platform test apps under vstest.console and datacollector by @​nohwnd in Run Microsoft.Testing.Platform test apps under vstest.console and datacollector microsoft/vstest#16201
• Fix test output eaten by MSBuild terminal logger by @​nohwnd in [fix] Fix test output eaten by MSBuild terminal logger microsoft/vstest#16223
• Remove the experimental test session feature by @​nohwnd in Remove the experimental test session feature microsoft/vstest#16231
• Skip a single bad executor instead of failing all executor loading by @​nohwnd in Skip a single bad executor instead of failing all executor loading microsoft/vstest#16239
• Assert apartment state instead of using Clipboard in UI tests by @​nohwnd in Assert apartment state instead of using Clipboard in UI tests microsoft/vstest#16270
• Surface test host crashes during protocol negotiation by @​nohwnd in Surface test host crashes during protocol negotiation microsoft/vstest#16285
• Pass the inferred target platform to the host in run settings by @​nohwnd in Pass the inferred target platform to the host in run settings microsoft/vstest#16271
• Report raw invalid IsTargetPlatformInferred value, cover host x64 forcing by @​nohwnd in Report raw invalid IsTargetPlatformInferred value, cover host x64 forcing microsoft/vstest#16295
• Disable the MTP testhost by default (#​16337) by @​nohwnd in [rel/18.10] Disable the MTP testhost by default (#16337) microsoft/vstest#16341

Full Changelog: microsoft/vstest@v18.9.0...v18.10.0

Commits viewable in compare view.

Updated Pixnop.Atlas.XUnit from 0.11.0 to 0.13.1.

Release notes

Sourced from Pixnop.Atlas.XUnit's releases.

0.13.1

Fixed

• Every JoinPlayer against a recent Stratum server (stable v1.22.7-stratum.2 and indev)
  failed with "did not finish joining the world within the tick bound", while the same scenarios
  passed on vanilla 1.22.7. Stratum's first-packet gate (ServerMain.cs, 2026-08-24) no longer
  creates the ConnectedClient on the connection event: it creates it on the first
  NetworkMessageType.Data message, and only when that packet is a ServerQuery (15) or a
  LoginTokenQuery (33). Anything else has its connection shut down with nothing logged.
  DummyClientConnector opened the handshake with the identification packet (1), so the join
  was dropped before the server had a chance to look at it and the wait could only time out. The
  connector now sends the login token query first and the identification second, which is the
  order the real client uses on every connection, singleplayer over the same dummy socket
  included (ClientMain.Connect). Vanilla answers the query with a LoginTokenAnswer (77) that
  ClientObservations dequeues and ignores, since it carries none of the four sub-messages that
  class dispatches on, so nothing changes there.

0.13.0

Added

• samples/: a README explaining what each of the three sample projects demonstrates, a
  ConfigScenarios scenario asserting the same command from a joined test player's chat
  (Say plus Client.ChatLines()) next to the console-caller version, and an
  IsolationScenarios pair showing that two scenarios writing the same block pass in either
  order under RollbackWorld = true, with no test orderer. The samples are the runnable
  documentation, and until now they covered neither test players nor world isolation.

• CONTRIBUTING.md, a pull request template and a bug report form: build environment, the
  three test commands, branch and commit conventions, the changelog expectation, and the
  release steps including the three places the pinned package version has to be bumped.

• The NuGet packages carry an icon, and their page on nuget.org now reads as a page written for
  nuget.org. The repository README was packed as-is, so its logo, its LICENSE link and its eight
  links into docs/ and .github/ all pointed at paths that do not exist there. A short
  docs/nuget-readme.md with absolute URLs is packed instead: what Atlas is, requirements, the
  install line, a first scenario, and links back to the README, the wiki, the changelog and the
  Mod DB page.

Changed

• Breaking: atlas fixture and worker mode now need a scenario assembly rebuilt against this
  release's harness. The CLI calls Atlas.XUnit by compiled signature instead of locating its
  members by name, and that needs the friend grant only this release's Atlas.XUnit carries. An
  assembly built against an older harness prints one line naming the harness version found, the
  version of the tool that met it and what the runtime threw, then exits 2: update the tool or
  rebuild the test project. atlas stage is unaffected, having called Atlas this way since
  0.11.0, the release that introduced it. That one line replaces three different endings for the
  same case: a raw MissingMethodException or TypeLoadException out of atlas stage, exit 1
  out of atlas fixture, and, in worker mode, silence, with the class-summary events simply
  never arriving. The tool still ships no harness copy of its own, so the assembly's own harness
  version is still the one that runs.

• The XML documentation shipped in the packages now matches the code it describes.
  ScenarioTimeoutException listed Ticks among its throwers, which a fixed tick wait cannot be,
  and said nothing about TicksWaited meaning the host's tick count for a watchdog timeout;
  AtlasSetupException covered only install, mods and staging, not the declaration errors, the
  calls that cannot proceed or the engine drift that also raise it. Ticks and Until
  did not document the argument exceptions they throw, nor that Until first evaluates its
  predicate on the tick after the call; Say deferred its completion guarantee to internal
  remarks a consumer cannot read; JoinPlayer documented one of its four AtlasSetupException
  causes, neither the ScenarioTimeoutException its own inventory wait can raise nor the engine's
  player-name rule; ExecuteCommand did not say it has no tick bound of its own.
  EntitySimulationTicks pointed at a repo path and AtlasModsAttribute at an internal type,
  neither followable from IntelliSense. WorldOptions and DataFileSeed now say which attribute
  writes them, and [AtlasScenario] states the AtlasScenarioBase requirement and what a
  watchdog timeout costs the rest of the class. No behavior changed.

... (truncated)

0.12.1

Fixed

• ScratchSweepTests.Scratch_Should_BeDeletedOnHandOff_When_ANestedClassEndsGreen kept flaking
  on CI after #​103 (six System.TimeoutException failures across the 1.21.7, 1.22.0, 1.22.2 and
  1.22.7 lanes, the last one at exactly 3 min 30 s with the widened bound). The bound was never
  the cause: HostRegistry.GetOrCreateAsync handed a class back a cached host that a later
  ServerHost boot had superseded. Every boot calls BridgeRendezvous.Reset(), which nulls the
  process-wide TickFired event and re-points the engine's statics (ServerMain.Logger,
  ClassRegistry) at the new server, so a host booted while another is live (every
  direct-ServerHost engine test does this) leaves the earlier host pumping but tickless: every
  tick wait on it hangs forever, tick-counted timeouts included, and the rollback capture runs
  outside the scenario watchdog (or, when the engine logs first, it crashes with an NRE attributed
  to the wrong class). The registry only reuses a cached host when the same class asks again
  in-process, which happens in exactly one place: the flaking test's nested run of
  IsolationActivityScenarios after NestedRunnerTests had run that class nested and left its
  restart replacement live. The three failing TRX timelines share the order NestedRunnerTests,
  then only direct-host classes (WorldSaveTests, EntitySimulationTickTests,
  ClientObservationTests), then the flake, and each failure lasted exactly the bound plus
  RunnerDisposal's 30 s idle grace, while passing lanes ran the same test in 11 to 13 s; xunit
  v2 orders test classes randomly per run, hence the intermittency. The registry now disposes and
  reboots a cached host whose boot another host superseded (ServerHost.IsSuperseded, the
  rendezvous identity of its own boot), exactly as for an owner change; SupersededHostTests pins
  the behavior. No bound changed.

Changed

• CI uploads the kept scratch directories' server-main.log files (the post-mortem artifact the
  issue #​83 sweep preserves for red classes) as an artifact when an E2E lane fails; until now they
  stayed on the runner and were lost with it.

0.12.0

Added

• ITestPlayer.Client, a client-side assertion surface with no client process (issue #​100,
  tier 2, from the Caminus field request: its server side drives a thermal overlay through
  HighlightBlocks(player, slot 7, ...), SpawnParticles(...) and a protobuf OverlayPacket
  on mod channel "caminus", none of which a server-only harness could observe). The test
  player's dummy connection already receives every packet a real client would; Atlas now
  drains it through the engine's own DummyTcpNetClient.ReadMessage() on each read and
  decodes with the engine's own serializer: Highlights(slot) (positions and colors of the
  latest highlight packet for the slot, an empty highlight clears it, mirroring the client),
  Particles() (the provider rebuilt as a client would, with position, velocity, quantity
  and color lifted for SimpleParticleProperties), Packets<T>(channel) (mod-channel
  messages resolved through the server's own channel registry and deserialized with the
  game's protobuf-net, T matched by full name so the ModLoader's own copy of the mod dll is
  fine), ChatLines() and Clear(). Records expose the raw packed Color plus a decoded
  Rgba, because the engine's two renderers read the int differently (highlights:
  ColorFromRgba, red in the lowest byte; particles: ToRgba(a, r, g, b), red in bits 16 to
  23, both decompile-verified on 1.21.7/1.22.0/1.22.7). Observations are cleared on a
  RollbackWorld restore (same event-bus hook a cooperating mod uses). TCP channels only.
  Full contract, tap point and engine symbol table in docs/specs/2026-07-17-client-observations.md.

• ITestPlayer.Say(message) (issue #​100): sends a chat line the way a real client's chat
  box does, over the same dummy connection the join sequence uses. First consumer feedback
  on 0.12.0-rc.1's ITestPlayer.Client (Caminus): a scenario driving a command through
  IWorldSession.ExecuteCommand gets the command's return value, but its synthetic console
  caller carries no player, so any reply the handler routes through the calling player
  (args.Caller.Player.SendMessage, or the engine's own status-message echo, which targets
  the same) had nowhere to land - ChatLines() stayed empty and the reply path was
  untestable. Say runs the exact packet a real client sends
  (Packet_Client { Id = 4, Chatline }, decompile-verified byte-identical on
  1.21.7/1.22.3/1.22.7), so the server's real chat/command dispatch runs with the joined
  player behind it and routes replies back through Client.ChatLines() like any other
  capture. Waits internally before returning, in two parts: polls the engine's own
  background packet-parsing thread's inbound queue down to zero (a cross-thread race whose
  latency is wall-clock, not tick, bounded - a fixed-tick wait here measured flaky under a
  loaded test run against 1.21.7), then a fixed 2 ticks for the game-thread-only dispatch
  pass, which is genuinely tick-bounded. A caller reading Client right after
  await player.Say(...) sees the reply with no further wait; full measurement in the
  timing section of docs/specs/2026-07-17-client-observations.md.

Fixed

• ScratchSweepTests.Scratch_Should_BeDeletedOnHandOff_When_ANestedClassEndsGreen (the issue
  #​83 sweep E2E added in #​85) flaked on CI under runner load with System.TimeoutException
  around 2 min 30 s, five times across several VS lanes, always green on rerun and locally.
  Root cause: its nested-runner boot (one real embedded server, the same shape
  TheoryNestedRunnerTests already budgets 3 minutes for) was bounded to 2 minutes for no
  stated reason, tighter than that precedent; under CI load the boot was still in flight at 2
  minutes, and RunnerDisposal's own 30 s idle-wait grace before giving up padded the
  ... (truncated)

0.12.0-rc.2

Added

• ITestPlayer.Say(message) (issue #​100): sends a chat line the way a real client's chat
  box does, over the same dummy connection the join sequence uses. First consumer feedback
  on 0.12.0-rc.1's ITestPlayer.Client (Caminus): a scenario driving a command through
  IWorldSession.ExecuteCommand gets the command's return value, but its synthetic console
  caller carries no player, so any reply the handler routes through the calling player
  (args.Caller.Player.SendMessage, or the engine's own status-message echo, which targets
  the same) had nowhere to land - ChatLines() stayed empty and the reply path was
  untestable. Say runs the exact packet a real client sends
  (Packet_Client { Id = 4, Chatline }, decompile-verified byte-identical on
  1.21.7/1.22.3/1.22.7), so the server's real chat/command dispatch runs with the joined
  player behind it and routes replies back through Client.ChatLines() like any other
  capture. Waits internally before returning, in two parts: polls the engine's own
  background packet-parsing thread's inbound queue down to zero (a cross-thread race whose
  latency is wall-clock, not tick, bounded - a fixed-tick wait here measured flaky under a
  loaded test run against 1.21.7), then a fixed 2 ticks for the game-thread-only dispatch
  pass, which is genuinely tick-bounded. A caller reading Client right after
  await player.Say(...) sees the reply with no further wait; full measurement in the
  timing section of docs/specs/2026-07-17-client-observations.md.

0.12.0-rc.1

Added

• ITestPlayer.Client, a client-side assertion surface with no client process (issue #​100,
  tier 2, from the Caminus field request: its server side drives a thermal overlay through
  HighlightBlocks(player, slot 7, ...), SpawnParticles(...) and a protobuf OverlayPacket
  on mod channel "caminus", none of which a server-only harness could observe). The test
  player's dummy connection already receives every packet a real client would; Atlas now
  drains it through the engine's own DummyTcpNetClient.ReadMessage() on each read and
  decodes with the engine's own serializer: Highlights(slot) (positions and colors of the
  latest highlight packet for the slot, an empty highlight clears it, mirroring the client),
  Particles() (the provider rebuilt as a client would, with position, velocity, quantity
  and color lifted for SimpleParticleProperties), Packets<T>(channel) (mod-channel
  messages resolved through the server's own channel registry and deserialized with the
  game's protobuf-net, T matched by full name so the ModLoader's own copy of the mod dll is
  fine), ChatLines() and Clear(). Records expose the raw packed Color plus a decoded
  Rgba, because the engine's two renderers read the int differently (highlights:
  ColorFromRgba, red in the lowest byte; particles: ToRgba(a, r, g, b), red in bits 16 to
  23, both decompile-verified on 1.21.7/1.22.0/1.22.7). Observations are cleared on a
  RollbackWorld restore (same event-bus hook a cooperating mod uses). TCP channels only.
  Full contract, tap point and engine symbol table in docs/specs/2026-07-17-client-observations.md.

Fixed

• ScratchSweepTests.Scratch_Should_BeDeletedOnHandOff_When_ANestedClassEndsGreen (the issue
  #​83 sweep E2E added in #​85) flaked on CI under runner load with System.TimeoutException
  around 2 min 30 s, five times across several VS lanes, always green on rerun and locally.
  Root cause: its nested-runner boot (one real embedded server, the same shape
  TheoryNestedRunnerTests already budgets 3 minutes for) was bounded to 2 minutes for no
  stated reason, tighter than that precedent; under CI load the boot was still in flight at 2
  minutes, and RunnerDisposal's own 30 s idle-wait grace before giving up padded the
  observed failure to the reported 2:30. Bounded to 3 minutes to match
  TheoryNestedRunnerTests, the smallest change that removes the tight bound without loosening
  a real signal.

• Atlas builds against Vintage Story 1.22.4 through 1.22.7 again (the 1.22.4 API annotated
  the inventory indexer as nullable, which the compile treated as errors: a guarded read in
  TestPlayer.GiveItem and null-forgiving reads in the rollback tests). The per-push CI
  matrix gains a 1.22.7 lane (latest stable); 1.22.4 through 1.22.6 join the weekly sweep.
  Caught by an on-demand sweep the day the gap was noticed: all four versions verdicted
  "incompatible (API)" on what turned out to be seven nullability diagnostics.

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