The risk in a C# refactor is silent breakage at a callsite you did not know about, usually in another project inside the same .sln. Atlas closes that gap before touching anything: the lsp tool's documentSymbol operation maps the module's public surface, findReferences enumerates every caller of each exported symbol, and a green baseline from xUnit via dotnet test pins current behavior. Restructuring then happens through apply_patch, which anchors on context lines and refuses to apply against a drifted file, and you re-run `dotnet test` after each hunk rather than once at the end.
How do I find every caller of a legacy C# class before refactoring it?
Map the C# module's public surface with Atlas's lsp tool documentSymbol operation, then run findReferences on each exported symbol to enumerate every callsite. In a .NET solution with 12 projects, findReferences reaches across the .sln through the language server, which grep across one .csproj would never do.
A legacy C# module usually has more callers than its author remembers, spread across other projects referenced through the `.sln` and `.csproj` graph. Atlas's first move is enumeration, not editing. The lsp tool's documentSymbol operation lists what the module actually exposes: the public classes, the public methods, the interfaces it implements. Then findReferences runs on each exported symbol and returns the language server's caller set, which spans project boundaries because the language server understands project references. Atlas also searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion and indexes code by AST declarations using tree-sitter, so a C# hit is a whole method or class declaration rather than a blind line window. The enumeration is the deliverable of this step: you now know the true blast radius before a single line of `LegacyOrderService.cs` changes.
Why should I run dotnet test before changing any C# code?
Pin behavior first: run the existing tests with Atlas's bash tool and record the green baseline before changing anything. In 2026 a C# refactor is still defined as a change that does not change behavior, and without a green xUnit via dotnet test run beforehand you cannot prove that property afterward.
The baseline is the contract. Run `dotnet test` through Atlas's bash tool on the affected projects and record what green looks like: how many xUnit tests pass, which ones are skipped, how long the run takes. If the suite is already red before you start, that is information worth having, because otherwise the first failure after your first hunk will look like your fault. Atlas's bash tool races commands against a timeout, so a slow `dotnet test` across a large `.sln` should be run with a generous timeout in milliseconds rather than killed mid-run. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the `dotnet test` invocation is one you approved. With a green baseline recorded, every subsequent red is attributable to exactly one apply_patch.
How does apply_patch restructure C# code without corrupting it?
Atlas restructures C# 1 hunk at a time with apply_patch, which seeks each hunk's context and old_lines and fails with Failed to find context if the file has drifted. A patch against a LegacyOrderService.cs that was auto-formatted since Atlas read it fails loudly rather than landing in the wrong method.
apply_patch is context-anchored, and during a legacy C# refactor that property is the whole safety story. Each hunk carries the surrounding lines it expects to find. If `LegacyOrderService.cs` changed since Atlas read it, whether because `dotnet format` ran or because a teammate pushed, apply_patch fails with Failed to find context instead of guessing at a location. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each restructuring hunk is shown before it lands, and Atlas snapshots file changes as git patches so any hunk can be diffed and rolled back. In practice a legacy C# module gets restructured one hunk at a time: extract an interface, move a method, split a god class into two files under the same namespace, each one reviewed on its own.
How often should I run xUnit during a C# refactor?
Re-run the tests with Atlas's bash tool after each hunk lands, not once at the end. Running xUnit via dotnet test once after 20 hunks tells you that the C# module broke, which is the least actionable possible signal. Running it after each hunk tells you which hunk broke it.
Per-hunk verification is what turns a legacy C# refactor from a gamble into a sequence of reversible steps. After each apply_patch lands on `LegacyOrderService.cs` or the interface you extracted, run `dotnet test` scoped to the affected xUnit project. Because you recorded a green baseline first, a red run is unambiguous: the last hunk did it. Atlas snapshots file changes as git patches, so you roll that one hunk back and rethink rather than unwinding twenty. Track the remaining callsites in a todowrite list so a partially migrated C# module cannot be mistaken for a finished one: a module where 8 of 11 callers have been updated is broken, and a todo list is what stops it from being declared done. Run `dotnet format` before you commit, and let NuGet resolve any package the restructure introduced.
How does Atlas keep a legacy C# refactor reviewable and revertible?
Atlas keeps a C# refactor reviewable through 3 guarantees: every tool call is permission-gated against allow, ask, and deny rules, every file edit is surfaced as a unified diff for approval before writing, and every change is snapshotted as a git patch so it can be diffed and rolled back.
A legacy C# module refactor touches many files across a `.sln`, which is exactly the shape of change reviewers rubber-stamp because it is too large to read. Atlas keeps it readable by keeping it granular. Each apply_patch hunk is a separate approval with its own unified diff. Each `dotnet test` run through bash is a separate permission check. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the refactor can be committed hunk group by hunk group once xUnit is green, rather than as one 40-file commit nobody will review. Atlas can also draft the whole restructure in a read-only plan agent first and ask before switching to a build agent, so the design of the C# refactor is agreed before any `.cs` file is opened for writing.
Step by step
- 01Run atlas in the solution with a .csproj or .sln so Atlas can see the namespaces, project references, and NuGet packages involved.
- 02Map the legacy module's public surface with the lsp tool's documentSymbol operation, listing the public classes, methods, and interfaces it exposes.
- 03Run the lsp tool's findReferences operation on each exported symbol to enumerate every callsite, including callers in other projects of the same .sln.
- 04Pin behavior first: run xUnit via dotnet test through Atlas's bash tool and record the green baseline before changing anything.
- 05Restructure with apply_patch, which seeks each hunk's context and old_lines and fails with Failed to find context if the .cs file has drifted.
- 06Review the unified diff Atlas surfaces for each C# file before it writes, since every file edit is presented for approval.
- 07Re-run xUnit via dotnet test after each hunk lands, not once at the end, so a red run points at exactly one patch.
- 08Track the remaining callsites in a todowrite list so a partially migrated C# module cannot be mistaken for a finished one.
- 09Run dotnet format over the touched files, let NuGet restore any new package, and let Atlas stage and create the commit once the suite is green.
Frequently asked questions
- how to find all callers of a c# method across a solution
- Run Atlas's lsp tool findReferences operation on the method. Because the language server understands project references in the .sln, it returns callers in other projects that a grep scoped to one .csproj would never find.
- how do I refactor a legacy c# class without breaking callers
- Map the public surface with the lsp tool's documentSymbol, enumerate callers with findReferences, record a green xUnit via dotnet test baseline, then restructure hunk by hunk with apply_patch and re-run the tests after each one.
- what does Failed to find context mean in atlas apply_patch
- apply_patch anchors on each hunk's context and old_lines. Failed to find context means the .cs file drifted since Atlas read it, perhaps because dotnet format ran, so the patch refused to apply rather than guessing at a location.
- should I run dotnet test after every change during a refactor
- Yes. Re-run xUnit via dotnet test after each hunk lands rather than once at the end. With a green baseline recorded beforehand, a red run after one hunk is unambiguous and the offending patch can be rolled back.
- can atlas undo a bad c# refactor step
- Yes. Atlas snapshots file changes as git patches so edits can be diffed and rolled back. Because apply_patch works hunk by hunk, one bad restructuring step can be reverted without unwinding the whole refactor.
- how do I track which c# callsites are still unmigrated
- Keep a todowrite list of the remaining callsites from findReferences. A module where 8 of 11 callers have been updated is broken, and the todo list is what stops it from being mistaken for a finished refactor.
- does atlas edit c# files without asking
- No. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing to any .cs file.
- can atlas plan a c# refactor before making changes
- Yes. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, so the design of the C# restructure is agreed before any .cs file is opened for writing.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Refactor a Legacy Module with Atlas in 2026
How to refactor a legacy module with Atlas in 2026: findReferences maps every callsite, apply_patch refuses to apply against a drifted file, and bash proves behavior.
Atlas for C# in 2026
Atlas is a terminal-native AI coding agent for C# and the .NET SDK in 2026. Run it in a solution with a .csproj or .sln and approve every diff before dotnet build.
Research a third-party API before integrating it in C# with Atlas (2026)
Use Atlas websearch and webfetch to pull a live API doc into context before writing C# integration code in 2026, then verify with dotnet format and dotnet test.
Self-Review Your Working Diff Before Committing in C# with Atlas (2026)
Self-review a C# working diff in 2026 with Atlas: read the full diff and every changed file, grep for leftovers, revert from a snapshot, then run xUnit via dotnet test.
Plan a Multi-File Change Before Editing in C# with Atlas (2026)
Design a C# refactor across many files in 2026 before touching one line. Atlas plan mode denies every edit tool, writes a plan, then hands off with plan_exit.
Review a Pull Request in C# With Atlas (2026)
Review a C# pull request with the context a line-by-line read misses. Atlas pulls the raw diff, reads whole files, and checks callers with the lsp tool's findReferences.
Extract a Shared Helper from Duplicated C# Code with Atlas (2026)
How Atlas collapses duplicated C# logic into one tested helper in 2026: codebase_search finds semantic copies, apply_patch swaps each callsite, xUnit via dotnet test proves it.
Diagnose a Hanging or Long-Running Command in C# with Atlas (2026)
Work out whether a dotnet build is genuinely slow or silently blocked on input, using Atlas in 2026, and get NuGet restore and dotnet test unstuck for good.