Dotnet Core - CoreCLR Vs NativeAOT Runtimes

When you compile with NativeAOT (PublishAot=true), your application does not use CoreCLR at all at runtime.

Instead, it uses a minimal, statically linked runtime that’s fundamentally different from CoreCLR, that is a lightweight static runtime called the NativeAOT Runtime (derived from the old CoreRT project)

---

🔍 How it works conceptually

When you publish a .NET app normally:

Standard .NET (JIT/CoreCLR path):

Your C# code
   ↓ (compiled by Roslyn)
Intermediate Language (IL)
   ↓ (executed by CoreCLR at runtime)
CoreCLR JIT compiles IL → Native code (on the fly)

When you publish using NativeAOT, the process changes drastically:

NativeAOT (AOT path):

Your C# code
   ↓ (compiled by Roslyn)
Intermediate Language (IL)
   ↓ (compiled AOT by crossgen2)
Native Machine Code (.exe)
   ↓
Executed directly by OS — No CoreCLR, no JIT

---

⚙️ What replaces CoreCLR in NativeAOT?

Instead of the CoreCLR runtime, NativeAOT uses a lightweight static runtime called the NativeAOT Runtime (derived from the old CoreRT project).

This runtime:

• Includes a minimal GC, type system, and exception handling system.
• Does not include JIT compilation logic.
• Does not support full reflection or dynamic assembly loading.

It’s statically linked into the final executable, so the entire runtime becomes part of your .exe file.

---

🧠 Deeper Comparison: CoreCLR vs NativeAOT Runtime

Feature	CoreCLR	NativeAOT Runtime
JIT Compiler	✅ Present (RyuJIT)	❌ Not included
GC (Garbage Collector)	✅ Full-featured, generational	✅ Simplified GC (same core concepts, smaller)
Type Loader	✅ Dynamic	✅ Static (known at build time)
Reflection	✅ Full	⚠️ Limited (metadata stripped)
Dynamic Assembly Load	✅ Supported	❌ Not supported
Code Generation at Runtime (Emit)	✅ Supported	❌ Not supported
Startup Time	⚡ Moderate	⚡⚡ Super fast
Binary Size	🧱 Larger	💡 Smaller
Runtime Required	.NET runtime (CoreCLR)	None — self-contained
Use Cases	General-purpose apps	Cloud, microservices, serverless, CLI tools

---

🧮 Example Build Flow

🔸 CoreCLR-based publish:

dotnet publish -r linux-x64 -c Release

Produces:

• app.dll

• dotnet host loads CoreCLR runtime

• JIT compiles IL on startup

🔸 NativeAOT publish:

dotnet publish -r linux-x64 -c Release /p:PublishAot=true

Produces:

• A single app executable

• Contains native code + stripped-down runtime

• Runs directly via ./app (no dotnet needed)

---

🧩 Why this matters

✅ Advantages:

• Blazing-fast cold starts (critical for AWS Lambda, Azure Functions, CLI tools)
• No runtime dependency (great for container deployment)
• Reduced attack surface (no JIT, less metadata)

⚠️ Trade-offs:

• No runtime code generation (System.Reflection.Emit)
• Limited dynamic loading
• Reflection-heavy frameworks (like some ORMs or JSON serializers) need trimming-safe versions

---

💡 Internal Implementation Hint

In .NET 7/8, the AOT toolchain (crossgen2) builds an object file (.obj) that includes:

• Compiled IL → native code

• Static GC and metadata tables

• Lightweight runtime startup code (from NativeAOT runtime)

Then it uses the system’s C++ linker to produce a final executable:

App.obj + NativeAOT runtime libs → FinalApp.exe

So the “runtime” is baked in, not “loaded dynamically” like CoreCLR.

---

🔧 Analogy

Mode	Analogy
CoreCLR (JIT)	Like a chef who cooks each dish when ordered — flexible, but slower startup.
R2R (Partial AOT)	Chef preps ingredients ahead of time — faster serving.
NativeAOT (Full AOT)	Meals fully cooked, sealed, and ready to serve — instant serving, no kitchen needed.

---

🧾 Summary

Aspect	CoreCLR (.NET Runtime)	NativeAOT
Uses JIT?	✅ Yes	❌ No
Runtime Engine	CoreCLR	NativeAOT runtime (based on CoreRT)
Startup Speed	⚡ Moderate	⚡⚡ Instant
Reflection Support	✅ Full	⚠️ Limited
Runtime Size	🧱 Larger	💡 Small and static
Output	IL + runtime	Native binary
Target Scenarios	General apps, APIs	Cloud-native, microservices, serverless, tools