DEV Community: Calvin A. Allen

Introducing the 'Debugalizers' Visual Studio extension!

Calvin A. Allen — Tue, 27 Jan 2026 12:00:00 +0000

If you've ever found yourself debugging an application and hovering over a string variable that contains a massive blob of minified JSON, XML, or some other structured data - you know the pain. You squint at the DataTip, try to make sense of the wall of text, maybe copy it out to a separate tool to format it, and by then you've lost your debugging flow entirely.

I decided to fix that problem for myself, and now I'm sharing it with you!

Introducing "Debugalizers", a Visual Studio extension that provides beautiful, formatted debug visualizers for over 30 different data formats.

What Does It Do?

When you're debugging and hover over a string variable, you'll see that little magnifying glass icon in the DataTip. Click it, select your Debugalizer of choice, and boom - a proper window pops up with your content beautifully formatted, syntax highlighted, and ready to explore.

The extension supports a wide variety of formats across five categories:

Data Formats

JSON, XML, HTML, YAML, TOML (with formatted, tree, and raw views)
CSV, TSV, INI (table and raw views)
Markdown (rendered and raw)
SQL, GraphQL (syntax highlighted)

Encoded Data

Base64 (decoded, hex, and raw views)
Base64 Images (actual image preview!)
URL Encoded, HTML Entities, Unicode Escape
Hex Strings, GZip, and Deflate (decompressed)

Security & Authentication

JWT tokens (claims table with token breakdown)
SAML (XML tree with claim parsing)
X.509 Certificates (detailed information table)

Structured Strings

Connection Strings (parsed key-value table)
URIs/URLs (parsed components and query parameters)
Query Strings, Regex patterns
Cron expressions (human-readable schedules)

Binary & Low-Level

Hex Dump (with ASCII sidebar)
GUID/UUID (format and version info)
Unix Timestamps (human-readable conversion)
IP Addresses (IPv4/IPv6 with CIDR info)

Interactive Features

It's not just about formatting, though. Each visualizer window gives you:

Search - Hit Ctrl+F to find content within your data
Copy - Grab the raw content or the formatted version
Export - Save to a file for later analysis
Word Wrap - Toggle it on or off as needed
Validation - Visual feedback showing whether your content is valid
Statistics - Line count, character count, byte count at a glance

How To Use It

Install the extension from the Visual Studio Marketplace
Start debugging your application
Hover over any string variable
Click the magnifying glass icon in the DataTip
Select the appropriate Debugalizer from the list
Enjoy actually being able to read your data!

The extension supports Visual Studio 2022 (version 17.8 or later), and it's completely zero-configuration - just install and go.

Why I Built This

I got tired of the dance: hover, squint, copy, paste into an online formatter, lose context, go back to Visual Studio, repeat. Every. Single. Time. With Debugalizers, everything stays right there in Visual Studio where you need it. Your debugging flow stays intact, and you can actually understand what you're looking at without leaving the IDE.

Feel free to check it out, and let me know if you have any suggestions for it - I know there are probably more formats people would love to see visualizers for! PRs accepted, too, if you're into that sort of thing.

And, of course, it's open source, so feel free to peruse the source code, create issues, and have discussions on ways we can make this tool even better!

Introducing the 'Couchbase Explorer' Visual Studio extension!

Calvin A. Allen — Mon, 19 Jan 2026 12:00:00 +0000

Introducing "Couchbase Explorer", an extension for Visual Studio 2022 (and 2026!) that brings Couchbase database browsing and management directly into your IDE. If you've ever found yourself constantly switching between Visual Studio and Couchbase's web console while developing, this extension is for you.

The Vision

Couchbase Explorer is designed to be your Couchbase companion inside Visual Studio. The goal is to let you browse your clusters, explore your data, and work with documents without breaking your development flow or switching context to another application.

Note that this extension is currently in BETA - it's functional, but there's still plenty of work to do. It's also worth mentioning that this is an independent, community-driven project and is not affiliated with, endorsed by, or sponsored by Couchbase, Inc.

Current Features

The initial release focuses on connection management and data browsing:

Multiple Connections - Save and manage connections to multiple Couchbase Server clusters
Secure Credential Storage - Passwords are stored securely using Windows Credential Manager
SSL/TLS Support - Connect securely to clusters with SSL encryption enabled
Hierarchical Tree View - Intuitive navigation: Connections → Buckets → Scopes → Collections → Documents
Document Viewer - Double-click any document to open it in a dedicated editor with formatted JSON and syntax highlighting
Lazy Loading - Efficient handling of large collections with batched document retrieval
Copy Functionality - Quickly copy document contents or document IDs to your clipboard
Refresh Support - Refresh at any level to see the latest data from your cluster
Theme Support - Adapts to Visual Studio's light and dark themes

Getting Started

Once installed, you can access the Couchbase Explorer from the View menu. Right-click in the explorer to add your first connection - you'll need your cluster's connection string, username, and password. The extension will securely store your credentials and connect to your cluster.

From there, you can expand the connection to see your buckets, then scopes, then collections. Expand a collection to browse its documents. Double-click any document to view its contents in a formatted JSON editor.

What's Coming

The roadmap is packed with planned features:

