Add MCP Apps UI support with SDK dashboard#413
Conversation
Implement MCP Apps (SEP-1865) support for the DotnetSdk tool, rendering an interactive HTML dashboard inline in VS Code chat. - Add McpAppsResources with ui:// resource returning themed HTML dashboard - Add both modern nested and legacy flat McpMeta keys on DotnetSdk tool (VS Code requires the legacy 'ui/resourceUri' flat key) - Register McpAppsResources in Program.cs - Add wire format tests validating both _meta key formats - Add doc/mcp-apps.md implementation guide
|
@copilot address comments |
… catch clause Co-authored-by: jongalloway <68539+jongalloway@users.noreply.github.com> Agent-Logs-Url: https://github.com/jongalloway/dotnet-mcp/sessions/09222802-7404-459d-a12c-088bc75feba3
Addressed both GitHub Advanced Security alerts in
CodeQL now reports 0 alerts. |
| catch (Exception) | ||
| { | ||
| // If runtime fetch fails, return SDKs only — dashboard will show what it can | ||
| return sdkContent; | ||
| } |
Check notice
Code scanning / CodeQL
Generic catch clause Note
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 19 days ago
To fix the problem, we should replace the generic catch (Exception) with more specific exception handlers that reflect the likely failure modes of invoking and parsing dotnet --list-runtimes. Specifically, failures may come from the process execution (I/O, invalid operation, Task cancellation) or from string/array operations while parsing (argument/out-of-range/format). We can group these into a small, explicit set of exception types and still preserve the current behavior: on these known failures, return sdkContent so the dashboard can show SDKs only.
The best minimal-change fix is:
- Replace
catch (Exception)withcatchclauses for a chosen set of expected exceptions, all of which perform the same fallback tosdkContent. - Optionally add a final
catchforOperationCanceledExceptionif cancellation should also result in a graceful fallback; if cancellation should propagate, we omit that. - Do not alter imports or method signatures; only adjust the catch section of
BuildListSdksWithRuntimesStructuredContentAsync.
Concretely, in DotNetMcp/Tools/Sdk/DotNetCliTools.Sdk.Consolidated.cs, around lines 578–619:
- Replace the single
catch (Exception)block with a grouped catch that handles common runtime and parsing errors, e.g.IOException,InvalidOperationException,FormatException,ArgumentException, andIndexOutOfRangeException, all with identical bodies returningsdkContent. This narrows the catch surface while keeping the observable behavior for these failure types unchanged.
| @@ -612,11 +612,31 @@ | ||
|
|
||
| return new { sdks, runtimes }; | ||
| } | ||
| catch (Exception) | ||
| catch (System.IO.IOException) | ||
| { | ||
| // If runtime fetch fails, return SDKs only — dashboard will show what it can | ||
| // If runtime fetch fails due to I/O issues, return SDKs only — dashboard will show what it can | ||
| return sdkContent; | ||
| } | ||
| catch (InvalidOperationException) | ||
| { | ||
| // If runtime fetch fails due to process invocation issues, return SDKs only | ||
| return sdkContent; | ||
| } | ||
| catch (FormatException) | ||
| { | ||
| // If runtime output cannot be parsed as expected, return SDKs only | ||
| return sdkContent; | ||
| } | ||
| catch (ArgumentException) | ||
| { | ||
| // If runtime parsing encounters bad arguments (e.g., Split), return SDKs only | ||
| return sdkContent; | ||
| } | ||
| catch (IndexOutOfRangeException) | ||
| { | ||
| // If runtime parsing encounters unexpected field counts, return SDKs only | ||
| return sdkContent; | ||
| } | ||
| } | ||
|
|
||
| private static object? BuildListRuntimesStructuredContent(string textResult) |
Implement MCP Apps (SEP-1865) support for the DotnetSdk tool, rendering an interactive HTML dashboard inline in VS Code chat.