AI Code Review for .NET Applications

The hidden cost of .NET platform complexity

The .NET ecosystem has evolved rapidly over the past decade. A production application that started on .NET Framework 4.6 may have migrated through .NET Core 3.1 to .NET 8, carrying forward patterns and dependencies from each era. Each migration introduced new idioms – minimal APIs replaced controller-based routing, top-level statements replaced Startup.cs, and the built-in DI container replaced third-party containers like Autofac or Ninject – but rarely was every file updated to match the new conventions.

The result is a codebase where modern and legacy patterns coexist uneasily. Some controllers use attribute routing while others rely on conventional routing. Configuration is split between appsettings.json, environment variables, legacy web.config transforms, and hardcoded values in static classes. Middleware is registered in an order that made sense three years ago but no longer matches the application's authentication and authorisation requirements.

This complexity is invisible in day-to-day development. Each file compiles, each endpoint responds, each test passes. But the accumulated inconsistency creates fragility: a change to middleware ordering breaks authentication for a subset of routes, a DI registration change causes a runtime exception in a rarely-used service, or an Entity Framework query that worked with ten records starts timing out with ten thousand.

What VibeRails finds in .NET applications

VibeRails performs a full-codebase scan using frontier large language models. Every .cs, .csproj, .sln, configuration, and migration file is analysed – not just recent commits, but the entire solution. For .NET applications specifically, the AI reasons about platform-level patterns that span multiple files and assemblies:

• Async/await deadlocks – calls to .Result or .Wait() on tasks within ASP.NET request contexts, synchronous-over-async patterns in middleware, missing ConfigureAwait(false) in library code, and fire-and-forget Task.Run calls that silently discard exceptions
• IDisposable misuse and memory leaks – classes that implement IDisposable but are never disposed, HttpClient instances created per request instead of using IHttpClientFactory, database connections not wrapped in using blocks, and event handler subscriptions that prevent garbage collection
• Dependency injection anti-patterns – singleton services capturing scoped dependencies, service locator patterns hiding true dependencies, ambiguous registrations where the last-registered implementation wins silently, and captive dependency chains where a transient holds a reference to a scoped service
• Entity Framework N+1 queries – LINQ queries that trigger lazy loading inside loops, missing Include and ThenInclude calls, queries that materialise too early with ToList() before filtering, and read-only paths missing AsNoTracking()
• LINQ performance traps – client-side evaluation of queries that should execute on the database, Contains calls that generate massive IN clauses, repeated enumeration of IQueryable causing duplicate database hits, and projection patterns that fetch entire entities when only two columns are needed
• Middleware pipeline ordering – authentication middleware registered after routing, exception handling middleware that does not catch errors from earlier stages, CORS middleware in the wrong position, and response compression applied to already-compressed content types
• Blazor component lifecycle issues – components that perform heavy work in OnInitializedAsync without cancellation token support, StateHasChanged called from non-UI threads, component parameters that trigger unnecessary re-renders, and memory leaks from undisposed component event subscriptions
• Configuration sprawl – settings scattered across appsettings.json, appsettings.Development.json, appsettings.Production.json, environment variables, user secrets, and hardcoded constants. Missing validation of required configuration values that cause runtime failures instead of startup failures.

Each finding includes the file path, line range, severity level, category, and a description with suggested remediation. The structured output turns a complex .NET solution into an organised inventory of improvements.

Why Roslyn analysers and ReSharper are not enough

Roslyn analysers, ReSharper, and SonarQube for .NET are effective at local code quality: naming conventions, unused variables, redundant casts, and simple null reference warnings. But they operate on individual files or compilation units with limited cross-project awareness.

Consider an IDisposable service that is registered as a singleton in Program.cs but holds a reference to a scoped DbContext. The Roslyn analyser sees valid code in each file. The lifetime mismatch only becomes visible when you trace the DI registration, the constructor injection chain, and the disposal semantics across multiple projects in the solution. That trace requires reading and correlating information from files that no single-file analyser can connect.

Entity Framework performance issues are similarly invisible to file-level analysis. A repository method returns an IQueryable that looks efficient in isolation. Three layers up, a controller action iterates the results and accesses a navigation property on each item, triggering hundreds of individual database queries. Finding this pattern requires understanding the full call chain from controller to repository to database – the kind of cross-file reasoning that AI code review excels at.

Middleware pipeline ordering issues cannot be detected by any static analyser because the correct order depends on the application's specific authentication scheme, CORS requirements, and error handling strategy. VibeRails evaluates the entire pipeline registration and flags ordering that contradicts ASP.NET Core best practices or the application's own configuration.

Common .NET review scenarios

Migrating from .NET Framework to .NET 8. The migration tool handles project file conversion and basic API replacements, but it cannot identify patterns that compiled on Framework but behave differently on modern .NET. VibeRails scans the migrated solution and flags synchronisation context changes that introduce deadlocks, System.Web dependencies that need replacement, and configuration patterns that no longer apply.

Scaling an ASP.NET Core API. An API that works at low traffic can fail under load due to connection pool exhaustion from undisposed DbContext instances, thread pool starvation from synchronous blocking calls, or memory pressure from large object heap allocations in response serialisation. VibeRails identifies these patterns before they cause production incidents.

Onboarding a new team onto an existing solution. A .NET solution with 50+ projects, custom middleware, multiple DbContexts, and years of accumulated conventions is overwhelming for new developers. A VibeRails scan produces a structured map of issues and inconsistencies that serves as both an onboarding guide and a remediation backlog.

Auditing Blazor applications. Blazor Server and Blazor WebAssembly have distinct performance characteristics and lifecycle constraints. VibeRails understands component rendering behaviour, circuit lifetime management, and the differences between server-side and client-side execution models, flagging patterns that work in development but fail at scale.

BYOK model, per-developer pricing

VibeRails runs as a desktop app with a BYOK model. It orchestrates Claude Code or Codex CLI installations you already have. Your .NET source code is read from disk locally or sent directly to the AI provider you configured – never to VibeRails servers. For enterprise teams with proprietary business logic or regulated data handling requirements, this means your code is not uploaded to a VibeRails cloud service.

Export findings as HTML for architecture review meetings or CSV for import into Azure DevOps, Jira, or whatever project management tool your team uses. The structured format means findings can be turned into work items with clear descriptions, file references, and severity ratings – ready for sprint planning.

Start with the free tier today. Run a scan on your .NET solution and see what VibeRails finds. If the findings are valuable, upgrade to the lifetime licence for $299 – less than a single day of contractor time.