Claude Code for .NET Developers: From Zero to Productive in VS Code and Visual Studio

Here is the pattern that plays out constantly with AI coding tools: you try one, it blows your mind. You use it for a week, and it starts feeling random. Sometimes it's brilliant; sometimes it confidently suggests code from three framework versions ago. You stop trusting it, and it fades into the "cool but not practical" category.

The problem is not the model. The problem is that you are using a powerful tool without understanding how it works. Claude Code is different from a chat window, and once you understand its mechanics — how it discovers context, how you shape its behavior, how you extend it with custom commands — it becomes genuinely reliable for .NET work.

This article covers everything: installation, VS Code integration, the honest story about Visual Studio 2022 and 2026, CLAUDE.md (the most important file you are not writing yet), context management, Skills, and MCP. Whether you are new to AI tooling or already use it daily, there is something here for you.

What Is Claude Code, Exactly?

Claude Code is not a chatbot that happens to know about code. It is a CLI-first, agentic coding assistant built by Anthropic. The key distinction: it operates on your actual repository. It can read files, run commands, edit code, and chain multiple steps together without you narrating every move.

The mental model that helps most: Claude Code is a skilled contractor who just walked into your codebase. Give them the right context, and they can work independently. Give them nothing, and they will ask questions — or worse, make assumptions.

There are two surfaces you will use:

• The CLI (claude) — runs in any terminal, works with any editor
• The VS Code extension (anthropic.claude-code) — embeds the CLI experience directly into VS Code, with file awareness, selection sharing, and inline diffs

Both use the same model and the same context system. The extension is additive convenience on top of the CLI, not a separate product.

Installation and Setup

Prerequisites

You need Node.js 22 LTS or later. Check with:

node --version

Install Claude Code globally:

npm install -g @anthropic-ai/claude-code

Authenticate:

claude

