# opencode for .NET projects: a practical guide

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

Use opencode in .NET solutions: AGENTS.md setup, safe build-test loops, EF Core and ASP.NET Core tips, and parallel agents with AgentVera.

**In short:**

- Put build, test, and lint commands plus .NET naming rules in AGENTS.md so opencode stays consistent.
- Work in small steps, run dotnet test after each change, and review diffs before merging.
- For parallel work, AgentVera runs opencode instances in separate git worktrees and auto-reviews code.

You start by running `opencode` in the solution folder; the agent reads AGENTS.md from that directory and applies the rules you define. See [opencode](/en/agents/opencode/) for the baseline behavior, then tailor AGENTS.md to .NET. This guide covers a practical .NET workflow, including C#, ASP.NET Core, Entity Framework Core, and xUnit or NUnit.

## Why opencode fits .NET work

opencode runs normal dotnet CLI commands, so it can use the same build, test, and format commands you already run. .NET solutions are explicit: the .sln and .csproj files tell the agent exactly which projects exist, their target frameworks, package references, and dependencies. The compiler is a strong feedback loop; when opencode edits C#, `dotnet build` and `dotnet test` return concrete errors and failing tests that the agent can use to correct itself. This works especially well for ASP.NET Core request pipelines, EF Core LINQ queries, and xUnit/NUnit test projects because the structure is predictable once you document your conventions.

## Setting up AGENTS.md for a .NET project

Create AGENTS.md at the solution root before serious work. Tell opencode how to build, test, and lint, and what .NET conventions matter in this repository. Include the solution layout, exact commands, target framework settings, and rules for EF Core, DI, async, and test naming. A realistic AGENTS.md for a common solution looks like this:

```markdown
# AGENTS.md

## Project layout
- src/ contains one class library per bounded context
- tests/ mirrors src with xUnit test projects
- Solution file: MyApp.sln

## Commands
- Build: dotnet build MyApp.sln --no-restore
- Test: dotnet test MyApp.sln --no-build --logger console;verbosity=normal
- Lint: dotnet format MyApp.sln --verify-no-changes
- Restore: dotnet restore MyApp.sln
- Add migration: dotnet ef migrations add <Name> --project src/MyApp.Infrastructure --startup-project src/MyApp.Api

## .NET conventions
- Use file-scoped namespaces; enable nullable and ImplicitUsings in every csproj
- Use primary constructors where available
- Prefer async/await for I/O; return Task<T> from service methods
- Register services in Program.cs via extension methods, one per project
- EF Core: keep DbContext in Infrastructure, entities in Domain, no lazy loading proxies
- Logging via ILogger<T>, not Console.WriteLine in libraries
- Tests: xUnit, one test class per production class, name tests Method_Scenario_ExpectedResult
- Do not change .sln or .csproj unless asked, except adding a project reference

## Rules for agent
- Always run dotnet build after code changes; do not claim success until tests pass
- Prefer minimal diffs; do not reformat untouched files
```

Keep this file short and specific. If you use Central Package Management, add a note that NuGet versions live in Directory.Packages.props and must not be added directly to csproj files. For ASP.NET Core, mention auth schemes, JSON options, and middleware order if they are non-default.

## A safe working loop with example prompts

Work in small steps. Start by asking opencode to inspect the solution and propose a plan. After each change, have it run `dotnet build` and the relevant `dotnet test`, then review the git diff yourself. Do not let it accumulate multiple unrelated changes. For the general opencode workflow, see [How to use opencode: a step-by-step guide](/en/blog/how-to-use-opencode/).

Useful prompts for .NET tasks:

- `Read MyApp.sln and list the projects with their target frameworks and dependencies; suggest an order to add a new order-history feature to the API.`
- `Add an endpoint GET /api/orders/{id} in OrdersController that returns OrderDto; write the controller action, service interface, and one xUnit test. Do not modify the DbContext.`
- `Create an EF Core migration named AddOrderStatus for the Order entity; run dotnet ef migrations add and show the generated files. Do not update the database.`
- `Fix the failing tests in OrderServiceTests; run dotnet test on the test project only and summarize what changed.`
- `Refactor the payment processing method into an IPaymentGateway interface with two implementations; update DI registration and existing tests; run the full solution build after each step.`

