-
Notifications
You must be signed in to change notification settings - Fork 33
Add VS Code configuration for development tasks and debugging #250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v5/main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,29 @@ | ||||||||
| { | ||||||||
| "version": "0.2.0", | ||||||||
| "configurations": [ | ||||||||
| { | ||||||||
| "name": ".NET Core Launch (TestSite)", | ||||||||
| "type": "coreclr", | ||||||||
| "request": "launch", | ||||||||
| "program": "dotnet", | ||||||||
| "args": ["run"], | ||||||||
| "cwd": "${workspaceFolder}/examples/Umbraco.Community.BlockPreview.TestSite", | ||||||||
| "stopAtEntry": false, | ||||||||
| "requireExactSource": false, | ||||||||
|
||||||||
| "requireExactSource": false, | |
| "requireExactSource": false, | |
| "preLaunchTask": "Dotnet build", |
Copilot
AI
Feb 13, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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" |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,3 @@ | ||
| { | ||
| "dotnet.defaultSolution": "src/Umbraco.Community.BlockPreview.sln" | ||
| "dotnet.defaultSolution": "Umbraco.Community.BlockPreview.sln" | ||
| } |
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,87 @@ | ||||||||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||||||||
| "version": "2.0.0", | ||||||||||||||||||||||||||||||||||
| "tasks": [ | ||||||||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||||||||
| "label": "Build", | ||||||||||||||||||||||||||||||||||
| "detail": "Builds the client and solution", | ||||||||||||||||||||||||||||||||||
| "promptOnClose": true, | ||||||||||||||||||||||||||||||||||
| "group": "build", | ||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
| "group": "build", | |
| "group": { "kind": "build", "isDefault": true }, |
Copilot
AI
Feb 13, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Copilot
AI
Feb 13, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Copilot
AI
Feb 13, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 }\"" |
Copilot
AI
Feb 13, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
If using this approach, remove the args field and add a preLaunchTask to build first.