DotNet Tools

A desktop VS Code extension by Sann Lynn Htun for modern SDK-style C#/.NET and ASP.NET Core projects, including standalone Blazor WebAssembly, without C# Dev Kit or the Microsoft C# extension. Version 0.1.6 uses extension ID burma-forge.burma-forge-dotnet-tools. Windows functional checks and Linux-container checks have evidence; full visual and macOS/Linux desktop release validation remains pending.

Requirements

• VS Code 1.144.1 or later. Windows x64 is the currently exercised host; macOS/Linux release validation remains pending.
• A compatible .NET SDK on PATH, matching your global.json. Building .slnx requires an SDK supporting that format (9.0.200+).
• A trusted local workspace for running tools, reading the clipboard, or creating/editing files. Restricted mode permits metadata viewing only.

Install the local burma-forge-dotnet-tools-0.1.6.vsix using Extensions → … → Install from VSIX, then reload VS Code if prompted. The accompanying .vsix.sha256 records its SHA-256 checksum; compare it with Get-FileHash -Algorithm SHA256 on Windows. See CHANGELOG.md for changes and known release limits.

Publisher display name: Burma Forge. Publisher ID: burma-forge. Extension ID: burma-forge.burma-forge-dotnet-tools. Author: Sann Lynn Htun. This is a separate Marketplace identity from the old dotnet-tools.dotnet-daily-tools listing. Disable or uninstall that old extension (or an earlier local build) before installing this identity to avoid duplicate commands. Saved selections belong to each identity separately; no automatic upgrade or state migration is performed.

Use

Open the .NET Tools Activity Bar icon. Select a .sln, .slnx, or .csproj build target and Debug/Release, then Build or Rebuild. Clean/Restore are in the Solution view's … menu. Progress is cancellable; output uses the .NET Tools channel, and located compiler errors appear in Problems.

Projects shows solution folders and project references. Select a project for code/tool context; explicitly use Set as Startup Project to choose the app to run. Framework/profile rows open native pickers. Run starts the app without a debugger; Stop terminates only the app process tree started here. Build target, selected project, and startup project are separate.

Selecting/restoring a startup project automatically fills a single statically known framework and a single Project launch profile (ignoring IIS Express and other unsupported launch types). With no Project profile it uses no launch profile. Multiple frameworks or Project profiles still require a choice on Run; click the rows to choose explicitly. Existing manual choices, including Default (no profile), are preserved when reselecting the same startup project.

Run keeps the project/configuration/framework/profile selected when invoked, including across a restart confirmation. A saved profile must still exist and use the Project launch type; otherwise choose another profile or Default. Conditional/imported metadata requires consent to SDK evaluation and is checked for the chosen framework and configuration before launch.

Opening .sln/.slnx through the extension's default custom editor reveals the sidebar on fresh opens. Open as Text remains available; user editor associations are respected. At startup VS Code does not expose a reliable distinction between restored custom editors and CLI-opened tabs: initial tabs retain your saved target and sidebar focus. Use Show solution in .NET Tools or the Open Solution command to activate that file explicitly when necessary. An external solution offers a new window containing its folder; existing work is preserved. The extension never changes OS associations or builds/restores on open. Invalid/expired solution-open handoffs cannot abort extension activation.

In a C# editor use Paste JSON as Classes, enter a root name, review the read-only preview, then use the preview toolbar (or Command Palette) to Insert Generated Classes or Cancel Generation. Finish that preview before starting another conversion. Insertion is one undo step and is rejected if the source selection/document changed or an old preview is active. Conversion is local, limited to 1 MiB/64 levels, preserves JSON names, and warns where sample values cannot determine a safe type. Add Type creates Class/Interface/Enum/Record files after destination/namespace review, without overwriting files.

Manage NuGet Packages and EF Core Tools are explicitly Planned informational dialogs. They show project context and future workflows; no package queries, installations, migrations, or database operations run.

Develop and validate

npm ci
npm test
$env:VSCODE_EXECUTABLE = 'C:\path\to\Code.exe'
npm run test:integration
$env:DOTNET_TOOLS_TEST_MODE = 'restricted'
npm run test:integration
Remove-Item Env:DOTNET_TOOLS_TEST_MODE
npm run package

Without VSCODE_EXECUTABLE, the test runner downloads the pinned VS Code test version. Integration tests use an isolated profile/extensions directory and small local SDK fixtures. They build/run test code and write only generated fixture/test artifacts. Tests do not require the user's C# extensions. Press F5 to launch a development host, or install the generated VSIX using Extensions → … → Install from VSIX. No publishing command is part of the workflow.

scripts/configure-manifest.cjs regenerates command/menu declarations when modifying those declarations. The packaged extension consumes package.json directly.

npm run test:sdk runs the additional real-SDK matrix, with deterministic simulated dialog answers and disposable OS-temp fixtures. It currently requires SDKs 8.0.422, 10.0.302 and 11.0.100 plus the .NET 8/10 runtimes; it installs none of them. It covers SDK selection/failures, argument safety, multi-framework/profile Run, restart snapshots and conditional/imported property evaluation. Its simulated UI assertions do not replace native desktop checks.

Linux container checks can be reproduced with docker build -t dotnet-tools-release-check -f test/linux/Dockerfile test/linux, then run that image with the checkout mounted read-only at /work, --init, and either --test out/test/unit/*.test.js or test/linux/smoke.cjs. Compile first on the host. These exercise POSIX process groups and real SDK operations, not a Linux desktop UI. No macOS result is claimed.

Limits

No legacy .NET Framework/non-SDK project support, debugger, language server, test explorer, Watch, publish, or remote/browser host support. Conditional/imported project metadata may require explicit SDK evaluation, which can execute trusted project code. Native sidebar selectors/actions intentionally adapt the image mockup to VS Code's standard controls.

SDK Build/Run can perform their normal implicit restore and execute trusted project targets. Cancellation/Stop may leave partially written build artifacts and is not rollback. No SDK/tool auto-installation, telemetry, clipboard logging, or remote JSON conversion is added.

To retain ownership of cancellable project execution, child processes disable shared MSBuild server/node reuse. This affects only tools launched by the extension and may increase build startup time. Windows Stop/Cancel force-terminates the owned process tree; app shutdown hooks are not guaranteed to run.

Design documents (spec.md, plan.md, tasks.md, validation.md) are in specs/001-dotnet-daily-tools/ in the source checkout and are excluded from the VSIX.