Keep each prompt scoped to one project or one concern. If you must touch multiple projects, say which ones and in what order.

## Tasks opencode does well and where to watch

opencode is strong at repetitive .NET work: adding controllers and minimal API endpoints, mapping DTOs, fixing LINQ queries, registering services, and writing xUnit or NUnit tests. It can also read compiler warnings and nullability errors and fix them. However, some .NET areas need close review.

| Task | Where opencode does well | Watch closely |
|------|--------------------------|---------------|
| Add controller endpoint | routing, action return types, model binding | auth filters, Swagger annotations, route conflicts |
| EF Core query | LINQ translation, Include/ThenInclude, AsNoTracking | client evaluation, N+1 queries, disposed DbContext |
| DI registration | adding services, extension methods | lifetime mismatch, captive dependencies, circular references |
| Unit tests | arrange/act/assert, mocking | wrong test framework attributes, async test deadlocks |

Specific pitfalls: opencode may edit generated files such as EF Core migrations and designer snapshots incorrectly; always review those diffs and run `dotnet ef migrations script` to verify. It may add NuGet packages with incompatible versions; use Central Package Management and pin major versions. It can register a scoped service in a singleton or introduce `.Result` in ASP.NET Core; ask for a build with warnings as errors if your project enables that. For solution-level work, it sometimes runs `dotnet test` at the root when only one project changed; specify the test project in your prompt.

## Testing and verification with the agent

Make opencode verify its own work. After any code change, ask it to run `dotnet build MyApp.sln --no-restore` and `dotnet test MyApp.sln --no-build`. Have it show the command output; if tests fail, it should not claim success. For faster loops, target one test project with `dotnet test tests/MyApp.UnitTests --no-build --filter FullyQualifiedName~OrderService`. If you use NUnit, make sure the agent uses NUnit attributes and not xUnit, or vice versa; a mismatch is common when both frameworks exist. Use `dotnet format MyApp.sln --verify-no-changes` as a lint check after a refactor. For ASP.NET Core integration tests, let the agent run the test project that uses WebApplicationFactory rather than starting the full app manually. Review the final git diff before committing: the agent may leave unused usings, generated migration files, or temporary console logging.

## Running several agents on one .NET project with AgentVera

For .NET solutions where you want several opencode agents in parallel, AgentVera runs real CLI agents side by side in one window, each in its own terminal panel. Its git worktree support matters most: each agent works in its own worktree, so one agent changing a csproj or Program.cs does not overwrite another’s work. Automatic code review is valuable because a second model checks agent output before you merge, and checkpoints let you undo a bad refactor or EF Core migration in one click. Token budgets keep long-running .NET work from burning through your account unnoticed. See [Best tools to run AI coding agents in parallel (2026)](/en/blog/best-tools-parallel-ai-coding-agents/) for broader options.

## Wrap-up

opencode fits .NET work when you give it explicit AGENTS.md rules, keep changes small, and verify with dotnet build and dotnet test after every step. It handles controllers, EF Core, DI, and tests well, but generated files and package versions deserve human review. For parallel work on the same solution, AgentVera adds worktrees, review, and checkpoints that reduce merge pain. Start with a clean AGENTS.md and one scoped prompt; you will quickly find the loop that keeps the solution building.

## Frequently asked questions

**Can opencode work with a .NET solution or does it need a single project?** It works at the folder level, so run it in the solution root with AGENTS.md describing the projects, commands, and conventions. You can target specific projects with dotnet CLI arguments in your prompts.

**How do I stop opencode from breaking my .NET build?** Include exact build, test, and lint commands in AGENTS.md, ask for small diffs, and require dotnet build and test after each step. Review csproj changes, EF Core migrations, and DI registration carefully.

**Does opencode support ASP.NET Core and EF Core migrations?** Yes, it can edit controllers, services, DbContext, and create migrations. Always review generated migration files and connection strings, and run dotnet ef migrations script to verify the generated SQL.

**Can I run multiple opencode agents on the same .NET repo?** Yes, by using separate git worktrees or an orchestration tool like AgentVera; otherwise agents can overwrite each other’s files. Worktrees keep changes isolated until you merge them.

---

**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/