Couchbase Capella Support - Connect to Couchbase's cloud offering
N1QL Query Editor - Write and execute SQL++ queries directly in Visual Studio
Document Editing - Create, update, and delete documents
Index Management - View and manage your cluster indexes
Full-Text Search Integration - Work with FTS indexes
Bulk Import/Export - Move data in and out of your collections
Query Results Panel - View query results in a dedicated tool window
Output/Log Window - Track operations and debug connection issues

You can check out the full issue list on GitHub to see everything that's planned and track progress.

Get It Now

Feel free to check it out on the Visual Studio Marketplace, and let me know if you have any suggestions! It's open source on GitHub, so issues and PRs are happily accepted if you're into that sort of thing.

Introducing the 'Git Ranger' Visual Studio extension!

Calvin A. Allen — Fri, 16 Jan 2026 12:00:00 +0000

Introducing "Git Ranger", an extension for Visual Studio 2022 (and 2026!) that brings enhanced Git tooling directly into your editor. If you've ever used GitLens in VS Code, this extension draws inspiration from that experience and aims to bring similar capabilities to Visual Studio.

The Vision

Git Ranger is designed to be a comprehensive Git companion for Visual Studio developers. The goal is to surface Git information where you need it, when you need it - without breaking your flow or switching context.

Current Features

The initial release focuses on inline Git information:

Inline Annotations - See who last modified each line, when, and why - right in your editor
Gutter Margin - A visual indicator in the left margin showing commit history at a glance
Theme-Adaptive Colors - 12 vibrant colors that automatically adjust for dark and light themes
Author Color Coding - Each contributor gets their own distinctive color
Age Heat Map Mode - Optional visualization showing relative age of changes
Interactive Tooltips - Hover to see full commit details
Copy Commit SHA - Quick access to commit hashes via click or menu command

Customization

Git Ranger is highly configurable. Head to Tools → Options → Git Ranger where you can adjust display options, color modes, date formats, caching behavior, and more.

What's Coming

The roadmap is packed with planned features:

Git CodeLens for methods and classes
File History and Line History tool windows
Visual Git Graph with styling and interactions
Status bar indicator
Branch and Tag management tool windows
Commit Details and Contributors views
Diff integration
Remote provider integrations (GitHub, GitLab, etc.)
Git Command Palette
Stash management
Interactive rebase editor
AI-powered commit message generation

You can check out the full issue list on GitHub to see everything that's planned and track progress.

Get It Now

Introducing the Visual Studio Code MCP Server!

Calvin A. Allen — Thu, 15 Jan 2026 12:00:00 +0000

Yesterday I introduced the Visual Studio MCP Server. Today, it's VS Code's turn.

VSC MCP Server

VSC MCP Server exposes VS Code's language intelligence features as MCP tools. Once connected, an AI assistant can:

Get symbols from documents and workspaces
Navigate to definitions and find references
Get IntelliSense completions and signature help
Run diagnostics, format code, and rename symbols
Search files and text across the entire workspace

All the things you take for granted when coding in VS Code — now available to your AI tools.

What's Under the Hood

VS Code has incredibly powerful language features built in. IntelliSense, Go to Definition, Find All References, hover info, call hierarchies — these aren't just UI conveniences. They're backed by language servers that deeply understand your code.

The problem is that this intelligence is locked inside VS Code. An AI tool running alongside the IDE can't tap into any of it. It has to rely on its own understanding of your codebase, which means re-parsing files, guessing at types, and missing context that VS Code already has.

This extension bridges that gap. It wraps VS Code's language server commands and exposes them through MCP, giving AI assistants access to the same semantic understanding that powers your daily coding experience.

The Tools

The extension exposes 30 MCP tools organized into categories:

Code Navigation & Analysis

document_symbols — Get all symbols in a file (functions, classes, variables)
workspace_symbols — Search symbols across the entire workspace
go_to_definition — Find where a symbol is defined
find_references — Find all usages of a symbol
hover_info — Get type information and documentation at a position
call_hierarchy — Get incoming and outgoing function calls
type_hierarchy — Get type inheritance chains

Completions & Suggestions

get_completions — Get IntelliSense code completions
get_signature_help — Get function signature and parameter info
get_code_actions — Get available quick fixes and refactorings

Formatting & Refactoring

format_document — Format an entire document
format_range — Format a specific range
organize_imports — Sort and organize imports
rename_symbol — Rename a symbol across all references

Diagnostics & Workspace

diagnostics — Get errors and warnings for files or the workspace
search_workspace_files — Search for files using glob patterns
search_workspace_text — Search text across the entire workspace

Write operations support dry-run mode, so the AI can preview changes before applying them.

Getting Started

Install the extension from the Visual Studio Marketplace, or search for "VSC as MCP" in the Extensions view.

The MCP server starts automatically when VS Code launches. By default, it listens on port 4000. Configure your MCP client to connect to:

{
  "mcpServers": {
    "vscode": {
      "url": "http://localhost:4000/mcp"
    }
  }
}

That's it. Your AI assistant can now query VS Code's language intelligence directly.

Configuration

If you need to change the defaults, head to Settings and search for codingwithcalvin.mcp:

Setting	Default	Description
`autoStart`	`true`	Start the server when VS Code launches
`port`	`4000`	Port for the MCP server
`bindAddress`	`127.0.0.1`	Bind address (localhost only for security)

You can also control the server from the Command Palette:

