Theory
What the till actually executes
ShopKeeper is finished (imagine, for today). You press Build, copy ShopKeeper.exe to the till at Mehta Stores, and it runs.
Small puzzle: the till's CPU executes raw machine instructions. Your .exe was built on YOUR laptop, without knowing anything about that CPU. So what exactly is inside the file, and who translates it at the till?
The answer is a 2-stage pipeline you already trust from Java, wearing Microsoft names, plus one word that ties it together: managed.
Theory
Stage 1: compile to MSIL + metadata
The VB.NET compiler does NOT produce machine code. It produces:
- MSIL (Microsoft Intermediate Language): CPU-neutral instructions, .NET's equivalent of Java bytecode
- metadata: a full self-description packed alongside: every class, method, property and reference in the code
Both travel together in an assembly: the .exe or .dll file. The metadata is why Visual Studio can autocomplete your classes and why a C# project can call your VB.NET code: the assembly explains itself to anyone who asks.
Theory
Stage 2: JIT, then the GC takes the watch
At the till, the CLR loads the assembly. As each method is first called, the JIT (just-in-time) compiler translates its MSIL into native code for THAT machine's CPU, and caches the result so later calls run at full native speed.
And while ShopKeeper runs, the CLR's garbage collector watches memory: any object no reference points to anymore is reclaimed automatically. No delete, no free, no memory leaks from a forgotten cleanup: the runtime carries that responsibility.
Formula
Managed code, the exam definition
Managed code is code that executes under the CLR's supervision: compiled to MSIL with metadata, JIT-compiled at run time, memory handled by the garbage collector, types verified before execution.
Code that runs directly on the OS without this supervision (classic C/C++ from BCA104/BCA304) is unmanaged code: faster to the metal, but every crash, leak and stray pointer is entirely yours.
Quiz
When is MSIL converted into native machine code?
- At build time, when you press Build in Visual Studio
- At run time, method by method, when each is first called
- Never: the CLR executes MSIL instructions directly, like a script
- When the assembly is copied to the target machine
Show the answer
At run time, method by method, when each is first called
That is precisely what just-in-time means: translation happens at the last moment, per method, on the machine that will run it, and the native result is cached for the rest of the run. Option A describes what a C compiler does, and would chain the .exe to one CPU. Option C undersells the CLR: it compiles MSIL rather than interpreting it line by line. Option D invents a translation step that copying simply does not perform.
Think first
Why not compile straight to machine code?
Two stages look like extra work. Before tapping, find 2 concrete wins of shipping MSIL instead of native code. (Hint: think about the till's CPU, and about the C# team next door.)
Show the answer
Portability across machines: the same assembly JIT-compiles correctly on any CPU with a CLR; native output would need one build per processor family. Language interoperability: every .NET language lands in the same MSIL + metadata, so your VB.NET classes are usable from C# unchanged: one shared landing ground. Add JIT's trick of optimising for the exact CPU it finds at run time, and the 2-stage detour starts looking like the direct route.
Watch out
Terms students blur together
MSIL is not metadata: MSIL is the instructions; metadata is the description OF the code (its types and members). They ship together in the assembly but answer different exam questions.
JIT is not the VB compiler: vbc runs once on your laptop (source to MSIL); JIT runs on every execution machine (MSIL to native).
The GC frees memory, not files or database connections: those still need explicit closing, as Unit 5 will insist.
Theory
One diagram to rule the unit
Draw it once and label it in both vocabularies:
source (.vb / .java) → compiler (vbc / javac) → intermediate (MSIL / bytecode) + metadata → engine (CLR / JVM) → JIT → native code, with GC underneath.
That single picture answers the managed-code question, the MSIL question, the JIT question AND the compare-with-Java question, which between them appear in nearly every BCA404 paper. Next lesson zooms into the engine itself: what else the CLR does besides JIT and GC.
Summary
Key takeaways
- VB.NET compiles to MSIL (CPU-neutral instructions) packaged with metadata in an assembly (.exe/.dll).
- Metadata is the assembly's self-description: types, members, references; it powers IntelliSense and cross-language use.
- The JIT compiler translates MSIL to native code at run time, per method on first call, cached for the run.
- The garbage collector automatically reclaims objects with no references: automatic memory management.
- Managed code = code running under CLR supervision; classic C/C++ is unmanaged.
- Same architecture as Java: vbc/javac, MSIL/bytecode, CLR/JVM, JIT and GC in both.
- Memory hook: compile once to the middle, finish the translation at the till.