CLR Internals

25.1 Assemblies

An assembly = a deployment unit (.dll/.exe) with a manifest (identity: name, version, culture, public key token), metadata, IL, and resources.

Strong naming (signing) is mostly irrelevant on modern .NET. It was required for the GAC on .NET Framework.

Inspect assemblies with ILSpy, dnSpy, or ildasm. VB compiles to IL just like C#, and decompiling a VB DLL as C# is a good way to learn.

Dependency resolution: *.deps.json, NuGet package graph, AssemblyLoadContext, binding redirects (.NET Framework app.config).

25.2 IL, JIT and Compilation Modes

IL → native code at first call. Tiered compilation (quick tier 0, optimized tier 1). Dynamic PGO.

Precompiled native code inside the assembly for faster startup (PublishReadyToRun)

Full ahead-of-time compilation, no JIT. Limited for VB: reflection-heavy and late-bound code isn't compatible. Test carefully.

See IL for VB code: Dim x = 5 + y → ldc.i4.5, ldloc, add.ovf (VB checks overflow by default, so it emits add.ovf).

25.3 The Microsoft.VisualBasic Runtime

VB programs reference Microsoft.VisualBasic.dll (the VB runtime): Strings, Conversion, Interaction, FileSystem, late binding (NewLateBinding), My helpers, Information.IsNumeric, etc.

Implications: some VB conversions (CInt on strings, = on strings with Option Compare Text) call runtime helpers, so they're slightly different from C# semantics.

25.4 Type System Mechanics

Method tables, object headers, vtables (Overridable → virtual calls), interface dispatch, boxing, static (Shared) constructors and type initialization order, generic instantiation (shared code for reference types, specialized code for value types).