🔍 Monitor Dotnet

📊 Real-time monitoring for .NET applications in VS Code — CPU load, memory, garbage collection, counters, metrics and environment variables. The monitor opens by itself when you start debugging. No web dashboard, no extra services — everything runs locally.

🇷🇺 Русская версия: README.ru.md · 📋 Changelog: CHANGELOG.md

✨ Features

✅ Requirements

For Aspire projects the Aspire CLI has to be installed: it is the CLI that starts the AppHost project. The Aspire extension for VS Code is optional — monitoring attaches to the same process as the debugger.

The application you monitor does not have to be .NET 10: EventPipe has been available since .NET Core 3.0, so .NET 5 apps and newer work as well. Windows, Linux and macOS are supported — private memory, environment variables and the command line are read through platform APIs. Mono and Unity are not supported.

🚀 Quick start

1. 📦 Install the extension (see Build from source below for a local build).
2. ⌨️ Press F5 on any .NET project, or run Monitor Dotnet: Start Monitoring from the command palette.
3. 📊 The Monitor Dotnet panel appears in the activity bar with live charts and counters.

🐞 Debug integration

Sessions of other .NET types (clr for .NET Framework, dotnet-core) are recognised as well. In an Aspire solution the dashboard, the orchestrator and the CLI are never offered as targets.

F# projects work the same way: Ionide debugs them through the coreclr session and puts the built assembly into program, and the same rules pick the application process. .fsproj is understood wherever a project file can be given. Profiling itself is runtime-level — the bridge reads EventPipe — so the language of the application does not matter.

🎯 Choosing the process

When several applications run together — an Aspire AppHost with its services, or a compound launch — you pick which process to monitor. Process in the panel header lists everything running:

The process detected for a session is remembered, so switching is instant. Monitoring is never switched behind your back: when a second debug session starts, the first one keeps being monitored and the extension offers to switch. When the monitored session ends, the extension suggests another running process.

📊 Performance panel

Three charts update once per second, plus a row of current-value tiles.

Colours come from the current theme, so the panel looks native in light, dark and high-contrast themes.

🩺 Automatic issue detection

The extension watches the charts and marks suspicious time ranges on its own:

Every issue gets a coloured band on the matching chart and an entry in the list above the charts: the severity badge (ℹ️ info, ⚠️ warning, 🔴 critical), the moment it started and a short explanation. Click an entry to select its time range — the charts zoom out to fit it and the range summary appears underneath. Turn the whole thing off with monitor-dotnet.enableIssueDetection.

The same list lives in the native Issues view next to the charts, with a theme icon per severity and the interval in the description. It works even with the panel closed: clicking an issue opens the charts and selects that interval.

The list is a report of the run, not a slice of the current data. Problems are kept per process: the chart panel and its bands always belong to the process shown on the charts, while the Issues view keeps the history and groups it by process (name and PID, with the monitored one marked, the monitored group expanded first).

Every issue keeps its own data. When the live charts have already moved past an interval — or it belongs to another process — clicking the issue shows that saved interval: the charts are drawn from the stored points with some context around it, a band marks the exact range, the summary below gives min / avg / max and GC numbers, and a banner names the process and offers Back to live data. So an old issue can still be analysed; only the points that were never collected are lost. The next debug session starts the list over, and Clear Collected Data forgets it as well.

🔢 Counters and metrics

The Counters view lists two kinds of data:

• 🧾 EventCounters — classic counters grouped by provider (System.Runtime, Microsoft.AspNetCore.Hosting, your own EventSource)
• 📐 Metrics — System.Diagnostics.Metrics instruments grouped by meter, including tagged series

Pick what to collect in the settings:

"monitor-dotnet.counterProviders": [
  "System.Runtime",                  // every counter of the provider
  "MyProvider[Counter1,Counter2]"    // only the listed counters
],
"monitor-dotnet.metricProviders": ["*"]  // all meters, or "MyMeter", or "MyMeter\\MyInstrument"

🌱 Environment

The Environment view shows what the application was started with:

• 🔤 environment variables of the process
• 🖥️ system properties: .NET version, startup flags, command line, OS, architecture
• 🔍 filter by name or value, and copy any value to the clipboard

🛠 Profiling on demand

Buttons in the Performance view title bar:

If a tool is missing, the extension offers to install it with one command (dotnet tool install --global …).

⚙️ Settings

🌍 Languages

The extension speaks the language of your VS Code interface.

• 🇬🇧 English — source language of every string
• 🇷🇺 Russian — complete translation

🏗️ How it works

┌────────────────────────── VS Code ──────────────────────────┐
│  Monitor Dotnet extension (TypeScript)                       │
│                                                              │
│  extension.ts ──► MonitorController ──► Bridge process       │
│                        │                    │ NDJSON (stdout)│
│                        ▼                    ▼                │
│  MonitorState (series, counters, metrics)  BridgeLocator     │
│            │                                                 │
│            ├─► Performance panel   (canvas charts, webview)  │
│            ├─► Counters view       (tree)                    │
│            ├─► Environment view    (tree)                    │
│            └─► Status bar          (CPU and memory)          │
└──────────────────────────────────────────────────────────────┘
                              ▲
                              │ one JSON message per line
                              ▼
┌─────────── Bridge (MonitorDotnet.Bridge, .NET 10) ───────────┐
│  EventPipe session:                                          │
│   • EventCounters                  → provider counters       │
│   • System.Diagnostics.Metrics     → meters                  │
│   • Microsoft-Windows-DotNETRuntime → GC events, heap stats  │
│  Operating system: private memory, environment, command line │
└──────────────────────────────────────────────────────────────┘

A VS Code extension cannot read EventPipe directly, so collection happens in a small .NET process. It attaches to the target process, parses the event stream and sends ready-made samples to the extension.

📁 Project structure

🧪 Build from source

Requirements: .NET SDK 10, Node.js 20+, VS Code 1.100+.

npm install
npm run bridge:build   # publish the .NET bridge to media/bridge and dist/bridge
npm run build          # bundle the extension and the charts panel
npm run package        # create monitor-dotnet-1.0.0.vsix
code --install-extension monitor-dotnet-1.0.0.vsix

Useful commands:

🔐 Privacy

• 🚫 No telemetry, no accounts, nothing is uploaded: the extension collects data locally and never sends it anywhere. The only network access happens when you confirm it — installing a missing diagnostic tool with dotnet tool install or opening the .NET diagnostics documentation.
• 🏠 All data is collected locally by the bridge process and shown only inside VS Code.
• 🗂️ Profile files and memory snapshots are written where you point them (the temporary directory by default).

📄 License

MIT — full text in LICENSE. © 2026 Dmitry Sorokin (dimanrus).