Library.template/2026 03 24

.config/dotnet-tools.json

@@ -3,32 +3,39 @@
   "isRoot": true,
   "tools": {
     "powershell": {
-      "version": "7.5.3",
+      "version": "7.5.4",
       "commands": [
         "pwsh"
       ],
       "rollForward": false
     },
     "dotnet-coverage": {
-      "version": "17.14.2",
+      "version": "18.5.2",
       "commands": [
         "dotnet-coverage"
       ],
       "rollForward": false
     },
     "nbgv": {
-      "version": "3.7.115",
+      "version": "3.9.50",
       "commands": [
         "nbgv"
       ],
       "rollForward": false
     },
     "docfx": {
-      "version": "2.78.3",
+      "version": "2.78.5",
       "commands": [
         "docfx"
       ],
       "rollForward": false
+    },
+    "nerdbank.dotnetrepotools": {
+      "version": "1.2.1",
+      "commands": [
+        "repo"
+      ],
+      "rollForward": false
     }
   }
 }

.github/Prime-ForCopilot.ps1

@@ -0,0 +1,5 @@
+if ((git -C $PSScriptRoot rev-parse --is-shallow-repository) -eq 'true')
+{
+    Write-Host "Shallow clone detected, disabling NBGV Git engine so the build can succeed."
+    $env:NBGV_GitEngine='Disabled'
+}

.github/copilot-instructions.md

@@ -3,7 +3,8 @@
 ## High level guidance
 
 * Review the `CONTRIBUTING.md` file for instructions to build and test the software.
-* Set the `NBGV_GitEngine` environment variable to `Disabled` before running any `dotnet` or `msbuild` commands.
+* Run the `.github/Prime-ForCopilot.ps1` script (once) before running any `dotnet` or `msbuild` commands.
+  If you see any build errors about not finding git objects or a shallow clone, it may be time to run this script again.
 
 ## Software Design
 
@@ -12,9 +13,68 @@
 
 ## Testing
 
-* 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 `.Test` suffix.
-* Tests should use the Xunit testing framework.
-* Some tests are known to be unstable. When running tests, you should skip the unstable ones by running `dotnet test --filter "TestCategory!=FailsInCloudTest"`.
+**IMPORTANT**: This repository uses Microsoft.Testing.Platform (MTP v2) with xunit v3. 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"`.
+
+### Running Tests
+
+**Run all tests**:
+```bash
+dotnet test --no-build -c Release
+```
+
+**Run tests for a specific test project**:
+```bash
+dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release
+```
+
+**Run a single test method**:
+```bash
+dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release -- --filter-method ClassName.MethodName
+```
+
+**Run all tests in a test class**:
+```bash
+dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release -- --filter-class ClassName
+```
+
+**Run tests with wildcard matching** (supports wildcards at beginning and/or end):
+```bash
+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):
+```bash
+dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release -- --filter-trait "TraitName=value"
+```
+
+**Exclude tests with a specific trait** (skip unstable tests):
+```bash
+dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release -- --filter-not-trait "TestCategory=FailsInCloudTest"
+```
+
+**Run tests for a specific framework only**:
+```bash
+dotnet test --project test/Microsoft.VisualStudio.SolutionPersistence.Tests/Microsoft.VisualStudio.SolutionPersistence.Tests.csproj --no-build -c Release --framework net8.0
+```
+
+**List all available tests without running them**:
+```bash
+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**:
+- 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=..."`)
+- 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
+- See `--help` for query filter language for advanced scenarios
 
 ## Coding style
 

.github/prompts/repo-merge-notes.md

@@ -0,0 +1,51 @@
+# Repo-specific merge notes for vs-solutionpersistence
+
+This file contains notes specific to this repo that help resolve Library.Template merge conflicts.
+It is referenced by `update-library-template.prompt.md` and kept separate to avoid merge conflicts with template-owned files.
+
+## Files deleted locally that the template will try to update
+
+These show as "deleted by us" conflicts. Here are the known cases:
+
+* **GitHub Actions CI files** (`.github/workflows/docs.yml`, `.github/workflows/docs_validate.yml`, `.github/actions/publish-artifacts/action.yaml`): This repo uses Azure Pipelines, not GitHub Actions for CI/CD. Keep these deleted.
+* **`.github/workflows/libtemplate-update.yml`**: Automatic Library.Template merge workflow. Should be **kept/restored** — it was mistakenly deleted in a past merge and is useful infrastructure.
+* **`.github/renovate.json`**: Dependency update automation. Should be kept/restored if missing.
+* **`test/Library.Tests/Library.Tests.csproj`**: Template's generic test project. Re-delete it, but apply any relevant changes to `test/Microsoft.VisualStudio.SolutionPersistence.Tests/`.
+
+## `azure-pipelines/build.yml`
+
+The template includes `expand-template.yml` references in build.yml (Windows, Linux, macOS jobs).
+This repo is not a template and does not have `Expand-Template.ps1`, so always remove these lines after accepting template changes:
+```yaml
+  - template: expand-template.yml
+```
+
+## `azure-pipelines/vs-insertion.yml`
+
+The template has a placeholder for `InsertionReviewers`. This repo customizes it to include the team:
+```yaml
+InsertionReviewers: $(Build.RequestedFor),VS Core - Solution Experience
+```
+When merging, keep the team name but accept any other new properties the template adds (e.g. `CustomScriptExecutionCommand`).
+
+## Researching template changes
+
+When a conflict is hard to understand, check the Library.Template commit history for the specific file:
+```
+https://github.com/aarnott/Library.Template/commits/microbuild/<path/to/file>
+```
+This shows *why* changes were made and helps decide whether to accept them.
+You can also compare the template's full current version of a file:
+```bash
+git show libtemplate/microbuild:<path/to/file>
+```
+
+## History of past merge mistakes
+
+The commit `2fb9c3d` ("Remove github actions", Feb 2025) bulk-deleted all GitHub workflow files.
+Some were genuinely unused (GitHub Actions CI, GitHub Pages deployment), but it also deleted useful automation:
+* `.github/workflows/libtemplate-update.yml` — Automatic weekly Library.Template merge PRs
+* `.github/workflows/docs_validate.yml` — Docfx link validation
+* `.github/renovate.json` — Renovate bot dependency updates
+
+These have been restored. If they show up as conflicts again in future merges, keep them.