MCP Server: Start — Start the server
MCP Server: Stop — Stop the server
MCP Server: Restart — Restart the server
MCP Server: Show Available Tools — View all available tools

Security

The server only binds to localhost by default. It validates the Host header to prevent DNS rebinding attacks and restricts CORS to localhost origins. No authentication is required since it assumes same-machine local access is trusted.

What's Next

This is v0.1.0. The tool coverage is solid, but there's always room for more. I'm looking at exposing debugging capabilities, terminal integration, and task execution. If there's something you'd find useful, let me know.

Wrapping Up

The source is on GitHub. If you run into issues or have ideas for additional tools, open an issue or send a PR.

Thanks for reading!

Introducing the Visual Studio MCP Server!

Calvin A. Allen — Wed, 14 Jan 2026 12:00:00 +0000

JetBrains is shipping MCP servers for their IDEs. Visual Studio isn't.

So I wrote one.

VS MCP Server

VS MCP Server exposes Visual Studio features as MCP tools. Once connected, an AI assistant can:

Get information about your currently open solution and projects
Open, close, read, and write documents
Work with text selections and navigate the editor
Trigger builds and check build status

All through the MCP protocol. It doesn't matter if you're using Claude Desktop, Cursor, Windsurf, or any other MCP-compatible client - they all speak the same language.

The Architecture

Visual Studio extensions run on the UI thread, and blocking that is a recipe for a sluggish IDE. An MCP server needs to handle HTTP connections and process requests, so doing all that on the main thread wasn't going to work.

The solution was to split things up. The extension spawns a separate process to handle HTTP/SSE communication with MCP clients. That process talks back to the Visual Studio extension via named pipes using JSON-RPC. Visual Studio stays responsive, the MCP server handles requests without blocking anything.

flowchart LR
    A[MCP Client<br/>Any AI Tool] <-->|HTTP/SSE<br/>:5050| B[MCPServer.Server<br/>Out of process]
    B <-->|Named Pipes<br/>JSON-RPC| C[VS Extension<br/>VS Integration]

Getting Started

The extension is available on the Visual Studio Marketplace. Install it, configure settings at Tools > Options > MCP Server if needed, then start the server via Tools > MCP Server > Start Server (or enable auto-start).

From there, configure your MCP client to connect to http://localhost:5050/sse. The extension supports Visual Studio 2022 and 2026, on both ARM64 and AMD64.

For the full list of available tools and configuration options, check out the GitHub repo.

What's Next

The current toolset covers the basics - solutions, documents, editor operations, and builds. But there's a lot more potential here. I'm planning to integrate Roslyn to enable deeper code exploration capabilities. Imagine asking your AI assistant to find all usages of a method, or get the signature of a class, or navigate through the semantic model of your code. That's where things get really interesting.

Wrapping Up

This is a new project, and I'm still finding the rough edges. If you run into issues or have ideas for additional tools, let me know. The source is on GitHub, and as always, I'm open to feedback and contributions.

Thanks for reading!

Introducing rnr - A Zero-Dependency Task Runner

Calvin A. Allen — Mon, 12 Jan 2026 12:00:00 +0000

Have you ever cloned a repository, ready to contribute, only to discover you need to install Node.js, Python, Make, or some other global dependency just to run the build? I have. Many times. And honestly, it's frustrating.

I wanted something simpler. Something where contributors could clone a repo and immediately run tasks without any setup. No "first, install this runtime" steps. No version mismatches. Just clone and go.

So I built rnr (pronounced "runner").

What is rnr?

rnr is a cross-platform task runner with one key differentiator: the binaries live inside your repository. When a contributor clones your project, they already have everything they need to run your build tasks. Zero friction.

It's written in Rust, compiles to native binaries for all major platforms, and uses a simple YAML configuration file to define your tasks.

The Problem

Most task runners require contributors to have something installed globally:

npm scripts require Node.js
Makefiles require Make (and good luck on Windows)
Just requires installing just
Task requires installing task

For maintainers, this is fine. But for contributors—especially those making quick documentation fixes or small improvements—asking them to install a runtime just to run a build is a barrier.

The Solution

With rnr, you initialize once as a maintainer:

# Linux
curl -fsSL https://github.com/CodingWithCalvin/rnr.cli/releases/latest/download/rnr-linux-amd64 -o rnr
chmod +x rnr
./rnr init

# macOS (Apple Silicon)
curl -fsSL https://github.com/CodingWithCalvin/rnr.cli/releases/latest/download/rnr-macos-arm64 -o rnr
chmod +x rnr
./rnr init

# Windows (PowerShell)
Invoke-WebRequest -Uri "https://github.com/CodingWithCalvin/rnr.cli/releases/latest/download/rnr-windows-amd64.exe" -OutFile "rnr.exe"
.\rnr.exe init

The init command presents an interactive selector where you choose which platforms your contributors might use:

Which platforms should this project support?

  [x] linux-amd64 (760 KB)
  [] macos-amd64 (662 KB)
  [x] macos-arm64 (608 KB) <- current
  [x] windows-amd64 (584 KB)
  [] windows-arm64 (528 KB)

  Selected: 1.95 MB total

Once you confirm, rnr downloads the appropriate binaries and sets up wrapper scripts. Here's what gets created:

