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.
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:
claude
) — runs in any terminal, works with any editoranthropic.claude-code
) — embeds the CLI experience directly into VS Code, with file awareness, selection sharing, and inline diffsBoth use the same model and the same context system. The extension is additive convenience on top of the CLI, not a separate product.
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).
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 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.
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.
Without any instruction file, Claude Code will:
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.
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.
Here is an example for a realistic ASP.NET Core project:
``markdown`
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.
``bash`
dotnet build OrderService.sln
`
``bash`
dotnet test OrderService.sln
dotnet test tests/OrderService.UnitTests/
dotnet test OrderService.sln --collect:"XPlat Code Coverage"
`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`record`
types for immutable domain models and DTOs`field`
keyword instead of explicit backing fields where applicable`var`
— use explicit types everywhere`.Result`
or `.Wait()`
`Features/`
folders grouped by domain concept (vertical slice)`src/OrderService.Infrastructure/Migrations/`
`dotnet ef migrations add <Name> --project src/OrderService.Infrastructure --startup-project src/OrderService.Api`
`dotnet ef database update --project src/OrderService.Infrastructure --startup-project src/OrderService.Api`
`dynamic`
or `object`
as return types
plaintextThis 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.
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).
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.
@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 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.
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.
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 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:
`~/.claude/skills/<skill-name>/SKILL.md`
. Available in every project on your machine.`.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.
`/dotnet-test`
**File:** `.claude/skills/dotnet-test/SKILL.md`
``markdown`
Run the test suite for this project and summarize the results.
`dotnet test`
using the command from CLAUDE.md (check the "Tests" section).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.
`/csharp-review`
**File:** `.claude/skills/csharp-review/SKILL.md`
``markdown`
Review the provided C# code for modern idiom usage and correctness.
`record`
or `record struct`
would be more appropriate?`init`
would suffice?`if`
/`switch`
chains that could use `switch`
expressions or positional patterns?`!`
suppressors hiding problems?`field`
keyword`field`
keyword could eliminate?`.Result`
, `.Wait()`
, or `async void`
outside of event handlers?List each finding as:
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.
`/ef-migrate`
**File:** `.claude/skills/ef-migrate/SKILL.md`
``markdown`
Guide through EF Core migration management for this project.
`dotnet ef migrations list`
command from CLAUDE.md to show existing migrations.
Use the correct `--project`
and `--startup-project`
flags from CLAUDE.md.`dotnet ef migrations add <Name>`
with correct flags`dotnet ef database update`
with correct flagsAlways 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.
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:
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.
Both IDEs are legitimate for .NET work. Here is where each one stands with Claude Code:
| Feature | VS Code + Claude Extension | Visual Studio 2022/2026 + Terminal |
|---|---|---|
| Claude Code integration | Native extension, inline diffs, selection sharing | Terminal only, CLI-based |
| Debugging experience | Good (but not VS-level) | Best in class for .NET |
| CLAUDE.md support | Full | Full (file not shown in Solution Explorer) |
| Skills / MCP | Full | Full (terminal invocation) |
| Designer tools (WinForms, WPF) | Limited | Full |
| Refactoring tools | Good | Excellent (ReSharper-level built-in) |
| Hot Reload / Edit and Continue | Good | Best in class |
| Extension ecosystem | Vast | .NET-focused, deep OS integration |
| Cost | Free | Community free; Pro/Enterprise paid |
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.
**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.