.github/prompts/template-release-notes.md

@@ -0,0 +1,20 @@
+# 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.

.github/prompts/update-library-template.prompt.md

@@ -0,0 +1,76 @@
+---
+description: Merges the latest Library.Template into this repo (at position of HEAD) and resolves conflicts.
+---
+
+# Instructions
+
+1. Run `tools/MergeFrom-Template.ps1`
+2. Resolve merge conflicts, taking into account conflict resolution policy below.
+3. Validate the changes, as described in the validation section below.
+4. Committing your changes (if applicable).
+
+## Conflict resolution policy
+
+There may be special notes in `.github/prompts/template-release-notes.md` that describe special considerations for certain files or scenarios to help you resolve conflicts appropriately.
+Always refer to that file before proceeding.
+In particular, focus on the *incoming* part of the file, since it represents the changes from the Library.Template that you are merging into your repo.
+Also refer to `.github/prompts/repo-merge-notes.md` for notes specific to this repo (e.g. which deleted files to keep, which customizations to preserve).
+Also consider that some repos choose to reject certain Library.Template patterns.
+For example the template uses MTPv2 for test projects, but a repo might have chosen not to adopt that.
+When resolving merge conflicts, consider whether it looks like the relevant code file is older than it should be given the changes the template is bringing in.
+Ask the user when in doubt as to whether the conflict should be resolved in favor of 'catching up' with the template or keeping the current changes.
+
+Use #runSubagent to analyze and resolve merge conflicts across files in parallel.
+
+### Keep Current files
+
+Conflicts in the following files should always be resolved by keeping the current version (i.e. discard incoming changes):
+
+* README.md
+
+### Deleted files
+
+Very typically, when the incoming change is to a file that was deleted locally, the correct resolution is to re-delete the file.
+
+In some cases however, the deleted file may have incoming changes that should be applied to other files.
+The `test/Library.Tests/Library.Tests.csproj` file is very typical of this.
+Changes to this file should very typically be applied to any and all test projects in the repo.
+You are responsible for doing this in addition to re-deleting this template file.
+
+### Files deleted by the template
+
+When the template deletes a file that exists locally, check the template's commit history to understand *why* it was removed.
+Use the GitHub commit history page for the file (e.g. `https://github.com/aarnott/Library.Template/commits/microbuild/path/to/file`) to find the relevant commit.
+If the template restructured or centralized the functionality (e.g. OptProf pipelines moved to a centralized VS pipeline), accept the deletion.
+If the file contains repo-specific customizations not present in the template, keep it.
+
+### Files deleted locally but updated by the template
+
+These show as "deleted by us" conflicts. Refer to `.github/prompts/repo-merge-notes.md` for this repo's specific decisions on which files to keep or re-delete.
+
+## Validation
+
+Validate the merge result (after resolving any conflicts, if applicable).
+Use #runSubagent for each step.
+
+1. Verify that `dotnet restore` succeeds. Fix any issues that come up.
+2. Verify that `dotnet build` succeeds.
+3. Verify that tests succeed by running `tools/dotnet-test-cloud.ps1`.
+
+While these validations are described using `dotnet` CLI commands, some repos require using full msbuild.exe.
+You can detect this by checking the `azure-pipelines/dotnet.yml` or `.github/workflows/build.yml` files for use of one or the other tool.
+
+You are *not* responsible for fixing issues that the merge did not cause.
+If validation fails for reasons that seem unrelated to the changes brought in by the merge, advise the user and ask how they'd like you to proceed.
+That said, sometimes merges will bring in SDK or dependency updates that can cause breaks in seemingly unrelated areas.
+In such cases, you should investigate and solve the issues as needed.
+
+## Committing your changes
+
+If you have to make any changes for validations to pass, consider whether they qualify as a bad merge conflict resolution or more of a novel change that you're making to work with the Library.Template update.
+Merge conflict resolution fixes ideally get amended into the merge commit, while novel changes would go into a novel commit after the merge commit.
+
+Always author your commits using `git commit --author "🤖 Copilot <no-reply@github.com>"` (and possibly other parameters).
+Describe the nature of the merge conflicts you encountered and how you resolved them in your commit message.
+
+Later, if asked to review pull request validation breaks, always author a fresh commit with each fix that you push, unless the user directs you to do otherwise.

.github/renovate.json

@@ -0,0 +1,8 @@
+{
+	"$schema": "https://docs.renovatebot.com/renovate-schema.json",
+	"extends": [
+		"github>microsoft/vs-renovate-presets:microbuild",
+		"github>microsoft/vs-renovate-presets:vs_main_dependencies"
+	],
+	"packageRules": []
+}

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

@@ -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@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5
+    - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
       with:
         fetch-depth: 0 # avoid shallow clone so nbgv can do its work.
     - name: ⚙ Install prerequisites