your-repo/
├── .rnr/
│ ├── config.yaml # Tracks configured platforms
│ └── bin/ # Platform binaries (only selected ones)
├── rnr # Unix wrapper script (auto-detects platform)
├── rnr.cmd # Windows wrapper script
└── rnr.yaml # Your task definitions

The wrapper scripts automatically detect the current platform and architecture, then run the correct binary from .rnr/bin/. Commit all of this to your repo.

After that, contributors simply run:

./rnr build # Run your build task
./rnr test # Run your tests
./rnr --list # See all available tasks

That's it. No installation required on their end.

Defining Tasks

Tasks are defined in an rnr.yaml file at the root of your repository. The syntax is intentionally simple.

Simple one-liners:

build: cargo build --release
test: cargo test
lint: cargo clippy

Full task definitions with descriptions, working directories, and environment variables:

build:
  description: Build for production
  dir: src/backend
  env:
    NODE_ENV: production
  cmd: npm run build

Sequential steps that reference other tasks:

ci:
  description: Run CI pipeline
  steps:
    - task: lint
    - task: test
    - task: build

Parallel execution for speeding up independent operations:

build-all:
  description: Build all services
  steps:
    - cmd: echo "Starting builds..."
    - parallel:
        - task: build-api
        - task: build-web
    - cmd: echo "All done!"

Nested task files for monorepos—subdirectories can have their own rnr.yaml:

# Root rnr.yaml
api:build:
  dir: services/api
  task: build # Runs 'build' from services/api/rnr.yaml

Built-in Commands

rnr ships with a few built-in commands:

rnr <task> — Execute a task from your rnr.yaml
rnr init — Initialize rnr in the current directory
rnr upgrade — Update to the latest rnr binaries
rnr --list — View all available tasks
rnr --version — Display the current version
rnr --help — Show help information

Why Rust?

I chose Rust for a few reasons:

Single binary — No runtime dependencies, just a native executable
Cross-platform — Compiles cleanly to Windows, macOS, and Linux
Performance — Fast startup, minimal overhead
I wanted to learn more Rust — Let's be honest, this was a big motivator

Get Started

If you maintain an open source project and want to reduce friction for contributors, give rnr a try:

Download the binary for your platform from the releases page
Run ./rnr init and select your target platforms
Create your rnr.yaml with your tasks
Commit the binaries and config to your repo

Your contributors will thank you.

I'm already using rnr on a couple of my own projects—dtvem.cli and rnr.cli itself. Yes, rnr builds rnr. Dogfooding at its finest.

What's Next?

This is v0.1.0, so there's plenty more I want to add:

Task dependencies (depends: [build, test])
Conditional execution (if: ${{ env.CI }})
Watch mode (watch: [src/**/*.rs])
Variable interpolation (${{ vars.version }})
Caching and incremental builds
Interactive task picker

If any of these would be useful for your workflow, let me know—or better yet, open an issue on GitHub.

It's Open Source

rnr is MIT licensed and available on GitHub at CodingWithCalvin/rnr.cli. If you find bugs, have feature requests, or want to contribute, PRs are absolutely welcome.

I'd love to hear what you think. Let me know if you try it out!

Introducing vscwhere!

Calvin A. Allen — Thu, 08 Jan 2026 12:00:00 +0000

If you've ever used Microsoft's vswhere, you know how handy it is. Need to find where Visual Studio is installed? Run vswhere. Need the path for a CI/CD script? vswhere -latest -property installationPath. It just works.

But what if you need to find Visual Studio Code instead?

So I built it.

Introducing vscwhere

vscwhere is a CLI tool that locates Visual Studio Code installations on Windows. Think of it as vswhere's little sibling — same idea, same familiar interface, just for VS Code instead of Visual Studio.

Need to find all your VS Code installations? Just run:

vscwhere

That's it. You'll get a list of all the VS Code installations on your machine — Stable and Insiders builds alike.

The Options

If you're familiar with vswhere, you'll feel right at home:

Options:
  -all Find all instances (default)
  -prerelease Include prerelease (Insiders) builds
  -latest Return only the latest version
  -format <type> Output format: text (default), json
  -property <name> Return value of specified property
  -nologo Suppress version banner
  -sort Sort instances by version (descending)
  -help, -? Display this help message

Need JSON for your build scripts? -format json. Just want the latest stable version's path? -latest -property installationPath. Need to include Insiders builds? -prerelease.

Example Output

Here's what it looks like in action. Running vscwhere with no arguments:

> vscwhere
VSCWhere version 0.1.0

installationPath: C:\Users\calvin.allen\AppData\Local\Programs\Microsoft VS Code\
installationVersion: 1.107.1
productPath: C:\Users\calvin.allen\AppData\Local\Programs\Microsoft VS Code\Code.exe
productId: stable
isPrerelease: false
displayName: Visual Studio Code
extensionsPath: C:\Users\calvin.allen\.vscode\extensions
userDataPath: C:\Users\calvin.allen\AppData\Roaming\Code

And with -format json:

> vscwhere -format json
VSCWhere version 0.1.0

