Your .NET solution has 15 projects, hundreds of files, and a mountain of generated code. You open Claude Code, ask it to add a feature, and halfway through the session it starts forgetting things you told it five minutes ago.

That’s not a bug. That’s the context window filling up. And in a large .NET solution, it fills up fast.

I’ve spent months working with Claude Code in solutions ranging from 5 to 30+ projects. Here’s what I’ve learned about keeping the context clean and your sessions productive.

The problem: .NET solutions are noisy

A typical .NET solution generates a lot of stuff you don’t want Claude Code to read. Every project has bin/ and obj/ folders. Entity Framework creates migration files that can be hundreds of lines each. Visual Studio generates .Designer.cs files, .g.cs files, and various XML artifacts.

When Claude Code scans your solution, it reads all of it. Every migration. Every generated file. Every compiled artifact it can find. That’s context budget you’re spending on noise instead of signal.

The result: Claude Code runs out of room for the code that actually matters — your business logic, your endpoints, your domain models.

.claudeignore — your first line of defense

Just like .gitignore tells Git what to skip, .claudeignore tells Claude Code what to ignore. Create this file in your solution root and list everything Claude Code shouldn’t read.

Here’s the .claudeignore I use for most .NET solutions:

# Build output
bin/
obj/
publish/

# Generated code
*.Designer.cs
*.g.cs
*.g.i.cs
*.generated.cs

# Entity Framework migrations
**/Migrations/

# Frontend build artifacts (if you have a SPA)
**/wwwroot/lib/
**/node_modules/

# IDE and tooling
.vs/
.idea/
*.user
*.suo

# Test output
TestResults/
coverage/

# NuGet
packages/

# Large data files
**/*.bacpac
**/*.bak

This single file can cut the noise in your solution by 60-80%. Migrations alone can be thousands of lines that Claude Code doesn’t need to understand your current code.

Important: don’t exclude your test projects. Claude Code needs those to run tests and verify changes. And don’t exclude your .csproj files — they contain dependency information that helps Claude Code understand your architecture.

/compact — reclaim context mid-session

Even with a good .claudeignore, long sessions eat context. You’ve been working for 20 minutes, asked Claude Code to read several files, made a few changes, and you can feel it getting slower and less precise.

That’s when you use /compact. This command tells Claude Code to summarize the conversation so far and free up context space. It keeps the important stuff — what you’re working on, what files you’ve changed, what decisions you’ve made — and drops the details it no longer needs.

I use /compact roughly every 15-20 minutes in a large solution. Think of it as clearing your desk: you keep the documents you’re actively working with and file the rest away.

A good habit: after Claude Code finishes a major change and you’ve verified it works, run /compact before starting the next task.

CLAUDE.md for monorepos and multi-project solutions

If your solution has a dozen projects, a single CLAUDE.md in the root isn’t enough. Claude Code supports CLAUDE.md files in subdirectories — and they’re only loaded when Claude Code works in that directory.

Structure it like this:

MySolution/
├── CLAUDE.md                    # Solution-level: architecture, conventions
├── .claudeignore                # What to skip
├── src/
│   ├── MyApp.Api/
│   │   └── CLAUDE.md            # API-specific: endpoints, auth, middleware
│   ├── MyApp.Domain/
│   │   └── CLAUDE.md            # Domain rules, entity conventions
│   └── MyApp.Infrastructure/
│       └── CLAUDE.md            # EF Core config, external services
└── tests/
    └── CLAUDE.md                # Test conventions, how to run tests

The root CLAUDE.md describes the overall architecture and shared conventions. The project-level files describe specifics that only matter when working in that project.

This way Claude Code loads only the context it needs. Working on an endpoint? It reads the API CLAUDE.md. Fixing a database issue? It reads the Infrastructure one. No wasted context on information it doesn’t need right now.

Work in focused sessions

This is the biggest mindset shift for working with Claude Code in large solutions: don’t try to do everything in one session.

One session, one focus. “Add the notification endpoint and its tests.” Not “Refactor the notification system, add the new endpoint, update the database, fix the logging, and oh also update the README.”

When you switch to a completely different part of the solution — say from the API layer to a background worker project — start a fresh session. The context from the API work won’t help you in the worker project. It’ll just take up space.

I typically work in 20-30 minute focused sessions. One feature, one project area, one clear goal. Then I commit, start fresh, and move on.

/clear — when to start fresh

/clear wipes the entire conversation and starts a new session without leaving your terminal. Use it when:

  • You’ve finished a task and want to start something unrelated
  • Claude Code is getting confused or repeating itself
  • You’ve been going back and forth on an approach and want a clean slate

Don’t use /clear when you’re in the middle of a multi-step change. If Claude Code is halfway through implementing a feature across multiple files, clearing the context means it loses track of what it already did. Use /compact instead.

The rule of thumb: /compact to trim, /clear to restart.

Structure your prompts around specific files

In a small project you can say “look at the code and add a feature.” In a large solution, that’s asking Claude Code to read 200 files to find the 3 it needs.

Be specific:

Instead of: “Add a notification endpoint.”

Say: “In src/MyApp.Api/Endpoints/, add a notification endpoint following the same pattern as UserEndpoints.cs. The query handler should go in src/MyApp.Application/Notifications/.”

You’re pointing Claude Code at exactly the right files and directories. It spends context on the code that matters, not on scanning your entire solution to figure out where things go.

The same goes for fixing bugs. Instead of “the notification feature is broken,” say “the GetNotifications handler in src/MyApp.Application/Notifications/GetNotificationsHandler.cs returns an empty list when there should be results. The test in tests/MyApp.Tests/Notifications/GetNotificationsTests.cs shows the expected behavior.”

More context in your prompt means less context Claude Code has to spend figuring things out.

A practical example

Here’s what my typical workflow looks like in a large .NET solution:

  1. Start a fresh session in the solution root
  2. Tell Claude Code what I’m working on: “I need to add a soft-delete feature to the Order entity in the Domain project, update the EF Core configuration in Infrastructure, and add a delete endpoint in the API.”
  3. Work through it step by step: domain first, then infrastructure, then API
  4. Run tests after each step: “Run the tests in tests/MyApp.Domain.Tests”
  5. /compact after the domain changes are done before moving to infrastructure
  6. Commit when the feature is complete
  7. /clear before starting the next task

This approach keeps the context focused, the sessions manageable, and the results predictable.

Start optimizing today

If you’re working with Claude Code in a .NET solution with more than a handful of projects, create a .claudeignore file today. It takes five minutes and the difference is immediate.

Then look at your CLAUDE.md. Is it one giant file trying to describe everything? Split it up. Put project-specific context where it belongs.

And most importantly: stop trying to do everything in one session. Focused work with clean context beats marathon sessions every time. Your context window is a resource — spend it on the code that matters.