diff --git a/catalog/Tools/Official-DotNet-MSBuild/agents/build-perf/AGENT.md b/catalog/Tools/Official-DotNet-MSBuild/agents/build-perf/AGENT.md index f8b85b1..72a302f 100644 --- a/catalog/Tools/Official-DotNet-MSBuild/agents/build-perf/AGENT.md +++ b/catalog/Tools/Official-DotNet-MSBuild/agents/build-perf/AGENT.md @@ -35,6 +35,9 @@ Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the ### Alternate flow — text-log replay (when MCP is unavailable) +Use `troubleshoot-binlog-mcp` if the user wants to repair the connection. If repair +is blocked, declined, or unnecessary, continue performance analysis with replay. + 1. Replay to diagnostic log: `dotnet msbuild perf-baseline.binlog -noconlog -fl -flp:v=diag;logfile=full.log;performancesummary` 2. `grep 'Target Performance Summary' -A 50 full.log` → find dominant targets and their cumulative time 3. `grep 'Task Performance Summary' -A 50 full.log` → find dominant tasks diff --git a/catalog/Tools/Official-DotNet-MSBuild/agents/msbuild/AGENT.md b/catalog/Tools/Official-DotNet-MSBuild/agents/msbuild/AGENT.md index c65d5ec..f68736a 100644 --- a/catalog/Tools/Official-DotNet-MSBuild/agents/msbuild/AGENT.md +++ b/catalog/Tools/Official-DotNet-MSBuild/agents/msbuild/AGENT.md @@ -36,6 +36,7 @@ Classify the user's request and route to the appropriate specialist: | User Intent | Route To | |------------|----------| +| Binlog MCP won't connect, `CONNECTION_CLOSED`, or binlog tools are missing | This agent + `troubleshoot-binlog-mcp` skill | | Build failed, errors to diagnose | This agent + `binlog-failure-analysis` skill | | Build is slow, optimize performance | `build-perf` agent + `build-perf-baseline` skill (start with baseline) | | Review/clean up project files | `msbuild-code-review` agent (specialized code review) | @@ -70,6 +71,8 @@ When answering questions about MSBuild syntax, properties, or behavior, use `#to This agent has access to a comprehensive set of troubleshooting and optimization skills: ### Build Failure Skills + +- `troubleshoot-binlog-mcp` — Binlog MCP startup/connection diagnosis, without requiring a binlog - `binlog-failure-analysis` — Binary log analysis for failure diagnosis - `binlog-generation` — Binary log generation conventions diff --git a/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-failure-analysis/SKILL.md b/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-failure-analysis/SKILL.md index 768e876..e2b597b 100644 --- a/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-failure-analysis/SKILL.md +++ b/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-failure-analysis/SKILL.md @@ -1,6 +1,6 @@ --- name: binlog-failure-analysis -description: "Analyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), non-MSBuild build systems." +description: "Analyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), binlog MCP startup or connection failures (use troubleshoot-binlog-mcp), non-MSBuild build systems." license: MIT --- @@ -9,7 +9,9 @@ license: MIT This skill diagnoses MSBuild build failures from a `.binlog` file. The preferred path uses the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) which is bundled with this plugin. If the MCP server is -not available, fall back to the **binlog replay** workflow at the bottom. +not available, use `troubleshoot-binlog-mcp` to diagnose startup when repair is wanted. +If repair is blocked, declined, or unnecessary for this task, continue with the +**binlog replay** workflow at the bottom. ## Primary workflow — binlog MCP diff --git a/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-generation/SKILL.md b/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-generation/SKILL.md index 0d18266..418ae0f 100644 --- a/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-generation/SKILL.md +++ b/catalog/Tools/Official-DotNet-MSBuild/skills/binlog-generation/SKILL.md @@ -1,6 +1,6 @@ --- name: binlog-generation -description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead)." +description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead), binlog MCP startup failures (use troubleshoot-binlog-mcp)." license: MIT --- diff --git a/catalog/Tools/Official-DotNet-MSBuild/skills/build-perf-diagnostics/SKILL.md b/catalog/Tools/Official-DotNet-MSBuild/skills/build-perf-diagnostics/SKILL.md index 22fdb70..901bc6c 100644 --- a/catalog/Tools/Official-DotNet-MSBuild/skills/build-perf-diagnostics/SKILL.md +++ b/catalog/Tools/Official-DotNet-MSBuild/skills/build-perf-diagnostics/SKILL.md @@ -9,6 +9,9 @@ license: MIT 1. **Generate a binlog**: `dotnet build /bl:{} -m` 2. Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) which is bundled with this plugin +If the server cannot connect, use `troubleshoot-binlog-mcp` when startup repair is +wanted. If repair is blocked, declined, or unnecessary, use the replay flow below. + ### Alternate flow when MCP is unavailable: binlog replay to text logs 1. **Generate a binlog**: `dotnet build /bl:{} -m` diff --git a/catalog/Tools/Official-DotNet-MSBuild/skills/troubleshoot-binlog-mcp/SKILL.md b/catalog/Tools/Official-DotNet-MSBuild/skills/troubleshoot-binlog-mcp/SKILL.md new file mode 100644 index 0000000..fb490c3 --- /dev/null +++ b/catalog/Tools/Official-DotNet-MSBuild/skills/troubleshoot-binlog-mcp/SKILL.md @@ -0,0 +1,128 @@ +--- +name: troubleshoot-binlog-mcp +description: "Diagnose dotnet-msbuild binlog MCP startup failures. USE FOR: CONNECTION_CLOSED, binlog server won't connect, missing binlog tools, Microsoft.AITools.BinlogMcp not found, dnx launch errors. Checks workspace SDK, feeds, and source mapping without bypassing policy. DO NOT USE FOR: errors inside a binlog (use binlog-failure-analysis), capturing binlogs (use binlog-generation), unrelated MCP servers." +license: MIT +--- + +# Troubleshoot Binlog MCP Startup + +Explain why the plugin's binlog MCP server cannot connect and give an evidence-based, +policy-safe recovery. This diagnoses the **server launch**, not failures recorded in a build. +No binlog file or project build is needed. + +This skill runs on demand. It cannot see a host error that was never exposed to the agent, +inject session-start context, or guarantee activation merely because a plugin was installed. + +## 1. Establish what failed + +Use the user's error and any host MCP status or startup logs already available. +`CONNECTION_CLOSED` alone says that the transport closed, not why. Do not translate it +directly into "package missing." + +- If the binlog server is connected and its tools are discoverable, stop startup troubleshooting. + Continue the original binlog analysis; do not change a working setup. +- If the plugin's skills loaded but its binlog server did not, continue below. +- If the plugin itself is not installed/enabled or no server is registered, address that host + configuration first. Do not diagnose NuGet package resolution without a launch attempt. +- If execution or host logs are unavailable, explain that limit and give the next command for + the user to run. Never claim to have inspected logs or repaired a connection. + +## 2. Match the host's workspace and SDK + +Discover the affected workspace directory and the host's actual MCP command, arguments, and +environment from available configuration. The shipped command is: + +```text +dotnet dnx Microsoft.AITools.BinlogMcp --yes --prerelease +``` + +Run diagnostics from that workspace with the host's environment, not from the plugin directory +or a temporary directory with different NuGet settings. Inspect: + +```text +dotnet --info +dotnet --version +dotnet nuget list source +``` + +Check the applicable `global.json` and inherited NuGet configuration, including parent/user +configuration, `clear`, disabled sources, and `packageSourceMapping`. A workspace `clear` +can replace the default nuget.org source with a private mirror that lacks this package. +An installed SDK is not necessarily the SDK selected in this directory. The shipped +`dotnet dnx` command requires a .NET 10+ SDK. + +Do not dump credential settings, private feed URLs, tokens, or credential-provider output into +the answer. Inspect locally as needed and report a redacted source label and relevant error. + +## 3. Capture the real launch error + +Prefer an existing startup log from the failing host. Otherwise reproduce its **unchanged** +launch command once, from the affected workspace, capturing both stdout and stderr plus the +exit code. Do not initially add `--source`, replace the configuration, remove `global.json`, +clear caches, or install another copy: those change the conditions being diagnosed. + +A stdio MCP server may remain running waiting for protocol input. Keep stdin open while +observing startup and use a bounded execution (for example, 30 seconds) with cleanup of only +the diagnostic process tree, including credential-provider children. Use the host's supported +timeout/cancellation facility; if it cannot safely clean up, ask the user to run the command +locally instead. Do not leave a background server running or kill unrelated `dotnet` processes. +A timeout, silence, or an open process is **not** proof that MCP initialized. + +Only if package availability remains unclear, run this supporting probe under the same +workspace settings with a bounded execution: + +```text +dotnet package search Microsoft.AITools.BinlogMcp --exact-match --prerelease --format json +``` + +Inspect the exact package ID and version in `searchResult[].packages`, and check both top-level +and per-source `problems`. Exit code zero alone does not establish a successful search. + +| Observed evidence | Diagnosis and next action | +|-------------------|---------------------------| +| `dnx` reports no matching version in the configured feeds | Those settings did not resolve the package. Check whether the approved mirror provides prerelease versions of this exact package. | +| Search returns no packages and no source problems | Only the searched feeds lack a listed match. This is not proof that `dnx` must fail: a cached tool or unlisted version may still work. | +| Search has top-level/per-source problems, HTTP 401/403, TLS, network, or credential-provider errors | Availability is unverified, not "package missing." Address the specific feed/access failure first, even if search exited zero. | +| Search finds the package but `dnx` fails | Follow the launch error. Search does not apply package source mapping; check mapping, restore/download access, and runtime requirements. Do not declare the connection healthy. | +| Missing `dotnet`, unrecognized `dnx`, or SDK selection error | Fix the host's PATH/SDK selection. Account for `global.json`; do not silently upgrade the repository or remove its SDK pin. | +| Timeout, unsupported search command, or malformed/non-JSON output | Report an inconclusive probe. Use launch logs or a user-run diagnostic; do not infer absence or success. | +| Launch succeeds but host connection still fails | Investigate the host's actual command/environment and MCP initialization logs; package discovery is no longer the demonstrated failure. | + +Do not repeat expensive probes once the evidence establishes the next action. + +## 4. Choose a policy-safe recovery + +Recommend the smallest change supported by the observed failure: + +- Have the feed owner mirror `Microsoft.AITools.BinlogMcp` and its required versions/dependencies + into an approved feed, or correct an approved mapping that excludes it. +- Repair the approved feed's authentication, connectivity, or certificate configuration when + that is the observed problem. Never suggest disabling certificate validation. +- Add nuget.org only if organizational policy permits and the user approves the change. + Do not remove `clear`, disable source mapping, or override sources to bypass enterprise policy. +- If appropriate and approved, install the tool from an approved feed and register its + `binlog-mcp` executable with the host as an alternative MCP server. Confirm the executable's + path and avoid registering a duplicate server. Installation alone is not connection recovery. +- For SDK/PATH issues, make the required SDK available to the host or use a deliberately + configured alternative launch. Ask before changing repository SDK selection. + +Do not edit NuGet settings, host registration, or SDK pins without the user's approval. +If policy prevents recovery, say so. For an existing binlog, offer the text-log replay fallback +in `binlog-failure-analysis` rather than blocking build diagnosis on MCP repair. + +## 5. Verify and report + +After an approved change, reconnect/restart the server using the host's supported controls. +Confirm MCP initialization and a tool listing that contains binlog tools such as +`binlog_overview`. If a binlog is available, resume the original analysis. + +Report the observed cause (or what remains unknown), the relevant redacted evidence, the +smallest recovery, and what was actually verified. End with one status line: + +```text +MCP status: connected +``` + +Use `connected` only after the host discovers the server's tools, `failed` for an observed +launch/connection failure, and `unverified` when only probes or advice are available. +Never substitute "package found" or "tool installed" for a verified MCP connection. diff --git a/catalog/Tools/Official-DotNet-MSBuild/skills/troubleshoot-binlog-mcp/manifest.json b/catalog/Tools/Official-DotNet-MSBuild/skills/troubleshoot-binlog-mcp/manifest.json new file mode 100644 index 0000000..2af7918 --- /dev/null +++ b/catalog/Tools/Official-DotNet-MSBuild/skills/troubleshoot-binlog-mcp/manifest.json @@ -0,0 +1,5 @@ +{ + "version": "0.1.11", + "category": "Core", + "compatibility": "Requires a .NET repository with MSBuild project or solution files." +} diff --git a/external-sources/upstreams/astro/packages/astro/package.json b/external-sources/upstreams/astro/packages/astro/package.json index 0629767..b0bc53f 100644 --- a/external-sources/upstreams/astro/packages/astro/package.json +++ b/external-sources/upstreams/astro/packages/astro/package.json @@ -110,7 +110,7 @@ ], "scripts": { "prebuild": "astro-scripts prebuild --to-string \"src/runtime/server/astro-island.ts\" \"src/runtime/client/{idle,load,media,only,visible}.ts\"", - "build": "pnpm run prebuild && astro-scripts build \"src/**/*.{ts,js}\" --copy-wasm && tsc -b && astro-check -- -- --tsconfig ./tsconfig.components.json", + "build": "pnpm run prebuild && astro-scripts build \"src/**/*.{ts,js}\" --copy-wasm && tsc -b && astro-check --tsconfig ./tsconfig.components.json", "build:ci": "pnpm run prebuild && astro-scripts build \"src/**/*.{ts,js}\" --copy-wasm", "dev": "astro-scripts dev --copy-wasm --prebuild \"src/runtime/server/astro-island.ts\" --prebuild \"src/runtime/client/{idle,load,media,only,visible}.ts\" \"src/**/*.{ts,js}\"", "test": "pnpm run test:unit && pnpm run test:integration && pnpm run test:types", @@ -214,7 +214,7 @@ "sass": "^1.105.1", "typescript": "^6.0.3", "undici": "7.30.0", - "vitest": "^4.1.11" + "vitest": "^5.0.5" }, "engines": { "node": ">=22.22.0", diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/README.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/README.md index bab6e66..9ed8d56 100644 --- a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/README.md +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/README.md @@ -6,3 +6,25 @@ The plugin also exposes the `binlog` MCP server to supported hosts. Files under `agents/` are GitHub Copilot custom-agent definitions. Codex plugin installs expose the skills and the Codex-compatible `binlog` MCP declaration, but do not install those `.agent.md` files as native Codex agents. + +## Binlog startup diagnostics + +The [troubleshoot-binlog-mcp](skills/troubleshoot-binlog-mcp/SKILL.md) skill diagnoses +`CONNECTION_CLOSED`, missing binlog tools, and failures to start `Microsoft.AITools.BinlogMcp`. +Ask, for example, "The dotnet-msbuild binlog MCP won't connect; help me diagnose it." +It captures the launch error in the affected workspace, checks SDK and NuGet settings, +and suggests recovery without bypassing organizational feed policy. + +This is an **on-demand skill**, not a session-start hook. It adds no executable hook code, +startup probe, or host-specific diagnostic payload. The MCP launch command is unchanged. +An agent can select the skill when the user reports a problem or a binlog workflow encounters +an unavailable server, provided the host has loaded the plugin's skills. A connection error +hidden from the agent cannot trigger the skill, so an automatic warning at session start is +not guaranteed. + +The skill distinguishes package absence from feed/authentication problems, SDK mismatches, +and timeouts. Package search alone is not a startup test: `dnx` also applies source mapping +and can use cached tools or unlisted versions. Recovery is verified by reconnecting the +host and discovering the binlog MCP tools, not just by finding the package. + +Focused evaluation scenarios live in `tests/dotnet-msbuild/troubleshoot-binlog-mcp/`. diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/build-perf.agent.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/build-perf.agent.md index f8b85b1..72a302f 100644 --- a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/build-perf.agent.md +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/build-perf.agent.md @@ -35,6 +35,9 @@ Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the ### Alternate flow — text-log replay (when MCP is unavailable) +Use `troubleshoot-binlog-mcp` if the user wants to repair the connection. If repair +is blocked, declined, or unnecessary, continue performance analysis with replay. + 1. Replay to diagnostic log: `dotnet msbuild perf-baseline.binlog -noconlog -fl -flp:v=diag;logfile=full.log;performancesummary` 2. `grep 'Target Performance Summary' -A 50 full.log` → find dominant targets and their cumulative time 3. `grep 'Task Performance Summary' -A 50 full.log` → find dominant tasks diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/msbuild.agent.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/msbuild.agent.md index c65d5ec..f68736a 100644 --- a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/msbuild.agent.md +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/agents/msbuild.agent.md @@ -36,6 +36,7 @@ Classify the user's request and route to the appropriate specialist: | User Intent | Route To | |------------|----------| +| Binlog MCP won't connect, `CONNECTION_CLOSED`, or binlog tools are missing | This agent + `troubleshoot-binlog-mcp` skill | | Build failed, errors to diagnose | This agent + `binlog-failure-analysis` skill | | Build is slow, optimize performance | `build-perf` agent + `build-perf-baseline` skill (start with baseline) | | Review/clean up project files | `msbuild-code-review` agent (specialized code review) | @@ -70,6 +71,8 @@ When answering questions about MSBuild syntax, properties, or behavior, use `#to This agent has access to a comprehensive set of troubleshooting and optimization skills: ### Build Failure Skills + +- `troubleshoot-binlog-mcp` — Binlog MCP startup/connection diagnosis, without requiring a binlog - `binlog-failure-analysis` — Binary log analysis for failure diagnosis - `binlog-generation` — Binary log generation conventions diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-failure-analysis/SKILL.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-failure-analysis/SKILL.md index 768e876..e2b597b 100644 --- a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-failure-analysis/SKILL.md +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-failure-analysis/SKILL.md @@ -1,6 +1,6 @@ --- name: binlog-failure-analysis -description: "Analyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), non-MSBuild build systems." +description: "Analyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), binlog MCP startup or connection failures (use troubleshoot-binlog-mcp), non-MSBuild build systems." license: MIT --- @@ -9,7 +9,9 @@ license: MIT This skill diagnoses MSBuild build failures from a `.binlog` file. The preferred path uses the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) which is bundled with this plugin. If the MCP server is -not available, fall back to the **binlog replay** workflow at the bottom. +not available, use `troubleshoot-binlog-mcp` to diagnose startup when repair is wanted. +If repair is blocked, declined, or unnecessary for this task, continue with the +**binlog replay** workflow at the bottom. ## Primary workflow — binlog MCP diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-generation/SKILL.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-generation/SKILL.md index 0d18266..418ae0f 100644 --- a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-generation/SKILL.md +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/binlog-generation/SKILL.md @@ -1,6 +1,6 @@ --- name: binlog-generation -description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead)." +description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead), binlog MCP startup failures (use troubleshoot-binlog-mcp)." license: MIT --- diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/build-perf-diagnostics/SKILL.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/build-perf-diagnostics/SKILL.md index 22fdb70..901bc6c 100644 --- a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/build-perf-diagnostics/SKILL.md +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/build-perf-diagnostics/SKILL.md @@ -9,6 +9,9 @@ license: MIT 1. **Generate a binlog**: `dotnet build /bl:{} -m` 2. Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) which is bundled with this plugin +If the server cannot connect, use `troubleshoot-binlog-mcp` when startup repair is +wanted. If repair is blocked, declined, or unnecessary, use the replay flow below. + ### Alternate flow when MCP is unavailable: binlog replay to text logs 1. **Generate a binlog**: `dotnet build /bl:{} -m` diff --git a/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/troubleshoot-binlog-mcp/SKILL.md b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/troubleshoot-binlog-mcp/SKILL.md new file mode 100644 index 0000000..fb490c3 --- /dev/null +++ b/external-sources/upstreams/dotnet-skills/plugins/dotnet-msbuild/skills/troubleshoot-binlog-mcp/SKILL.md @@ -0,0 +1,128 @@ +--- +name: troubleshoot-binlog-mcp +description: "Diagnose dotnet-msbuild binlog MCP startup failures. USE FOR: CONNECTION_CLOSED, binlog server won't connect, missing binlog tools, Microsoft.AITools.BinlogMcp not found, dnx launch errors. Checks workspace SDK, feeds, and source mapping without bypassing policy. DO NOT USE FOR: errors inside a binlog (use binlog-failure-analysis), capturing binlogs (use binlog-generation), unrelated MCP servers." +license: MIT +--- + +# Troubleshoot Binlog MCP Startup + +Explain why the plugin's binlog MCP server cannot connect and give an evidence-based, +policy-safe recovery. This diagnoses the **server launch**, not failures recorded in a build. +No binlog file or project build is needed. + +This skill runs on demand. It cannot see a host error that was never exposed to the agent, +inject session-start context, or guarantee activation merely because a plugin was installed. + +## 1. Establish what failed + +Use the user's error and any host MCP status or startup logs already available. +`CONNECTION_CLOSED` alone says that the transport closed, not why. Do not translate it +directly into "package missing." + +- If the binlog server is connected and its tools are discoverable, stop startup troubleshooting. + Continue the original binlog analysis; do not change a working setup. +- If the plugin's skills loaded but its binlog server did not, continue below. +- If the plugin itself is not installed/enabled or no server is registered, address that host + configuration first. Do not diagnose NuGet package resolution without a launch attempt. +- If execution or host logs are unavailable, explain that limit and give the next command for + the user to run. Never claim to have inspected logs or repaired a connection. + +## 2. Match the host's workspace and SDK + +Discover the affected workspace directory and the host's actual MCP command, arguments, and +environment from available configuration. The shipped command is: + +```text +dotnet dnx Microsoft.AITools.BinlogMcp --yes --prerelease +``` + +Run diagnostics from that workspace with the host's environment, not from the plugin directory +or a temporary directory with different NuGet settings. Inspect: + +```text +dotnet --info +dotnet --version +dotnet nuget list source +``` + +Check the applicable `global.json` and inherited NuGet configuration, including parent/user +configuration, `clear`, disabled sources, and `packageSourceMapping`. A workspace `clear` +can replace the default nuget.org source with a private mirror that lacks this package. +An installed SDK is not necessarily the SDK selected in this directory. The shipped +`dotnet dnx` command requires a .NET 10+ SDK. + +Do not dump credential settings, private feed URLs, tokens, or credential-provider output into +the answer. Inspect locally as needed and report a redacted source label and relevant error. + +## 3. Capture the real launch error + +Prefer an existing startup log from the failing host. Otherwise reproduce its **unchanged** +launch command once, from the affected workspace, capturing both stdout and stderr plus the +exit code. Do not initially add `--source`, replace the configuration, remove `global.json`, +clear caches, or install another copy: those change the conditions being diagnosed. + +A stdio MCP server may remain running waiting for protocol input. Keep stdin open while +observing startup and use a bounded execution (for example, 30 seconds) with cleanup of only +the diagnostic process tree, including credential-provider children. Use the host's supported +timeout/cancellation facility; if it cannot safely clean up, ask the user to run the command +locally instead. Do not leave a background server running or kill unrelated `dotnet` processes. +A timeout, silence, or an open process is **not** proof that MCP initialized. + +Only if package availability remains unclear, run this supporting probe under the same +workspace settings with a bounded execution: + +```text +dotnet package search Microsoft.AITools.BinlogMcp --exact-match --prerelease --format json +``` + +Inspect the exact package ID and version in `searchResult[].packages`, and check both top-level +and per-source `problems`. Exit code zero alone does not establish a successful search. + +| Observed evidence | Diagnosis and next action | +|-------------------|---------------------------| +| `dnx` reports no matching version in the configured feeds | Those settings did not resolve the package. Check whether the approved mirror provides prerelease versions of this exact package. | +| Search returns no packages and no source problems | Only the searched feeds lack a listed match. This is not proof that `dnx` must fail: a cached tool or unlisted version may still work. | +| Search has top-level/per-source problems, HTTP 401/403, TLS, network, or credential-provider errors | Availability is unverified, not "package missing." Address the specific feed/access failure first, even if search exited zero. | +| Search finds the package but `dnx` fails | Follow the launch error. Search does not apply package source mapping; check mapping, restore/download access, and runtime requirements. Do not declare the connection healthy. | +| Missing `dotnet`, unrecognized `dnx`, or SDK selection error | Fix the host's PATH/SDK selection. Account for `global.json`; do not silently upgrade the repository or remove its SDK pin. | +| Timeout, unsupported search command, or malformed/non-JSON output | Report an inconclusive probe. Use launch logs or a user-run diagnostic; do not infer absence or success. | +| Launch succeeds but host connection still fails | Investigate the host's actual command/environment and MCP initialization logs; package discovery is no longer the demonstrated failure. | + +Do not repeat expensive probes once the evidence establishes the next action. + +## 4. Choose a policy-safe recovery + +Recommend the smallest change supported by the observed failure: + +- Have the feed owner mirror `Microsoft.AITools.BinlogMcp` and its required versions/dependencies + into an approved feed, or correct an approved mapping that excludes it. +- Repair the approved feed's authentication, connectivity, or certificate configuration when + that is the observed problem. Never suggest disabling certificate validation. +- Add nuget.org only if organizational policy permits and the user approves the change. + Do not remove `clear`, disable source mapping, or override sources to bypass enterprise policy. +- If appropriate and approved, install the tool from an approved feed and register its + `binlog-mcp` executable with the host as an alternative MCP server. Confirm the executable's + path and avoid registering a duplicate server. Installation alone is not connection recovery. +- For SDK/PATH issues, make the required SDK available to the host or use a deliberately + configured alternative launch. Ask before changing repository SDK selection. + +Do not edit NuGet settings, host registration, or SDK pins without the user's approval. +If policy prevents recovery, say so. For an existing binlog, offer the text-log replay fallback +in `binlog-failure-analysis` rather than blocking build diagnosis on MCP repair. + +## 5. Verify and report + +After an approved change, reconnect/restart the server using the host's supported controls. +Confirm MCP initialization and a tool listing that contains binlog tools such as +`binlog_overview`. If a binlog is available, resume the original analysis. + +Report the observed cause (or what remains unknown), the relevant redacted evidence, the +smallest recovery, and what was actually verified. End with one status line: + +```text +MCP status: connected +``` + +Use `connected` only after the host discovers the server's tools, `failed` for an observed +launch/connection failure, and `unverified` when only probes or advice are available. +Never substitute "package found" or "tool installed" for a verified MCP connection. diff --git a/external-sources/upstreams/roslynk/README.md b/external-sources/upstreams/roslynk/README.md index b4824b5..f158b08 100644 --- a/external-sources/upstreams/roslynk/README.md +++ b/external-sources/upstreams/roslynk/README.md @@ -222,13 +222,15 @@ The skill directory is watched, so a fresh copy is picked up without restarting > `#if` branches and Razor, and it never matches names inside comments or strings. > > **Getting started:** call `open_solution` with the absolute path to the `.sln`/`.slnx`; the -> `solutionId` it returns is the handle every other tool needs. It loads in the background — while -> it does, other calls return `error=Indexing`; retry shortly or poll `get_solution_status`. Never +> `solutionId` it returns is the handle every other tool needs. It waits for the load by default +> (`noWait=true` pre-warms in the background); every solution tool waits server-side up to the +> configured timeout, so you normally get the result rather than a retry prompt. Only if the timeout +> elapses do calls return `error=Indexing` (with `projects=loaded/?`); retry shortly. Never > fall back to reading or editing files directly. Never call `reload_solution` on your own > initiative — a file watcher picks up edits automatically; suggest a reload instead. > > **Lifecycle:** -> - `open_solution`: Load a solution. Parameters: `solutionPath` (absolute). Idempotent, cheap to repeat. +> - `open_solution`: Load a solution. Parameters: `solutionPath` (absolute), `noWait` (return before the load finishes). Idempotent, cheap to repeat. > - `get_solution_status`: List every loaded solution and its progress, with the messages behind `loadDiagnostics` (skipped analyzers, failed project loads) indented under each Ready solution. A missing generator DLL names the project to build; once built, the next call picks it up without a reload. Optional parameter: `allLoadDiagnostics` (every message instead of the first 20 per solution). > - `reload_solution`: Force a from-disk re-evaluation. Parameter: `solutionId`. Only when the user explicitly asks. > @@ -238,7 +240,7 @@ The skill directory is watched, so a fresh copy is picked up without restarting > - `get_symbol`: Identify a symbol and get its declaration. Parameters: `solutionId`, `symbolName` (fully-qualified). > - `get_symbol_body`: Read a symbol's source text, body included. Parameters: `solutionId`, `symbolName` (fully-qualified), `includeLeadingTrivia`, `startItem` (page a long declaration; the response reports `truncated=Y`/`count`/`nextStartItem`), `maxSize` (page size in characters; default the response budget), `part` (fetch one declaration of a partial type; oversized parts are listed with `omitted=Y` and line counts). > - `get_members`: List a type's members with their locations. Parameters: `solutionId`, `symbolName`, `includeInherited`, `nameFilter`, `includeMethods`/`includeFields`/`includeProperties`/`includeEvents`/`includeNestedTypes`. -> - `search_symbols`: Find symbols by partial name. Parameters: `solutionId`, `query`, `maxSize` (page size; paging reaches every match). +> - `search_symbols`: Find symbols by partial name, or by a dotted container-qualified name (`Type.Member`, matched as a suffix of the containing type/namespace chain). Parameters: `solutionId`, `query`, `kinds` (optional JSON array of kind names such as `["Method"]`; a JSON-array string is also accepted), `maxSize` (page size; paging reaches every match). > - `multi_query`: Run several of the read-only queries above in one call, against a single snapshot of the solution. Parameters: `solutionId`, `operations` (each names a tool and carries that tool's own parameters), optional `expectSnapshot`. The whole response stays within the server's response budget (80,000 characters by default): every operation runs, whole results are delivered smallest-first until the budget is filled (in request order), and the rest are named once in the header as `retry=:` (size = the result's cost as a ratio of the budget, rounded up to 0.1). Sizes ≥ 1.0 must be re-sent alone (they page); sizes summing to ≤ 1.0 fit one continuation batch together. See the skill's multi_query section. For impact questions ("what uses X?", "what breaks if I change X?"), batch `find_references`, `get_callers`, `get_callees`, `find_implementations` and `get_type_hierarchy` in one call. > > **Relationships:** @@ -307,6 +309,8 @@ Listens on `http://localhost:6502`. Point your MCP client at that URL (streamabl The response budget (the character cap every tool result is held under; default 80,000) is read once at startup from `Roslynk:MaxResponseChars` in `appsettings.json` or the `Roslynk__MaxResponseChars` environment variable. A shared daemon serves every client with one value — set the smallest cap your clients need, and restart the daemon to change it. +Solution-scoped tools wait server-side for an in-flight initial load for up to `Roslynk:LoadWaitSeconds` (default 30, or the `Roslynk__LoadWaitSeconds` environment variable) before returning `error=Indexing` with the live project count. Restart the daemon to change it. + ## Run (Windows) Foreground dev: diff --git a/external-sources/vendir.lock.yml b/external-sources/vendir.lock.yml index f701a43..024209f 100644 --- a/external-sources/vendir.lock.yml +++ b/external-sources/vendir.lock.yml @@ -2,26 +2,28 @@ apiVersion: vendir.k14s.io/v1alpha1 directories: - contents: - git: - commitTitle: 'Merge pull request #1330 from dotnet/copilot/fix-dotnet-pinvoke-examples...' - sha: 9386ed7c1148a7bef970aa0502371c982effa01c + commitTitle: 'Merge pull request #1309 from dotnet/abhitejjohn-finish-vally-018-migration...' + sha: c848e7fffab05c594f9b954c6f3beb373d108447 tags: - - skill-validator-nightly-4-g9386ed7c + - skill-validator-nightly-16-gc848e7ff path: dotnet-skills - git: commitTitle: Add Cursor rules that reference the existing skill docs... sha: af2319bd01bb7cc881267a9ef42cafdaf5e9029d path: webgpu-claude-skill - git: - commitTitle: '[ci] release (#18405)' - sha: e990df87fb74b71a94b50fbc83a26a189391e300 + commitTitle: 'fix(astro): stop excluding node-fetch from server dep optimization + in workerd dev (#18438)...' + sha: 5e0eaa4415a9081efdaeb3d9af3717ce3226ad18 tags: - - '@astrojs/check@0.9.11' + - '@astrojs/check@0.9.11-18-g5e0eaa4415' path: astro - git: - commitTitle: 'Ensure server instructions are correct (Fixes #120) (#125)' - sha: 4ec00df7da4b6c259a818076cf15161bebacf190 + commitTitle: 'Report precise invalid-JSON and multi_query binding errors (Fixes + #108) (#135)...' + sha: 7be07af1124bbc85aeed0b8037b8e9442ce3f7d7 tags: - - 2.2.0-5-g4ec00df + - 2.2.0-16-g7be07af path: roslynk path: upstreams kind: LockConfig