[
  {
    "installationPath": "C:\\Users\\calvin.allen\\AppData\\Local\\Programs\\Microsoft VS Code\\",
    "installationVersion": "1.107.1",
    "productPath": "C:\\Users\\calvin.allen\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe",
    "productId": "stable",
    "isPrerelease": false,
    "displayName": "Visual Studio Code",
    "extensionsPath": "C:\\Users\\calvin.allen\\.vscode\\extensions",
    "userDataPath": "C:\\Users\\calvin.allen\\AppData\\Roaming\\Code"
  }
]

Also, the most important for workflows, -nologo (and combine it with JSON output):

> vscwhere -nologo -format json
[
  {
    "installationPath": "C:\\Users\\calvin.allen\\AppData\\Local\\Programs\\Microsoft VS Code\\",
    "installationVersion": "1.107.1",
    "productPath": "C:\\Users\\calvin.allen\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe",
    "productId": "stable",
    "isPrerelease": false,
    "displayName": "Visual Studio Code",
    "extensionsPath": "C:\\Users\\calvin.allen\\.vscode\\extensions",
    "userDataPath": "C:\\Users\\calvin.allen\\AppData\\Roaming\\Code"
  }
]

How Does It Work?

Here's where it gets a little unusual. VS Code doesn't write any special registry keys when it's installed — there's no convenient "here's where I live" entry to read. The only registry presence VS Code has is its uninstall entries.

So that's what vscwhere uses. It finds the uninstall entries in the Windows Registry and works backwards to determine the actual installation directory. It's a reliable way to find installations regardless of where the user chose to install them — and really, it's the only way without resorting to scanning the entire filesystem.

Why Rust?

Executable size. That's it. A .NET trimmed, single-file binary clocked in at 12MB. The Rust version? Under 1MB. For a simple CLI tool that finds VS Code installations, 12MB felt absurd. Rust gives me a tiny, dependency-free binary that's fast and easy to distribute. No runtime dependencies, no installers — just download the executable and run it.

Current Limitations

A few things to note:

Windows only — macOS and Linux support may come later, but for now it's Windows-focused
No portable installations — it finds Stable and Insiders builds installed the normal way, but won't detect portable VS Code installations

Get It

vscwhere is available from GitHub releases. Grab the latest binary and drop it somewhere in your PATH:

github.com/CodingWithCalvin/vscwhere

This is an early release — version 0.1.0 — so there's plenty of room for improvement. If you've got ideas or run into issues, let me know!

As always, I accept pull requests :)

Introducing the Developer Tools Virtual Environment Manager!

Calvin A. Allen — Mon, 05 Jan 2026 12:00:00 +0000

If you've ever tried to manage multiple versions of Python, Node.js, or Ruby on Windows, you know the pain. Tools like nvm, pyenv, and rbenv work great on macOS and Linux, but Windows support ranges from "hacky workarounds" to "just use WSL." And even on Unix systems, you're juggling three different tools with three different configurations.

So I built something better.

Introducing dtvem

dtvem (Developer Tools Virtual Environment Manager) is a unified, cross-platform runtime version manager written in Go. One tool to manage Python, Node.js, and Ruby — and it works identically on Windows, macOS, and Linux.

No shell hooks. No .bashrc modifications. No WSL required. Just install it and go.

Why Another Version Manager?

The existing tools are great, but they all have the same problem: Windows is an afterthought. And if you work across multiple runtimes, you're maintaining separate tools with separate configurations.

dtvem takes a different approach:

Windows is a first-class citizen — not an afterthought or "community port"
Shim-based architecture — works in cmd.exe, PowerShell, bash, zsh, fish, whatever
One tool for multiple runtimes — Python, Node.js, and Ruby today, with Go, Rust, and Java on the roadmap
Project-local versions — drop a config file in your project and the right versions activate automatically

How It Works

dtvem uses shims instead of shell integration. When you run python or node, it intercepts the command and routes it to the correct version based on your configuration.

The resolution order is simple:

Local config — .dtvem/runtimes.json in your project (or any parent directory)
Global config — ~/.dtvem/config/runtimes.json for system-wide defaults
System PATH — falls back to whatever's installed on your system

No magic. No shell hooks. It just works.

Getting Started

Installation is a one-liner.

Windows (PowerShell):

irm dtvem.io/install.ps1 | iex

macOS / Linux:

curl -fsSL dtvem.io/install.sh | bash

Once installed, the workflow is straightforward:

# Install a runtime version
dtvem install python 3.12.0
dtvem install node 22.0.0

# Set global defaults
dtvem global python 3.12.0
dtvem global node 22.0.0

# Set project-specific versions
cd my-project
dtvem local python 3.10.0
dtvem local node 18.20.0

# Check what's active
dtvem current

That's it. Navigate into my-project and Python 3.10.0 and Node 18.20.0 are automatically active. Navigate out and your global versions take over.

Migrating from Existing Tools

Already using nvm, pyenv, or rbenv? dtvem can import your existing installations:

dtvem migrate node # Import from nvm or fnm
dtvem migrate python # Import from pyenv
dtvem migrate ruby # Import from rbenv, rvm, chruby, or uru

It detects your existing version managers, copies the installed versions, preserves your globally installed packages, and optionally cleans up the old installations. You can run both tools side-by-side during the transition if you want a gradual migration.

The Website

All the details live at dtvem.io. You'll find:

Getting Started guide — installation and basic workflow
Command reference — all 18 commands documented
Runtime guides — specifics for Python, Node.js, and Ruby
Migration guide — step-by-step for switching from other tools
Comparison page — how dtvem stacks up against nvm, pyenv, rbenv, asdf, and mise

