Add VS Code configuration for development tasks and debugging#250
Add VS Code configuration for development tasks and debugging#250rickbutterfield wants to merge 1 commit intov5/mainfrom
Conversation
Adds launch/debug configurations and build tasks modeled after the Umbraco-CMS repository, adapted for BlockPreview's project structure. Also fixes the default solution path in settings.json. https://claude.ai/code/session_015JoPQr4bPMG8ZTb567haCd
Pull Request ReviewThank you for this contribution! This is a solid addition to the developer experience. I've reviewed the VS Code configuration changes and have the following feedback: ✅ Strengths
🔍 Potential Issues & Suggestions1. Launch Configuration - Program PathIssue: The launch configuration uses Why this matters:
Recommendation: Consider using the standard pattern with a 2. Kill Task Error HandlingIssue: The Recommendation: Add error suppression using 3. Task GroupingEnhancement: The composite "Build" task could be marked as the default build task by setting 4. Missing preLaunchTaskEnhancement: The launch configuration doesn't have a Recommendation: Add 5. requireExactSource SettingQuestion: The Recommendation: Document why this is disabled or consider removing it to use the default behavior. 🎯 Code Quality & Best Practices
🔒 Security ConsiderationsNo security concerns identified. These are development-only configuration files that won't be included in the NuGet package. 🧪 Testing RecommendationsTo validate these configurations work as expected:
📝 SummaryThis is a valuable contribution that will improve the contributor experience. The main recommendations are:
The current implementation will work but may cause confusion for developers familiar with standard VS Code .NET debugging patterns. Recommendation: Request changes to address the launch configuration issue (#1), the others are optional enhancements. |
There was a problem hiding this comment.
Pull request overview
This PR adds VS Code workspace configuration files to improve the development experience for contributors working on BlockPreview, an Umbraco community package. The configurations enable streamlined building, running, and debugging of both the client-side TypeScript/Lit components and the .NET backend. The PR also corrects an existing path issue in the settings file where the solution path was incorrectly pointing to a src/ subdirectory.
Changes:
- Added comprehensive VS Code tasks for building and running client (npm/Vite) and server (.NET) components
- Added VS Code launch configurations for debugging the TestSite application
- Fixed incorrect default solution path from
src/Umbraco.Community.BlockPreview.slntoUmbraco.Community.BlockPreview.sln
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
.vscode/tasks.json |
Defines npm and .NET build/watch tasks, composite Build task, and platform-specific process cleanup task |
.vscode/settings.json |
Corrects the default solution path to point to the root-level .sln file |
.vscode/launch.json |
Adds .NET Core launch and attach configurations for debugging with automatic browser opening and cleanup |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "program": "dotnet", | ||
| "args": ["run"], | ||
| "cwd": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite", |
There was a problem hiding this comment.
The launch configuration uses "program": "dotnet" with "args": ["run"], which will work since the cwd is set to the project directory. However, the standard and more reliable approach for .NET debugging in VS Code is to point the program field directly to the compiled DLL:
"program": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite/bin/Debug/net10.0/Umbraco.Community.BlockPreview.TestSite.dll"
This approach:
- Provides better debugging performance (no additional dotnet CLI overhead)
- Makes it clearer what's being debugged
- Follows VS Code .NET extension conventions
If using this approach, remove the args field and add a preLaunchTask to build first.
| "program": "dotnet", | |
| "args": ["run"], | |
| "cwd": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite", | |
| "program": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite/bin/Debug/net10.0/Umbraco.Community.BlockPreview.TestSite.dll", | |
| "cwd": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite", | |
| "preLaunchTask": "build-test-site", |
| "label": "Build", | ||
| "detail": "Builds the client and solution", | ||
| "promptOnClose": true, | ||
| "group": "build", |
There was a problem hiding this comment.
The composite "Build" task should be marked as the default build task. Change line 8 from "group": "build" to "group": {"kind": "build", "isDefault": true} to make it the default build task that can be executed with Ctrl+Shift+B (or Cmd+Shift+B on macOS).
| "group": "build", | |
| "group": { "kind": "build", "isDefault": true }, |
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite" | ||
| }, | ||
| "windows": { | ||
| "command": "taskkill /IM Umbraco.Community.BlockPreview.TestSite.exe /F" |
There was a problem hiding this comment.
The Windows taskkill command is likely incorrect. When running dotnet run or debugging through VS Code, the process name is "dotnet.exe", not "Umbraco.Community.BlockPreview.TestSite.exe". The command should be:
"command": "taskkill /IM dotnet.exe /F"
However, this has the downside of killing ALL dotnet.exe processes. A more precise approach would use PowerShell to filter by working directory or command line arguments. The pkill commands on Linux/macOS also have the same issue - they may kill other instances of the application if multiple are running.
| "command": "taskkill /IM Umbraco.Community.BlockPreview.TestSite.exe /F" | |
| "command": "powershell -NoProfile -Command \"Get-CimInstance Win32_Process | Where-Object { $_.Name -eq 'dotnet.exe' -and $_.CommandLine -match 'Umbraco.Community.BlockPreview.TestSite' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }\"" |
| { | ||
| "label": "Client Build", | ||
| "detail": "Runs npm run build for BlockPreview.UI", | ||
| "promptOnClose": true, | ||
| "group": "build", | ||
| "type": "npm", | ||
| "script": "build", | ||
| "path": "src/Umbraco.Community.BlockPreview.UI/", | ||
| "problemMatcher": [] | ||
| }, |
There was a problem hiding this comment.
The "Client Build" task may fail if npm packages haven't been installed yet. Consider adding "Client Install" as a dependency of "Client Build" by adding a "dependsOn" field:
"dependsOn": ["Client Install"]
This ensures packages are installed before attempting to build. Alternatively, document that "Client Install" needs to be run manually before the first build.
| "args": ["run"], | ||
| "cwd": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite", | ||
| "stopAtEntry": false, | ||
| "requireExactSource": false, |
There was a problem hiding this comment.
The launch configuration is missing a preLaunchTask to build the project before debugging. Add a preLaunchTask field that references the "Dotnet build" task to ensure the project is built before launching the debugger. Without this, debugging may fail if the project hasn't been built yet or if changes have been made since the last build.
| "requireExactSource": false, | |
| "requireExactSource": false, | |
| "preLaunchTask": "Dotnet build", |
| }, | ||
| "env": { | ||
| "ASPNETCORE_ENVIRONMENT": "Development" | ||
| } |
There was a problem hiding this comment.
Consider adding a "console" field to specify where console output should be displayed. For web applications, the recommended value is "internalConsole" to show output in VS Code's Debug Console. Add:
"console": "internalConsole"
This provides a better debugging experience for ASP.NET Core applications.
| } | |
| }, | |
| "console": "internalConsole" |
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite" | ||
| }, | ||
| "linux": { | ||
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite" | ||
| }, | ||
| "windows": { | ||
| "command": "taskkill /IM Umbraco.Community.BlockPreview.TestSite.exe /F" |
There was a problem hiding this comment.
The kill-test-site task should include error handling to prevent failures when the process isn't running. Add "ignoreExitCode": true to the problemMatcher configuration or modify the commands to ignore errors:
- Windows:
"command": "taskkill /IM Umbraco.Community.BlockPreview.TestSite.exe /F || exit 0" - Linux/macOS:
"command": "pkill -f Umbraco.Community.BlockPreview.TestSite || true"
This prevents the postDebugTask from failing when the process has already terminated, which would show an error message to the user unnecessarily.
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite" | |
| }, | |
| "linux": { | |
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite" | |
| }, | |
| "windows": { | |
| "command": "taskkill /IM Umbraco.Community.BlockPreview.TestSite.exe /F" | |
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite || true" | |
| }, | |
| "linux": { | |
| "command": "pkill -f Umbraco.Community.BlockPreview.TestSite || true" | |
| }, | |
| "windows": { | |
| "command": "taskkill /IM Umbraco.Community.BlockPreview.TestSite.exe /F || exit 0" |
| "label": "Dotnet build", | ||
| "detail": "Dotnet build of solution", | ||
| "promptOnClose": true, | ||
| "group": "build", | ||
| "command": "dotnet", | ||
| "type": "process", | ||
| "args": [ | ||
| "build", | ||
| "${workspaceFolder}/Umbraco.Community.BlockPreview.sln", | ||
| "/property:GenerateFullPaths=true", | ||
| "/consoleloggerparameters:NoSummary" | ||
| ], | ||
| "problemMatcher": "$msCompile" | ||
| }, | ||
| { | ||
| "label": "Dotnet watch", | ||
| "detail": "Dotnet run and watch of TestSite", | ||
| "promptOnClose": true, | ||
| "command": "dotnet", | ||
| "type": "process", | ||
| "args": [ | ||
| "watch", | ||
| "run", | ||
| "--project", | ||
| "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite/Umbraco.Community.BlockPreview.TestSite.csproj", | ||
| "/property:GenerateFullPaths=true", | ||
| "/consoleloggerparameters:NoSummary" | ||
| ], | ||
| "problemMatcher": "$msCompile" | ||
| }, |
There was a problem hiding this comment.
Task naming is inconsistent. Tasks use "Client" as a prefix (e.g., "Client Build", "Client Install", "Client Watch") but then use "Dotnet" with a lowercase "n". For consistency, consider either:
- Using "Dotnet Build" and "Dotnet Watch" (current style)
- Using ".NET Build" and ".NET Watch" (matching the official product name)
- Using "Server Build" and "Server Watch" (parallel to "Client")
The most common convention in VS Code configurations is to use ".NET" to match Microsoft's official branding.
Summary
This PR adds VS Code workspace configuration files to streamline the development experience for contributors working on the BlockPreview project.
Key Changes
Added
.vscode/tasks.json: Defines build and development tasks including:Added
.vscode/launch.json: Provides debugging configurations:Updated
.vscode/settings.json: Fixed the default solution path fromsrc/Umbraco.Community.BlockPreview.slntoUmbraco.Community.BlockPreview.slnto match the actual project structureBenefits
These configurations enable developers to:
https://claude.ai/code/session_015JoPQr4bPMG8ZTb567haCd