The first run opens a browser for OAuth with your Anthropic account. After that, your credentials are stored locally and the CLI works offline-first (the model calls still go to Anthropic's API, of course).

VS Code Integration

Install the extension from the marketplace. The ID is anthropic.claude-code. You need VS Code 1.98 or later.

Once installed, a Claude icon appears in the activity bar. Open it, sign in, and you have a chat panel that is deeply aware of your open files, your current selection, and your workspace structure. You can also invoke it inline with Ctrl+Shift+C (Windows/Linux) or Cmd+Shift+C (Mac) to open a quick input without leaving your editor flow.

The extension does something important automatically: when you highlight code and ask a question, it attaches that selection as context. You do not have to copy-paste. This alone saves significant friction on large codebases.

If you use JetBrains Rider, there is also full Claude Code integration available through the JetBrains Marketplace. The experience is comparable to VS Code. Rider users are covered — you can follow this entire article and apply it directly.

Visual Studio 2022 and 2026: The Honest Story

Visual Studio has been the king of .NET IDEs for decades — it just has not heard of Claude yet.

As of June 2026, there is no official Claude Code extension for Visual Studio 2022 or 2026. GitHub Copilot has deep VS integration; Claude Code does not. This is not a temporary oversight — the extension model for Visual Studio is substantially different from VS Code, and Anthropic has focused on the VS Code surface.

The workaround is simple and it works well: use the integrated terminal.

Open it with View > Terminal (or Ctrl+\`). Then run:

bash
claude


Claude Code starts in your repo's root directory. It reads everything — your .cs files, your .csproj, your appsettings.json, your CLAUDE.md. The terminal-based experience is the same CLI you would use anywhere. You lose the inline diff rendering and selection-sharing that the VS Code extension provides, but the model's capabilities are identical.

Practical tip: keep Visual Studio open for debugging, the designer, and refactoring tooling (where it is unmatched), and open VS Code or a terminal alongside it for Claude interactions. Many .NET developers already do this. It is not a compromise — it is using each tool for what it is best at.

CLAUDE.md — The Brain of the Operation

This is the most important section in the article.

Every time Claude Code starts in a directory, it performs a filesystem walk. It moves upward from the current working directory, looking for CLAUDE.md files. It also lazily loads CLAUDE.md files found in subdirectories as it encounters them during work. The result is a layered context system: a root CLAUDE.md for the whole repo, and optionally per-project or per-module files for specific concerns.

CLAUDE.md is not magic. It is just a Markdown file. But it is the file Claude reads before doing anything else. Think of it as your onboarding document for a contractor who starts fresh every session.

What Claude Does NOT Know Without CLAUDE.md

Without any instruction file, Claude Code will:

• Guess your build system from file structure
• Assume generic conventions
• Ask clarifying questions repeatedly
• Make mistakes that a three-minute onboarding would prevent

With a good CLAUDE.md, Claude knows your exact dotnet commands, your test runner, your architecture decisions, your naming conventions, and any constraints specific to your project. It stops guessing and starts working.

Discovery in Visual Studio: A Common Gotcha

CLAUDE.md lives at the root of your repository — the same directory as your .sln file. Visual Studio's Solution Explorer shows files based on what is referenced in .csproj or .sln files. Since CLAUDE.md is not referenced by either, it will not appear in Solution Explorer.

This trips people up. They create the file, it does not show up in VS, they assume something is wrong. Nothing is wrong. Claude loads it perfectly. Open it directly in VS Code or a plain text editor to edit it.

To verify what Claude has loaded, run:

plaintext
/memory


This lists all context files currently active in the session. If CLAUDE.md is loaded, it appears here. This is your ground truth.

A Practical CLAUDE.md for a .NET Project

Here is an example for a realistic ASP.NET Core project:

`markdown

OrderService

ASP.NET Core 10 minimal API backed by PostgreSQL via EF Core 10.
Authentication: JWT with ASP.NET Core Identity.
Deployed to Azure Container Apps via GitHub Actions.

Build

`bash
dotnet build OrderService.sln
`

Tests

`bash

Run all tests

dotnet test OrderService.sln

Run only unit tests

dotnet test tests/OrderService.UnitTests/

Run with coverage

dotnet test OrderService.sln --collect:"XPlat Code Coverage"
`

Architecture

• src/OrderService.Api/ — minimal API endpoints, no business logic here
• src/OrderService.Domain/ — domain models, value objects, interfaces
• src/OrderService.Application/ — CQRS handlers (MediatR), validators (FluentValidation)
• src/OrderService.Infrastructure/ — EF Core, repositories, external HTTP clients
• tests/OrderService.UnitTests/ — xUnit, Moq, domain and application layer only
• tests/OrderService.IntegrationTests/ — xUnit, Testcontainers, full API stack

Conventions

• Use record types for immutable domain models and DTOs
• Use C# 14 field keyword instead of explicit backing fields where applicable
• All nullable reference types enabled; annotate accordingly
• No var — use explicit types everywhere
• Async all the way down; no .Result or .Wait()
• Repository interfaces in Domain layer; implementations in Infrastructure
• Endpoint classes in Features/ folders grouped by domain concept (vertical slice)

EF Core

• Migrations in src/OrderService.Infrastructure/Migrations/
• Add migration: dotnet ef migrations add <Name> --project src/OrderService.Infrastructure --startup-project src/OrderService.Api
• Apply: dotnet ef database update --project src/OrderService.Infrastructure --startup-project src/OrderService.Api

Do Not

• Do not add business logic to endpoint handlers
• Do not use dynamic or object as return types
• Do not skip FluentValidation for command/query inputs
• Do not add new NuGet packages without noting them here `plaintext

This file takes about fifteen minutes to write and saves hours of back-and-forth over the lifetime of a project. The investment is obvious once you have it.

Generating a Starter CLAUDE.md

If you are not starting from scratch, Claude Code can inspect your repo and generate a first draft:


/init
plaintext

This reads your solution structure, existing documentation, and common patterns, then writes a CLAUDE.md that reflects what it found. Treat the output as a starting point — review it, correct anything wrong, and add the domain knowledge Claude cannot infer (architecture decisions, team conventions, known pitfalls).

Giving Claude Context

Even with a great CLAUDE.md, you will often need to point Claude at specific files during a conversation. The @ mention syntax does this precisely.

File and Directory Mentions


@Program.cs
csharp

Attaches the full content of Program.cs to the current message.


@src/OrderService.Application/
plaintext

Attaches a directory listing. Claude will then read specific files from it as needed, rather than loading everything upfront.


@appsettings.json#1-20
plaintext

Attaches only lines 1 through 20. Useful when you care about a specific section of a large config file and do not want to burn context on the rest.

VS Code Selection Sharing

When you use the VS Code extension, any code you highlight in the editor is automatically shared when you open the Claude panel. You do not need @ mentions for your active selection — it is already there. This makes "explain this method" or "what does this LINQ query do" workflows completely frictionless.

Managing Long Contexts

Long sessions accumulate context. After several hours of work, Claude's context window fills with earlier conversation turns that are no longer relevant. When responses start feeling less sharp, run:


/compact
plaintext

This summarizes the conversation history into a compressed form, freeing up context space without losing the thread of what you have been working on. Think of it as telling the contractor to forget the small talk and remember only the decisions.

Skills — Custom Commands for Your Workflow

Skills are reusable, invocable commands that extend Claude Code's default behavior. They live as Markdown files and you invoke them with a / prefix, just like built-in commands. There are two scopes:

• Personal skills — stored in ~/.claude/skills/<skill-name>/SKILL.md. Available in every project on your machine.
• Project skills — stored in .claude/skills/<skill-name>/SKILL.md in your repo root. Checked into source control, shared with the team.

A skill file is a Markdown document that tells Claude what to do when invoked. It can include steps, decision logic, expected outputs, and even inline prompts.

Here are three practical examples for .NET development.

Skill: /dotnet-test

File: .claude/skills/dotnet-test/SKILL.md

`markdown

dotnet-test

Run the test suite for this project and summarize the results.

Steps

1. Run dotnet test using the command from CLAUDE.md (check the "Tests" section).
2. Parse the output for failed tests.
3. For each failure:
   • Show the test name
   • Show the failure message
   • Show the stack trace trimmed to the first 5 lines
4. If all tests pass, confirm with a short success message.
5. If build errors prevent tests from running, show the build errors instead.

Output Format

Group failures by project. Keep the summary concise — one paragraph max,
followed by a numbered list of failures if any exist.
`

Invoke with /dotnet-test. Claude runs your test command, reads the output, and gives you a clean summary instead of a wall of terminal text.

Skill: /csharp-review

File: .claude/skills/csharp-review/SKILL.md

`markdown

csharp-review

Review the provided C# code for modern idiom usage and correctness.

What to Check

• Records: Are mutable classes used where record or record struct would be more appropriate?
• Init-only properties: Are setters used where init would suffice?
• Pattern matching: Are if/switch chains that could use switch expressions or positional patterns?
• Nullable annotations: Are reference types properly annotated? Any ! suppressors hiding problems?
• Primary constructors: Could a class use C# 12+ primary constructor syntax?
• field keyword: Are there explicit backing fields that C# 14's field keyword could eliminate?
• Async: Any .Result, .Wait(), or async void outside of event handlers?
• LINQ: Any imperative loops that would read more clearly as LINQ?

Output Format

List each finding as:

• [Category] Description of the issue
• Suggested rewrite (code block, 10 lines max)

End with a one-sentence overall assessment.
`

Invoke with /csharp-review while a file is open (or with @filename if using the CLI). You get actionable, .NET-specific feedback rather than generic suggestions.

Skill: /ef-migrate

File: .claude/skills/ef-migrate/SKILL.md

`markdown

ef-migrate

Guide through EF Core migration management for this project.

Steps

1. Run the dotnet ef migrations list command from CLAUDE.md to show existing migrations. Use the correct --project and --startup-project flags from CLAUDE.md.
2. Show the migration list, noting which have been applied (indicated by [applied]).
3. Ask the user: "Do you want to add a new migration, or apply pending ones?"
4. If adding a migration:
   • Ask for the migration name (PascalCase, descriptive, e.g., AddOrderStatusIndex)
   • Run dotnet ef migrations add <Name> with correct flags
   • Show which files were created
   • Ask if they want to review the generated migration before applying
5. If applying pending migrations:
   • Confirm the number of pending migrations
   • Run dotnet ef database update with correct flags
   • Report success or errors

Safety Note

Always mention that migrations modify the database schema. Remind the user to review
generated migrations before applying to staging or production environments.
`

This skill turns what is normally a multi-step, flag-heavy CLI workflow into a guided conversation. It uses the migration commands already defined in your CLAUDE.md, so it adapts to each project automatically.

MCP — Connecting External Tools

Model Context Protocol (MCP) is a standard that lets Claude connect to external data sources and tools beyond your local filesystem. Where Skills extend what Claude does, MCP extends what Claude can see.

A few examples relevant to .NET teams:

• GitHub MCP — Claude can read PR diffs, check CI status, and leave review comments directly, without you copy-pasting GitHub URLs into the chat
• Azure DevOps MCP — Claude can read your current sprint, query work items, and understand the backlog when you ask it to help prioritize or plan
• Database MCP — Claude can query your local or dev database schema to inform code generation, without you having to paste CREATE TABLE statements

MCP servers are configured in your Claude Code settings and are available across all sessions. For .NET teams working in Azure DevOps or GitHub, setting up the corresponding MCP server once pays dividends on every PR review and sprint planning task after that.

VS Code vs Visual Studio: An Honest Comparison

Both IDEs are legitimate for .NET work. Here is where each one stands with Claude Code:

The pragmatic answer for most .NET developers: use both. VS Code for AI-assisted coding, exploration, and file editing; Visual Studio for debugging sessions, UI designers, and deep refactoring. They open the same project files and there is no conflict. Many developers keep both open simultaneously without issue.

If you have to pick one: pure backend services (ASP.NET Core APIs, worker services, console apps) work well with VS Code as your primary. Anything with Windows Forms, WPF, or complex debugger needs warrants Visual Studio as primary with Claude Code in the terminal.

Key Takeaways

• CLAUDE.md is not optional — it is the difference between an AI that guesses and one that knows your codebase. Write it, commit it, keep it current. Run /init to generate a starting point from your existing repo.

• Visual Studio is fully usable — the lack of a native extension is a real limitation, but View > Terminal and the claude CLI give you full Claude Code functionality. The file-awareness and Skills system work identically.

• Context is everything — use @ mentions to target specific files, use line ranges to stay precise, and use /compact when sessions get long. Precision in context leads to precision in output.

• Skills are multipliers — a fifteen-minute investment writing a project skill pays back immediately. Codify your team's review criteria, your test workflow, your migration process. Claude Code executes them consistently every time.

• The model is not random — your context is — when Claude gives you a bad answer, the fix is almost always better context: a clearer CLAUDE.md, a more specific @ mention, or a well-written skill. Understanding the context system turns a frustrating tool into a reliable one.

The architecture is simple once you see it: CLAUDE.md tells Claude who you are and how your project works, @ mentions tell Claude what to look at right now, and Skills tell Claude how to handle your recurring tasks. Stack those three things on top of a capable model and the "random magic" feeling goes away entirely. What you get instead is a coding assistant that behaves like someone who has actually read the codebase.

Which, thanks to CLAUDE.md, it has.