The install scripts are served directly from the domain, so the one-liner installations just work.

Get It / Contribute

dtvem is pre-1.0 but fully functional. The core runtimes are stable, and I'm working on adding Go, Rust, and Java.

Both projects are open source under the MIT license:

CLI: github.com/CodingWithCalvin/dtvem.cli
Website: github.com/CodingWithCalvin/dtvem.io

If you're tired of juggling multiple version managers — or you've been stuck on Windows without good options — give dtvem a try.

As always, I accept pull requests :)

Introducing the Visual Studio Toolbox!

Calvin A. Allen — Fri, 02 Jan 2026 12:00:00 +0000

If you've ever used JetBrains Toolbox, you know how convenient it is. It's the central hub for all your JetBrains IDEs — install new tools, manage updates, launch any version with a single click. Everything in one place, tucked away in the system tray.

The other day I was clicking around in JetBrains Toolbox and it hit me — why doesn't Visual Studio have something like this? I've got multiple versions installed, experimental hives for extension development, and I'm constantly hunting through the Start menu to find the right one. Turns out this was exactly what I needed but didn't know I wanted.

So I built it.

Introducing Visual Studio Toolbox

Visual Studio Toolbox is a Windows system tray application that serves as mission control for Visual Studio. It automatically detects all your Visual Studio installations — 2019, 2022, 2026, experimental hives, the whole lot — and puts them one click away.

No more hunting through the Start menu. No more trying to remember which version you need for that legacy project. Just click the tray icon and pick the one you want.

What Can It Do?

Here's the quick rundown of features:

One-Click Launch

Each Visual Studio instance in the list has a play button right there — click it and that version launches. That's it. That's the whole thing.

Developer Tools at Your Fingertips

Click the gear icon on any instance and you get quick access to:

Developer Command Prompt — because sometimes you just need that environment
Developer PowerShell — same deal, but PowerShell flavored
Open Installation Folder — jump straight to where VS lives on disk
Open AppData Folder — for when you need to poke around in settings and extensions

The list of command prompt and PowerShell options is driven by your Windows Terminal profiles. If you've got custom profiles set up, they'll show up here. If you don't have Windows Terminal installed or don't have any profiles, it falls back to a single Developer Command Prompt and single Developer PowerShell option.

Stays Out of Your Way

The app lives in your system tray. You can configure it to:

Launch on Windows startup
Start minimized
Minimize to tray instead of taskbar
Close to tray (so it's always ready when you need it)

The Tech Stack

For those curious about what's under the hood:

C# 13 and .NET 10
WinUI 3 with Windows App SDK 1.8
H.NotifyIcon.WinUI for the system tray functionality
MVVM Community Toolkit for keeping things clean and testable

I wanted to build this with modern Windows development tech, and WinUI 3 gave me exactly what I needed — a native Windows look and feel with proper light/dark theme support (complete with that sweet Visual Studio purple accent color).

Getting the window styled the way I wanted took some effort though. I was going for a specific look — no traditional Windows chrome, square borders, a flat aesthetic. WinUI 3 doesn't make that trivial out of the box, but after some wrestling with window customization APIs, I got it where I wanted it.

Get It / Contribute

Visual Studio Toolbox is open source under the MIT license. Grab a portable executable from the GitHub releases, or check out the source:

👉 github.com/CodingWithCalvin/VSToolbox

Eventually there will be an MSIX package on the Microsoft Store — when I have time to figure that whole process out.

This is still early days — version 0.1.1 just shipped — so there's plenty of room for new features and improvements. If you've got ideas or run into issues, let me know!

As always, I accept pull requests :)

SDK-style Projects for your Visual Studio Extensions!

Calvin A. Allen — Thu, 01 Jan 2026 12:00:00 +0000

Remember that post I wrote last week about creating MSBuild SDKs? Well, I wasn't just writing that for fun - I was actually building something with all that knowledge.

I've released CodingWithCalvin.VsixSdk, an MSBuild SDK that brings modern SDK-style .csproj files to Visual Studio extension development. No more XML soup!

The Problem

If you've ever created a Visual Studio extension, you know the pain. The .csproj file looks like it was written in 2008 (because it basically was). Hundreds of lines of XML, explicit file includes for everything, and don't even get me started on trying to understand what half of those properties do.

Sure, you could migrate from packages.config to PackageReference in the old format - Visual Studio has supported that for years - but you'd still be stuck with all that verbose XML and manual file management.

And here's the kicker - without an SDK-style project, you can't use dotnet build from the command line. You're stuck invoking MSBuild directly, like some kind of caveman. Meanwhile, every other .NET project gets to use the nice, clean SDK-style format and the dotnet CLI:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
</Project>

Why should VSIX projects be stuck in the past?

The Solution

With my new SDK, your VSIX project can look like this:

<Project Sdk="CodingWithCalvin.VsixSdk/0.3.0">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <RootNamespace>MyAwesomeExtension</RootNamespace>
    <AssemblyName>MyAwesomeExtension</AssemblyName>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.VisualStudio.SDK" Version="17.*" />
  </ItemGroup>
</Project>

