[main] Update dependencies from dotnet/arcade, dotnet/arcade-services, dotnet/dnceng

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/arcade

• Subscription: e1494738-68cf-4cfe-3661-08d8e287a9c2
• Build: 20260427.3 (312097)
• Date Produced: April 27, 2026 5:34:26 PM UTC
• Commit: f5d199ccaf897f1ab275ce683b4151be403458b5
• Branch: main

• Dependency Updates:
  • From 11.0.0-beta.26211.1 to 11.0.0-beta.26227.3
    • Microsoft.DotNet.Arcade.Sdk
    • Microsoft.DotNet.Helix.Sdk

From https://github.com/dotnet/arcade-services

• Subscription: 4aecaf13-3af0-4dee-bf73-08d8e287ac39
• Build: 20260422.1 (311383)
• Date Produced: April 22, 2026 12:24:59 PM UTC
• Commit: c6c2b88a15ff0bddf33824eb2402969d9b9f3f4c
• Branch: production

• Dependency Updates:
  • From 1.1.0-beta.26214.2 to 1.1.0-beta.26222.1
    • Microsoft.DotNet.DarcLib
    • Microsoft.DotNet.ProductConstructionService.Client

From https://github.com/dotnet/dnceng

• Subscription: 2dcf631d-13b8-4cac-ab86-08dcc13e8b5d
• Build: 20260423.1 (311598)
• Date Produced: April 23, 2026 5:49:55 PM UTC
• Commit: a448fd88c48f2a366ba29eba0008e9ac938ecc59
• Branch: main

• Dependency Updates:
  • From 1.1.0-beta.26216.2 to 1.1.0-beta.26223.1
    • Microsoft.DncEng.SecretManager

[ViktorHofer]

cc @agocke & @Youssef1313

[mmitche]

I saw this in arcarde-validation yesterday. The agent decided to fix it like:

dotnet/arcade-validation@0dd07f0

Let me know if this is not the right fix here.

[Youssef1313]

The problem here is likely introduced by #16734 and #16754 sounds like the right fix. However, I have few doubts about #16734:

• For xunit 2, I'm not sure if using the xunit.v3 assert package can cause issues.
  • Is it well supported by xunit? (cc @bradwilson)
  • Is it going to break any repos? For example, if a repo was explicitly adding the PackageReference to the xunit 2 assert package, they might break. However, this is likely "fixable" on consuming repos. Still, it's a potential break.
  • The API surface might be different, or even some behaviors/features might be different. So this feels aggressive and might break repos?
• For xunit 3, the concern about the API surface, behavior, or feature differences between xunit.v3.assert and xunit.v3.assert.aot still applies.

[bradwilson]

Is it well supported by xunit?

While v2 and v3 were both being co-released, the source was the same (it comes from a Git submodule that was shared with both projects). The only assertion at that time that was in v3 that would not "work" in v2 were the dynamic skips, since that requires engine cooperation. (Calling Assert.Skip under v2 would've just failed the test, since it throws SkipException.) So this API for certain would be "problematic", though very obvious to see.

We previously "enabled" Assert.Skip via <DefineConstants>XUNIT_SKIP</DefineConstants> but we've since moved on in the repo to only support v3 via source (anybody who wants v2 via source has to stick to a tag/branch and not use main), but again, the worst thing that happens is a test which someone wanted skipped actually becomes failed, which should be easily noticable.

I'm not aware of anything else that would behave incorrectly if you used the v3 assertions with v2.

Is it going to break any repos? For example, if a repo was explicitly adding the PackageReference to the xunit 2 assert package, they might break.

They would definitely break without some intervention, since both would define Xunit.Assert and there would be naming collisions.

If the intention is to support v2, then using the v2 assertion library is the correct answer. Arbitrarily pulling the v3 assertion library really isn't a reusable strategy. It's fine for an end consumer who knows what they're doing, but definitely not something you'd want to propagate. Your consumers would need to know to bring in xunit.core + xunit.v3.assert instead of xunit to prevent the doubled up assertion problem.

For xunit 3, the concern about the API surface, behavior, or feature differences between xunit.v3.assert and xunit.v3.assert.aot still applies.

Yes, they're definitely quite different. Assert.Equivalent goes away entirely, and the compile-time API surface changes a decent amount (though I obviously tried to do my best to ensure things just recompiled fine).

[ViktorHofer]

Thanks @bradwilson for sharing your expertise. @Youssef1313 / @agocke please prioritize unblocking this PR. We need to get it in for some future work in arcade.

[Youssef1313]

I personally would lean towards reverting #16734 for now, and discuss it to consider a balanced way to move forward.

I would need to understand who are the current consumers of AOT assertions? Is it solely runtime? Are these projects that need AOT assertions on xunit.v3 already?

If all AOT consumers we care about are xunit.v3, then my suggestion would be:

• Drop our AOT fork, as done in Remove Microsoft.DotNet.XUnitAssert #16734 already.
• Approach xunit 2 differently from how Remove Microsoft.DotNet.XUnitAssert #16734 did, by simply always referencing xunit.assert and provide no AOT support. If really needed, we must gate xunit.v3.assert.aot under an MSBuild property.
• Approach xunit 3 differently from how Remove Microsoft.DotNet.XUnitAssert #16734 did. Instead of switching the package solely based on TargetFrameworkIdentifier, we have an MSBuild property that opts in to using the AOT package, with the normal package being the default.

[Youssef1313]

#16763 might be a good balance (and doesn't involve a complete revert of #16734)

[ViktorHofer]

I would need to understand who are the current consumers of AOT assertions? Is it solely runtime?

Yes, from what I know that's just dotnet/runtime. Andy introduced that forked project for AOT tests there.

[mmitche]

This is currently blocking the 10.0.8 build from publishing (need the update here for channel publishing)