Update repository from Library.Template

.agents/skills/bundle-dependency-prs/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: bundle-dependency-prs
+description: Fix broken dependency update PRs and aggregate the ones that work into one PR.
+disable-model-invocation: true
+---
+
+# Instructions
+
+You have two goals:
+
+1. Get all dependency PRs to a state where their PR checks pass.
+2. Aggregate dependency PRs with passing checks into just one PR.
+
+You can identify dependency update PRs by those authored by `dependabot` or `renovate`.
+
+You'll find instructions for building and validating the repo in the [CONTRIBUTING.md](../../../CONTRIBUTING.md) doc.
+Always validate your changes locally before pushing them to the remote repository.
+
+When writing PR bodies or comments, avoid unmatched markdown code fences. Keep markdown well-formed.
+
+For purposes of assessing PR readiness by its PR checks, consider docfx related checks to be irrelevant.
+If a docfx check fails but all other checks succeed, then that is a 'successful' dependency update PR.
+
+## Fix up dependency PRs with failing checks
+
+Before aggregating PRs, first try to fix any individual dependency update PRs with failing build/test checks.
+
+1. For the dependency PRs with failing build or test PR checks, check out their source branch and fix any issues.
+2. Push your fixes as fresh commits to the individual dependency PRs.
+   If pushing to a repo in the `microsoft` org when the PR is authored by `renovate`, follow-up the push with a PR comment that says exactly this: "/azp run" which triggers PR checks to re-run.
+3. If you can't fix a particular PR, add a comment to the PR describing your attempt and outcome.
+
+## Group dependency PRs that are ready to go
+
+Your next goal is to collect all the dependency updates that are ready to go into a single PR.
+
+1. Prepare a local branch called `bulkDepUpdates`.
+   1. Consider that a remote branch by the same name may already exist. If it does, base your local branch on it.
+   2. Merge `origin/main` into this branch.
+   3. Resolve any conflicts.
+2. For the dependency PRs whose build and test PR checks already pass, merge them into the `bulkDepUpdates` branch.
+   Consider that your local branch may have already merged an equivalent PR in the past (from a past run). If so, you should skip merging that PR.
+   Resolve any conflicts.
+   Build and run tests to validate your branch.
+3. Push the branch.
+4. Create a PR, if one does not already exist.

.agents/skills/update-library-template/template-release-notes.md