That's it. That's the whole thing. The SDK handles all the VSSDK build tools, the manifest processing, the VSCT compilation - everything that used to require dozens of lines of cryptic XML. And yes, you can now just run dotnet build like everybody else!

Getting Started

The easiest way to get started is with the dotnet template:

# Install the template
dotnet new install CodingWithCalvin.VsixSdk.Templates

# Create a new extension
dotnet new vsix -n MyExtension --publisher "Your Name" --description "My awesome extension"

# Build it
cd MyExtension
dotnet build

The template sets up everything you need - the project file, the manifest, the whole nine yards.

What You Get

Beyond the clean project file, the SDK includes some features I'm pretty proud of:

Source Generators

The SDK automatically generates a VsixInfo class from your manifest:

// Auto-generated - use these anywhere in your code
public static class VsixInfo
{
  public const string Id = "MyExtension.a1b2c3d4-...";
  public const string Version = "1.0.0";
  public const string Publisher = "Your Name";
  public const string DisplayName = "My Extension";
  // ... and more
}

No more hardcoding strings that get out of sync with your manifest. Just use VsixInfo.Version and you're done.

If you have .vsct files, you get generated constants for those too - GUIDs, command IDs, menu groups, all as strongly-typed constants.

Version Override at Build Time

If you've ever tried to automate versioning a VSIX in CI/CD, you know how painful it is. You'd typically have to run some kind of sed or PowerShell regex to find and replace the version in the manifest XML, then trigger a separate build step, and hope you didn't break the XML formatting in the process. It's fragile and annoying.

With this SDK, it's just:

dotnet build -p:SetVsixVersion=2.0.0

One command. The SDK updates the manifest, regenerates the constants, and builds the VSIX with the correct version everywhere. Perfect for GitHub Actions where you want to version based on tags or run numbers:

- name: Build Release
  run: dotnet build -c Release -p:SetVsixVersion=${{ github.ref_name }}

No more grep/sed gymnastics.

Auto-Inclusion

The SDK automatically includes common VSIX files like .vsct files and VSPackage.resx. You don't have to explicitly list them anymore - they just work.

A Real-World Example

I've already migrated my Open in Notepad++ extension to use this SDK. Here's what the project file looks like now:

<Project Sdk="CodingWithCalvin.VsixSdk/0.3.0">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <RootNamespace>CodingWithCalvin.OpenInNotepadPlusPlus</RootNamespace>
    <AssemblyName>CodingWithCalvin.OpenInNotepadPlusPlus</AssemblyName>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <DeployExtension>True</DeployExtension>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.VisualStudio.SDK" Version="17.14.40265" />
  </ItemGroup>

  <ItemGroup>
    <Content Include="..\..\resources\icon.png" Link="resources\icon.png">
      <IncludeInVSIX>true</IncludeInVSIX>
    </Content>
    <Content Include="..\..\LICENSE" Link="resources\LICENSE">
      <IncludeInVSIX>true</IncludeInVSIX>
    </Content>
  </ItemGroup>
</Project>

Compare that to the hundreds of lines it used to be. F5 debugging works, the VSIX builds correctly, deploys to the experimental instance - everything just works.

Migrating an Existing Project

If you have an existing extension you want to migrate, the process is pretty straightforward:

