Gemini CLI works well on .NET projects because it operates as a terminal coding agent: you run gemini in the project folder, keep the solution buildable, and let it edit files, run dotnet commands, and read compiler output. This guide covers setup with GEMINI.md, a practical .NET loop, review points, and testing with Gemini CLI.
Why Gemini CLI is a good fit for .NET codebases
The .NET toolchain is command-driven, which matches an agent that works through a terminal. Builds, tests, package management, formatting, and EF Core migrations all have deterministic commands: dotnet build, dotnet test, dotnet add package, dotnet format, and dotnet ef migrations add. When the agent runs those and reads the exact compiler or test output, the loop is predictable.
This also fits .NET project structure. A solution file and the src/tests folders give the agent clear boundaries, and the XML in .csproj files is easy to edit if you tell the agent the target framework and package policy. For example, the agent can add a controller, register a scoped service, create a migration, update the test project, and then verify the whole solution with one command.
Give the agent a .NET command center with GEMINI.md
Put a short GEMINI.md at the solution root, next to the .sln file. Keep it command-first and project-specific; long prose is less useful than exact commands and rules. A realistic .NET example:
# Project commands
build: dotnet build MyApp.sln
test: dotnet test MyApp.sln --no-restore
format: dotnet format MyApp.sln --verify-no-changes
run: dotnet run --project src/MyApp.Api
# Layout
src/MyApp.Api ASP.NET Core Web API
src/MyApp.Core domain services and interfaces
tests/MyApp.Core.UnitTests xUnit tests
# .NET rules
- Target net8.0; do not change TargetFramework without asking.
- Keep nullable enabled; do not add #nullable disable.
- Use EF Core migrations; never edit generated migration code by hand.
- Prefer AddScoped in Program.cs for application services; no service locators.
- Keep constructors short and use primary constructors only in simple DTOs.This file does three jobs: it gives the agent the verified commands, maps folders to projects, and sets hard boundaries around common .NET failure points such as framework changes, nullable suppression, and hand-edited migrations. If you use multiple solutions or a global.json, add those file locations too.
The daily loop for .NET work: plan, edit, test, review
Use a plan, small steps, run the tests, review the diff loop. Start with a small, testable change instead of a broad refactor. After each agent turn, run dotnet test yourself or require the agent to show the full output, then inspect git diff file by file. For a broader walkthrough of that loop, see How to use Gemini CLI: a step-by-step guide.
Example prompts for typical .NET tasks:
- Add an endpoint
GET /api/orders/{id}toOrdersController; include order lines and customer name; use EF Core withAsNoTracking; return 404 if missing. - Create an xUnit test project and write tests for
PriceCalculator; cover zero discount, negative quantity throws, and rounding to two decimals. - Add a new EF Core migration for an
OrderStatuscolumn; do not rundatabase update, just show the generated migration and model snapshot diff. - Refactor the registration logic in
Program.csinto an extension methodAddOrderProcessing; keep existing behavior and run the full test suite. - Review
Program.csfor middleware order problems and suggest the minimal diff to fix authentication before authorization.
Each prompt is small enough to review in one diff and includes the verification step the agent must run.
What Gemini CLI does well in .NET and the diffs to distrust
The agent handles well-defined, compiler-checked tasks: adding endpoints, mapping entities with EF Core, creating migrations, writing xUnit tests, and refactoring DI registration. The risk is not the code compiling; it is runtime behavior and data safety.
| Area | What to check in the diff | Why it matters |
|---|---|---|
| EF Core queries | Include/ThenInclude, AsNoTracking for reads, no client evaluation | Missed includes lead to N+1 queries or lazy-loading surprises |
| DI lifetimes | Scoped service injected into singleton; DbContext captured in background service | Produces captive dependencies and runtime errors |
| Middleware order | UseAuthentication before UseAuthorization, exception handler before static files | Auth failures can be silent and static files may bypass middleware |
| Migrations | Up and Down methods, model snapshot, generated SQL | A bad Down or schema drift can cause data loss |
| Async | .Result or .Wait(), async void, missing CancellationToken | Deadlocks, thread-pool starvation, and untracked exceptions |
Watch especially for .sln vs .csproj confusion. If the agent edits the wrong project, give the exact project path in the prompt. With NuGet, ask it to keep existing package versions unless you approve an upgrade; preview packages and mismatched test SDK versions are common. For EF Core, do not let the agent apply dotnet ef database update without showing the migration SQL first.
Verify .NET changes with tests, format, and EF migrations
Require the agent to run dotnet test and show the full output, not just a summary. Green tests are the minimum; also run dotnet build to catch warnings, and dotnet format --verify-no-changes to keep formatting stable. For EF Core changes, generate and review the SQL with dotnet ef migrations script.
Run tests from the solution root or the test project directory, because configuration files such as appsettings.Development.json are resolved relative to the project. If an xUnit test fails only in parallel, ask the agent to isolate the fixture before re-running the suite.
A useful verification prompt is: “Run dotnet test tests/MyApp.Core.UnitTests/MyApp.Core.UnitTests.csproj and show full failure output; if all pass, run dotnet format --verify-no-changes and show any formatting violations.”
Running multiple .NET agents in worktrees with AgentVera
For larger .NET solutions, the most useful AgentVera features are parallel agents in isolated git worktrees, automatic code review after each turn, checkpoints, and token budgets. Parallel worktrees let one agent refactor the API project while another works on EF Core migrations without file conflicts. The review pass catches DI lifetime mistakes and EF query issues with findings linked to file:line. Checkpoints let you undo a bad migration or middleware change in one click, and token budgets stop an agent from making endless edits. This fits the .NET need for quick iteration plus strict review; see AI agent orchestration for coding: 5 patterns and tools.
Keep Gemini CLI predictable on .NET
Gemini CLI becomes a reliable .NET teammate when the repository gives it exact commands and boundaries. Keep GEMINI.md lean, make every change prove itself with dotnet test, review EF Core and DI diffs carefully, and use worktrees if you run several agents. That turns a general coding agent into a predictable .NET tool.