Per-project launch options, publish/test tasks, explorer badge, keybindings
- dotnetSolution.launch.projects: args, env, cwd, console and profile per project name, layered over the global settings and Properties/launchSettings.json. Applied to the debug button and, through resolveDebugConfiguration, to the launch.json entry too. - publish and test task targets with the same configuration/platform. - Problems panel opens when a task fails. - The startup csproj and its folder are marked in the explorer. - F5 / Ctrl+F5 / Ctrl+Shift+B map to debug/run/build until a launch.json entry exists; Ctrl+Alt+C and Ctrl+Alt+P open the pickers. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0169iPWwKHZoBTNN9qwXiwqk
This commit is contained in:
Claude Fable 5.1
@@ -48,8 +48,17 @@ own workspace state — so this extension owns the build rather than wrapping
|
||||
| `solution` | `dotnet build MyGame.sln -c Test -p:Platform=x64` | Like Visual Studio's *Build Solution*. MSBuild maps every project through the `.sln`: MyGame.* build as `Test\|x64`, MoonWorks as `Debug\|Any CPU`, and the Editor → Builder `ProjectDependencies` entry is honoured, so the Builder exists before the Editor's post-build step needs it. |
|
||||
| `project` | `dotnet build MyGame.Editor.csproj -c Test -p:Platform=x64` | Only the startup project and its `ProjectReference`s. Faster, but solution-only dependencies are ignored. |
|
||||
|
||||
Rebuild adds `--no-incremental`; Clean runs `dotnet clean`. All three are tasks of type
|
||||
`dotnet-solution`, so they show up under *Run Task* and can be used as `preLaunchTask`.
|
||||
Rebuild adds `--no-incremental`; Clean runs `dotnet clean`. Two more targets use the same
|
||||
selection:
|
||||
|
||||
| Target | Command | Notes |
|
||||
| --- | --- | --- |
|
||||
| `publish` | `dotnet publish MyGame.Editor.csproj -c Release -p:Platform=x64 [-r win-x64]` | Always the startup project. `dotnetSolution.publish.runtime` sets `-r`, which `PublishAot` needs; `publish.args` adds the rest |
|
||||
| `test` | `dotnet test MyGame.sln -c Test -p:Platform=x64` | Follows `buildScope`; `dotnetSolution.test.args` adds filters or `--no-build` |
|
||||
|
||||
All five are tasks of type `dotnet-solution`, so they show up under *Run Task* and can be
|
||||
used as `preLaunchTask`. When one fails the Problems panel opens
|
||||
(`dotnetSolution.showProblemsOnFailure`).
|
||||
|
||||
## What a launch does
|
||||
|
||||
@@ -60,23 +69,49 @@ and `AppendTargetFrameworkToOutputPath` is off. The result is cached until a pro
|
||||
solution file changes.
|
||||
|
||||
The apphost `.exe` is launched when the project produces one, since vsdbg wants an
|
||||
executable; otherwise it runs `dotnet <TargetPath>`. Working directory is `TargetDir`
|
||||
unless `dotnetSolution.launch.cwd` says otherwise. DotRush's debug configuration provider
|
||||
still runs after this one and fills in `justMyCode`, symbol options and the console.
|
||||
executable; otherwise it runs `dotnet <TargetPath>`. DotRush's debug configuration provider
|
||||
still runs after this one and fills in `justMyCode` and symbol options.
|
||||
|
||||
### Arguments, environment, working directory
|
||||
|
||||
Builder and Editor want different arguments, so these are layered, most specific wins:
|
||||
|
||||
1. `dotnetSolution.launch.projects`, keyed by project name:
|
||||
```jsonc
|
||||
"dotnetSolution.launch.projects": {
|
||||
"MyGame.Builder": { "args": ["-build", "-resourcePath", "Resources"], "cwd": "../MyGame.Editor" },
|
||||
"MyGame.Editor": { "console": "integratedTerminal" }
|
||||
}
|
||||
```
|
||||
`cwd` is relative to the project folder. `profile` names a launchSettings.json profile.
|
||||
2. The global `dotnetSolution.launch.args` / `.env` / `.cwd` / `.console`.
|
||||
3. `Properties/launchSettings.json` next to the project: `commandLineArgs`,
|
||||
`environmentVariables` and `workingDirectory` of the first `"commandName": "Project"`
|
||||
profile, or the one named by `dotnetSolution.launch.profile`.
|
||||
4. Otherwise no arguments and `TargetDir` as the working directory.
|
||||
|
||||
The same layering applies to F5 through the launch.json entry: its `args` stay empty in
|
||||
the file and are filled in at launch time.
|
||||
|
||||
## Usage
|
||||
|
||||
| Action | How |
|
||||
| --- | --- |
|
||||
| Pick the startup project | Click the project name, or right-click a `.csproj` → *Set as Startup Project (.NET Solution)* |
|
||||
| Pick the configuration | Click `Debug \| x64`. Entries the solution does not build the project under are marked with `$(warning)` |
|
||||
| Build / Rebuild / Clean | *.NET Solution: Build* etc., or the `dotnet-solution` tasks |
|
||||
| Debug | The `$(debug-alt)` button, *.NET Solution: Debug Startup Project*, or F5 with the launch.json entry below |
|
||||
| Run without debugging | *.NET Solution: Run Startup Project (without debugging)* |
|
||||
| Pick the startup project | Click the project name (`Ctrl+Alt+P`), or right-click a `.csproj` → *Set as Startup Project (.NET Solution)*. The explorer marks it with ▶ |
|
||||
| Pick the configuration | Click `Debug \| x64` (`Ctrl+Alt+C`). Entries the solution does not build the project under are marked with `$(warning)` |
|
||||
| Build / Rebuild / Clean | *.NET Solution: Build* etc., or the `dotnet-solution` tasks. `Ctrl+Shift+B` until a launch.json entry exists, after that VS Code's default build task |
|
||||
| Publish / Test | *.NET Solution: Publish Startup Project*, *.NET Solution: Run Tests* |
|
||||
| Debug | The `$(debug-alt)` button, *.NET Solution: Debug Startup Project*, or F5 |
|
||||
| Run without debugging | *.NET Solution: Run Startup Project (without debugging)*, or `Ctrl+F5` |
|
||||
| Several `.sln` files | *.NET Solution: Select Solution*, or `dotnetSolution.solution` |
|
||||
|
||||
### F5
|
||||
|
||||
Without a launch.json entry, `F5`, `Ctrl+F5` and `Ctrl+Shift+B` are bound to this
|
||||
extension's debug, run and build commands (only while a solution is loaded and no debug
|
||||
session is running). Once the entry below exists those keys go back to VS Code's own
|
||||
handling, which then uses the entry — same result, but editable in launch.json.
|
||||
|
||||
The first time it sees a solution the extension offers to write a `launch.json` entry.
|
||||
Later, run *.NET Solution: Create launch.json and tasks.json entries* from the command
|
||||
palette, or pick it at the bottom of the startup-project list (click the project name):
|
||||
@@ -87,7 +122,7 @@ palette, or pick it at the bottom of the startup-project list (click the project
|
||||
"type": "coreclr",
|
||||
"request": "launch",
|
||||
"program": "${command:dotnetSolution.activeProgram}",
|
||||
"cwd": "${command:dotnetSolution.activeTargetDir}",
|
||||
"cwd": "${command:dotnetSolution.activeCwd}",
|
||||
"preLaunchTask": "dotnet-solution: Build"
|
||||
}
|
||||
```
|
||||
@@ -103,6 +138,7 @@ The same entry is offered dynamically in the *Run and Debug* dropdown even witho
|
||||
| `dotnetSolution.activeProgram` | apphost `.exe`, or the `.dll` when there is none |
|
||||
| `dotnetSolution.activeTargetPath` | the built assembly |
|
||||
| `dotnetSolution.activeTargetDir` | its directory |
|
||||
| `dotnetSolution.activeCwd` | the working directory after the layering above |
|
||||
| `dotnetSolution.activeProjectPath`, `activeProjectName` | the startup project |
|
||||
| `dotnetSolution.activeSolutionPath` | the solution |
|
||||
| `dotnetSolution.activeConfiguration`, `activePlatform` | solution configuration, e.g. `Test`, `Any CPU` |
|
||||
@@ -116,6 +152,11 @@ The same entry is offered dynamically in the *Run and Debug* dropdown even witho
|
||||
| `dotnetSolution.buildScope` | `solution` | See above |
|
||||
| `dotnetSolution.targetFramework` | `""` | For `TargetFrameworks` projects; empty takes the first |
|
||||
| `dotnetSolution.launch.args` / `.env` / `.cwd` / `.console` | | Passed to the launched application |
|
||||
| `dotnetSolution.launch.projects` | `{}` | The same, per project name; wins over the global ones |
|
||||
| `dotnetSolution.launch.profile` | `""` | launchSettings.json profile to read |
|
||||
| `dotnetSolution.publish.runtime` / `.args` | `""` / `[]` | `-r` and extra arguments for publish |
|
||||
| `dotnetSolution.test.args` | `[]` | Extra arguments for test |
|
||||
| `dotnetSolution.showProblemsOnFailure` | `true` | Open Problems when a task fails |
|
||||
| `dotnetSolution.debugType` | `coreclr` | |
|
||||
| `dotnetSolution.syncDotRush` | `true` | Push the startup project to DotRush and follow its changes |
|
||||
| `dotnetSolution.syncDotRushWorkspaceProperties` | `false` | Write `Configuration=…;Platform=…` into `dotrush.roslyn.workspaceProperties` so IntelliSense sees the same `DefineConstants`. Off because DotRush reloads its workspace on every change |
|
||||
|
||||
Reference in New Issue
Block a user