Back up your project - Always a good idea before major changes
Replace the .csproj content - Swap out all that legacy XML for the SDK-style format
Update the manifest - Remove support for versions prior to VS 2022, and add support for VS 2026 (version range [17.0, 19.0)). While you're in there, it's a good time to add arm64 support too.
Add your PackageReferences - If you were already using PackageReference, just move them over. If not, convert your package references now.
Delete the cruft - Remove packages.config (since you've migrated to PackageReference in the previous step), Properties/AssemblyInfo.cs, and any explicit file includes
Build and test - Run dotnet build and fix any issues

The README on GitHub has a detailed migration guide with before/after examples and a checklist.

Requirements

Visual Studio 2022 or later
.NET Framework 4.7.2+ target framework

The SDK is specifically for VS 2022+ extensions. If you're still supporting older versions of Visual Studio, you'll need to stick with the legacy project format for now.

Wrapping Up

I built this SDK because I got tired of fighting with legacy project files every time I wanted to create or update an extension. If you're building Visual Studio extensions and want a cleaner development experience, give it a try.

The SDK is available on NuGet and the source is on GitHub. If you run into issues or have ideas for improvements, let me know - I'm always looking to make this thing better.

Creating Your Own MSBuild SDK - It's Easier Than You Think!

Calvin A. Allen — Thu, 25 Dec 2025 12:00:00 +0000

This post is part of the 2025 C# Advent Calendar.

Check it out here, for other AWESOME posts.

I'll be honest - I put off learning how MSBuild SDKs work for way too long. Every time I saw that Sdk="Microsoft.NET.Sdk" attribute at the top of a .csproj file, I just accepted it as magic and moved on. But recently I needed to create a custom SDK, and after banging my head against the wall for a bit, I finally figured it out.

Spoiler: it's not nearly as scary as I thought.

What Even Is an MSBuild SDK?

Before we dive in, let's clear up what we're actually talking about. An MSBuild SDK is basically a NuGet package that automatically imports .props and .targets files into your project. That's it. That's the whole thing.

When you write:

<Project Sdk="MyAwesome.Sdk/1.0.0">

MSBuild goes "oh, you want that SDK?" and then imports Sdk.props at the very beginning and Sdk.targets at the very end of your project. Everything in between is your actual project content.

The Folder Structure

Here's what your SDK package needs to look like:

MyAwesome.Sdk/
├── Sdk/
│ ├── Sdk.props ← Imported first
│ └── Sdk.targets ← Imported last
└── MyAwesome.Sdk.csproj

The Sdk/ folder is the magic folder. MSBuild looks there specifically.

Creating the Props File

The .props file runs before anything else in the project. This is where you set up defaults:

<Project>
  <PropertyGroup>
    <!-- Set defaults that users can override -->
    <TargetFramework Condition="'$(TargetFramework)' == ''">net8.0</TargetFramework>
    <ImplicitUsings Condition="'$(ImplicitUsings)' == ''">enable</ImplicitUsings>

    <!-- Properties you always want set -->
    <MyCustomProperty>true</MyCustomProperty>
  </PropertyGroup>
</Project>

See those Condition attributes? That's the key pattern. You're saying "only set this if the user hasn't already set it." This lets your SDK provide sensible defaults while still allowing customization.

Creating the Targets File

The .targets file runs after the project content. This is where you do the real work:

<Project>
  <!-- Auto-include certain files -->
  <ItemGroup Condition="'$(EnableDefaultMyItems)' != 'false'">
    <None Include="**/*.config" />
  </ItemGroup>

  <!-- Add custom build targets -->
  <Target Name="MyCustomTarget" BeforeTargets="Build">
    <Message Importance="high" Text="Look ma, I'm in a custom SDK!" />
  </Target>

  <!-- Validate configuration -->
  <Target Name="ValidateStuff" BeforeTargets="BeforeBuild">
    <Warning Condition="'$(SomeProperty)' == ''"
             Text="Hey, you probably want to set SomeProperty." />
  </Target>
</Project>

Wrapping Other SDKs

Here's where it gets interesting. You probably don't want to recreate everything from scratch - you want to build on top of the existing .NET SDK. The pattern looks like this:

Sdk.props:

<Project>
  <!-- Import the base SDK props first -->
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

  <!-- Then add your customizations -->
  <PropertyGroup>
    <MyCustomDefault>true</MyCustomDefault>
  </PropertyGroup>
</Project>

Sdk.targets:

<Project>
  <!-- Your custom logic first -->
  <ItemGroup>
    <None Include="**/*.special" />
  </ItemGroup>

  <!-- Then import base SDK targets -->
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

The order matters here. Props imports happen outside-in (base first, then yours), and targets happen inside-out (yours first, then base). At least, that's what made sense for my use case - your mileage may vary.

The .csproj for Your SDK Package

Your SDK project itself is pretty minimal:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <PackageId>MyAwesome.Sdk</PackageId>
    <Version>1.0.0</Version>
    <PackageType>MSBuildSdk</PackageType>
    <IncludeBuildOutput>false</IncludeBuildOutput>
    <SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking>
  </PropertyGroup>

  <ItemGroup>
    <None Include="Sdk\**" Pack="true" PackagePath="Sdk" />
  </ItemGroup>
</Project>

The important bits:

PackageType>MSBuildSdk - tells NuGet this is an SDK package
IncludeBuildOutput>false - you're not shipping a DLL, just the props/targets
That ItemGroup makes sure your Sdk/ folder ends up in the right place in the package

Testing Locally (The Part I Struggled With)

This is where I wasted the most time. You can't just dotnet build and expect Visual Studio to find your SDK. Here's what actually works:

Build your SDK package: dotnet pack -c Release
Add your output folder as a local NuGet source
Reference the exact version in your test project

Or, the sneaky way - during development, just use Microsoft.NET.Sdk in your test project and manually import your props/targets:

Directory.Build.props:

<Project>
  <Import Project="../src/MyAwesome.Sdk/Sdk/Sdk.props" />
</Project>

Directory.Build.targets:

<Project>
  <Import Project="../src/MyAwesome.Sdk/Sdk/Sdk.targets" />
</Project>

This way you can iterate without constantly rebuilding packages. Just switch to the real Sdk="..." reference when you're ready to ship.

Common Gotchas

A few things that tripped me up:

Props vs Targets confusion - If your defaults aren't working, you probably put them in targets instead of props. Properties need to be set before the project content, not after.
Condition syntax - It's Condition="'$(Prop)' == ''" with single quotes inside double quotes. I mess this up constantly.
Import order matters - Some properties from other SDKs or build tools need to be set super early in props, before they get evaluated. If something isn't working, try moving it earlier in the import chain.
The casing matters - The folder must be Sdk/ with a capital S. Lowercase won't work on case-sensitive file systems.
NuGet caching will drive you insane - When testing locally, NuGet aggressively caches packages. Either bump your version number every time, or clear the cache with dotnet nuget locals all --clear. Trust me on this one.

Wrapping Up

Creating an MSBuild SDK isn't rocket science - it's really just packaging up props and targets files in a specific folder structure. The hardest part is figuring out which properties go where and what order to import things.

If you're building something that needs consistent project configuration across multiple projects, or you're wrapping complex build tooling behind a simpler interface, an SDK is a great way to go.

If you have questions or run into issues I didn't cover, let me know - I'm still learning this stuff myself and always happy to compare notes.