# Using Gemini CLI on a .NET project: practical workflow

URL: https://agentvera.dev/en/blog/gemini-cli-for-dotnet/ · Published: 2026-11-01

Practical Gemini CLI .NET guide: project setup with GEMINI.md, test-driven workflows, EF Core review points, and running parallel agents.

**In short:**

- Start gemini at the .sln root and let GEMINI.md pin your exact dotnet build, test, and format commands.
- Use a plan–small edit–test–diff loop and review EF Core, DI lifetime, and middleware changes closely.
- Run several agents in separate worktrees with AgentVera to avoid file conflicts and catch .NET-specific mistakes.

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](/en/agents/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:

```markdown
# 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](/en/blog/how-to-use-gemini-cli/).

Example prompts for typical .NET tasks:

- Add an endpoint `GET /api/orders/{id}` to `OrdersController`; include order lines and customer name; use EF Core with `AsNoTracking`; 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 `OrderStatus` column; do not run `database update`, just show the generated migration and model snapshot diff.
- Refactor the registration logic in `Program.cs` into an extension method `AddOrderProcessing`; keep existing behavior and run the full test suite.
- Review `Program.cs` for 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](/en/blog/ai-coding-agent-orchestration/).

## 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.

## Frequently asked questions

**How do I start Gemini CLI on a .NET project?** Run gemini in the folder that contains your .sln file. Put a GEMINI.md there first so the agent knows your build, test, and formatting commands and the project layout.

**What should I put in GEMINI.md for a .NET solution?** Keep it command-first: exact dotnet build, dotnet test, and dotnet format lines, the project-to-folder map, target framework, and rules like never edit generated EF Core migrations by hand.

**Can Gemini CLI run dotnet test and dotnet ef commands?** Yes, it can execute terminal commands and read their output. Ask it to run dotnet test and show full failures, or use dotnet ef migrations script to review migration SQL before applying it.

**What are the biggest pitfalls when using Gemini CLI with EF Core?** It may change models and migrations in ways that look valid but cause data loss or schema drift. Always review the Up and Down methods, the model snapshot, and the generated SQL before accepting the diff.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/