@@ -0,0 +1,84 @@
+# Template release notes
+
+This file will describe significant changes in Library.Template as they are introduced, especially if they require special consideration when merging updates into existing repos.
+This file is referenced by update-library-template.prompt.md and should remain in place to facilitate future merges, whether done manually or by AI.
+
+## Solution rename
+
+Never leave a Library.slnx file in the repository.
+You might even see one there even though this particular merge didn't bring it in.
+This can be an artifact of having renamed Library.sln to Library.slnx in the template repo, but ultimately the receiving repo should have only one .sln or .slnx file, with a better name than `Library`.
+Delete any `Library.slnx` that you see.
+Migrate an `.sln` in the repo root to `.slnx` using this command:
+
+```ps1
+dotnet solution EXISTING.sln migrate
+```
+
+This will create an EXISTING.slnx file. `git add` that file, then `git rm` the old `.sln` file.
+Sometimes a repo will reference the sln filename in a script or doc somewhere.
+Search the repo for such references and update them to the slnx file.
+
+## Migrating from xUnit to TUnit
+
+The template now uses TUnit with Microsoft.Testing.Platform instead of the xUnit test runner.
+When merging this update into an existing repository, migrate all test projects and repo-specific test automation.
+Follow the [TUnit xUnit migration guide](https://tunit.dev/docs/migration/xunit), including its automated migration code fixes.
+
+* Replace xUnit runner/framework package references with `TUnit.Engine` and set `<OutputType>Exe</OutputType>` in each test project.
+  Remove obsolete runner dependencies such as `xunit.runner.visualstudio`, `Microsoft.NET.Test.Sdk`, and `coverlet.collector`, along with `xunit.runner.json`.
+  Reconcile central package versions with the template's `Directory.Packages.props`.
+* Existing xUnit assertions can remain: the template retains `xunit.v3.assert`, using `xunit.v3.assert.aot` for .NET 9 and later.
+  Keep `Xunit` imports for assertions, but use TUnit for test attributes and lifecycle APIs.
+* Convert `[Fact]` and `[Theory]` to `[Test]`, and `[InlineData]` to `[Arguments]`.
+  Migrate member/class data sources, traits, fixtures, collection behavior, setup/teardown, and test output according to the migration guide.
+  Review tests that depend on xUnit's execution ordering or parallelization rules; do not assume those rules carry over.
+* Merge the `global.json` Microsoft.Testing.Platform runner setting, test directory build files, traversal projects, and updated PowerShell/YAML automation.
+  Keep every test project in the repository's solution for managed test runs.
+  The traversals discover `.csproj` files under `src` and `test`; adjust discovery if your projects live elsewhere or use another project language.
+* Update custom test commands and filters.
+  VSTest `--filter` expressions do not work with this runner; pass TUnit filters after `--`, for example `-- --treenode-filter "/*/*/ClassName/MethodName"`.
+  Replace any xUnit-specific CI result or coverage handling with the template's Microsoft.Testing.Platform integration.
+* Validate managed tests and coverage, then run `dotnet publish tools\dirs.proj -c Release` and `.\tools\dotnet-test-cloud.ps1 -Configuration Release -IncludeNativeAOT`.
+  Test projects targeting .NET 8 or later are eligible for NativeAOT publication by default.
+  If a project cannot support NativeAOT, set `<PublishNativeAOTTests>false</PublishNativeAOTTests>` in its project file; it will still run as managed tests.
+
+## NativeAOT compatibility validation
+
+Shipping projects now set `IsAotCompatible` for target frameworks compatible with .NET 8.
+Apply the same conditional property to each shipping project that is intended to support NativeAOT, then resolve all trim and AOT analyzer warnings rather than suppressing them broadly.
+
+The new `test/AotCompatibilityTest` project catches NativeAOT compiler warnings that library analyzers may not report.
+Keep it in the solution, add every NativeAOT-compatible shipping assembly as a `TrimmerRootAssembly`, and retain its publishable entry in `test/dirs.proj`.
+CI validates this project through the existing traversal publish on Windows, Linux, and macOS; it is intentionally marked `IsTestProject=false` because publishing successfully is the test.
+
+## NativeAOT opt-out and AI merge guidance
+
+Not every repo wants to take on NativeAOT readiness or NativeAOT-published test validation.
+If a receiving repo does not intend to support NativeAOT, opt out explicitly instead of inheriting the template's defaults.
+
+For test projects that should remain managed-only:
+
+* Set `<PublishNativeAOTTests>false</PublishNativeAOTTests>` in the project file or in a repo-level `Directory.Build.props`.
+* Leave the managed test project in the solution so usual IL-based testing continues to work.
+* Keep `dotnet test` and the managed coverage flow unchanged; only the NativeAOT publish step is disabled.
+
+For shipping libraries that do not want NativeAOT compatibility analysis:
+
+* Remove `IsAotCompatible` from the project, or set it only for specific target frameworks that truly support NativeAOT.
+* Do not add new AOT compatibility warnings to the build if the library is not intended to be AOT-compatible.
+* If the repo does not target .NET 8 or later, the property should be omitted entirely rather than applied unconditionally.
+
+For the compatibility project itself:
+
+* Remove the `test/AotCompatibilityTest` project from the solution if NativeAOT validation is out of scope.
+* Remove its entry from `test/dirs.proj` so the traversal publish no longer publishes it.
+* Keep the project only when the repo intends to validate shipping assemblies under NativeAOT in CI.
+
+When merging this template into a downstream repo, the AI assistant should ask whether NativeAOT is a relevant target for that repo before applying these changes if `IsAotCompatible` is not already set by any of the projects.
+If the answer is no, it should apply the opt-out steps above instead of blindly keeping the NativeAOT defaults.
+This is especially important for repos that are not shipping a NativeAOT-ready library or that cannot support the extra publish-time validation in CI.
+If the repo owner is unsure about NativeAOT support, you might offer to test the repo for NativeAOT readiness by attempting a NativeAOT publish of the relevant projects and observing whether any compatibility warnings or errors are produced.
+
+In the event the user elects for NativeAOT targeting, make efforts to get tests to work under NativeAOT as well so the shipping code can confidently advertise its NativeAOT compatibility.
+If aspects of the library or tests make successful builds, publish or test runs problematic, discuss this with the repo owner before making significant changes or giving up on NativeAOT support.

.config/dotnet-tools.json

@@ -3,42 +3,42 @@
   "isRoot": true,
   "tools": {
     "powershell": {
-      "version": "7.6.2",
+      "version": "7.6.6",
       "commands": [
         "pwsh"
       ],
       "rollForward": false
     },
     "dotnet-coverage": {
-      "version": "18.7.0",
+      "version": "18.11.2",
       "commands": [
         "dotnet-coverage"
       ],
       "rollForward": false
     },
     "nbgv": {
-      "version": "3.9.50",
+      "version": "3.10.94",
       "commands": [
         "nbgv"
       ],
       "rollForward": false
     },
     "docfx": {
-      "version": "2.78.5",
+      "version": "2.81.0",
       "commands": [
         "docfx"
       ],
       "rollForward": false
     },
     "nerdbank.dotnetrepotools": {
-      "version": "1.4.1",
+      "version": "1.5.42",
       "commands": [
         "repo"
       ],
       "rollForward": false
     },
     "dotnet-symbol": {
-      "version": "9.0.661903",
+      "version": "10.0.745401",
       "commands": [
         "dotnet-symbol"
       ],

.github/renovate.json

@@ -4,5 +4,33 @@
 		"github>microsoft/vs-renovate-presets:microbuild",
 		"github>microsoft/vs-renovate-presets:vs_main_dependencies"
 	],
-	"packageRules": []
+	"labels": ["dependencies"],
+	"packageRules": [
+		{
+			"matchPackageNames": ["nbgv", "nerdbank.gitversioning"],
+			"groupName": "nbgv and nerdbank.gitversioning updates"
+		},
+		{
+			"matchPackageNames": ["xunit*"],
+			"groupName": "xunit"
+		},
+		{
+			"matchPackageNames": ["tunit*"],
+			"groupName": "tunit",
+			"schedule": ["on the first day of the month"]
+		},
+		{
+			"matchPackageNames": ["Microsoft.Testing.Extensions.*"],
+			"groupName": "Microsoft Testing Platform"
+		},
+		{
+			"matchDatasources": ["dotnet-version", "docker"],
+			"matchDepNames": ["dotnet-sdk", "mcr.microsoft.com/dotnet/sdk"],
+			"groupName": "Dockerfile and global.json updates"
+		},
+		{
+			"matchPackageNames": ["*"],
+			"allowedVersions": "!/-g[a-f0-9]+$/"
+		}
+	]
 }

.github/workflows/copilot-setup-steps.yml

@@ -16,7 +16,7 @@ on:
 jobs:
   # The job MUST be called `copilot-setup-steps` or it will not be picked up by Copilot.
   copilot-setup-steps:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-26.04
     # Set the permissions to the lowest permissions possible needed for your steps.
     # Copilot will be given its own token for its operations.
     permissions:
@@ -26,7 +26,7 @@ jobs:
     # You can define any steps you want, and they will run before the agent starts.
     # If you do not check out your code, Copilot will do this for you.
     steps:
-    - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+    - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
       with:
         fetch-depth: 0 # avoid shallow clone so nbgv can do its work.
     - name: ⚙ Install prerequisites

.github/workflows/libtemplate-update.yml

@@ -12,12 +12,12 @@ on:
 
 jobs:
   merge:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-26.04
     permissions:
       contents: write
       pull-requests: write
     steps:
-    - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+    - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
       with:
         fetch-depth: 0 # avoid shallow clone so nbgv can do its work.
 

.github/copilot-instructions.md → AGENTS.md

@@ -13,11 +13,10 @@
 
 ## Testing
 
-**IMPORTANT**: This repository uses Microsoft.Testing.Platform (MTP v2) with xunit v3. Traditional `--filter` syntax does NOT work. Use the options below instead.
+**IMPORTANT**: This repository uses TUnit with Microsoft.Testing.Platform (MTP v2). Traditional `--filter` syntax does NOT work. Use the options below instead.
 
 * There should generally be one test project (under the `test` directory) per shipping project (under the `src` directory). Test projects are named after the project being tested with a `.Tests` suffix.
-* Tests use xunit v3 with Microsoft.Testing.Platform (MTP v2). Traditional VSTest `--filter` syntax does NOT work.
-* Some tests are known to be unstable. When running tests, you should skip the unstable ones by using `-- --filter-not-trait "FailsInCloudTest=true"`.
+* Tests use TUnit with Microsoft.Testing.Platform (MTP v2), while retaining xUnit assertions. Traditional VSTest `--filter` syntax does NOT work.
 
 ### Running Tests
 
@@ -46,7 +45,7 @@ dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Micr
 dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release -- --filter-method "*Pattern*"
 ```
 
-**Run tests with a specific trait** (equivalent to category filtering):
+**Run tests with a specific property**:
 ```bash
 dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release -- --filter-trait "TraitName=value"
 ```
@@ -67,13 +66,11 @@ cd test/Microsoft.VisualStudio.SolutionPersistence.Tests
 dotnet run --no-build -c Release --framework net8.0 -- --list-tests
 ```
 
-**Key points about test filtering with MTP v2 / xunit v3**:
+**Key points about test filtering with TUnit / MTP v2**:
 - Options after `--` are passed to the test runner, not to `dotnet test`
-- Use `--filter-method`, `--filter-class`, `--filter-namespace` for simple filtering
-- Use `--filter-trait` and `--filter-not-trait` for trait-based filtering (replaces `--filter "TestCategory=..."`)
+- Use `--treenode-filter` to select tests by assembly, namespace, class, method, or property
 - Traditional VSTest `--filter` expressions do NOT work
-- Wildcards `*` are supported at the beginning and/or end of filter values
-- Multiple simple filters of the same type use OR logic, different types combine with AND
+- Wildcards `*` are supported in tree node segments
 - See `--help` for query filter language for advanced scenarios
 
 ## Coding style