If you are having difficulty with the concept of .Net being compiled or a 'Virtual Machine' think of it like this:-
1) .Net languages compile to an intermediate language (CIL), this intermediate language is then compiled to machine code each time you run the application by a run-time compiler (or just-in-time compiler in marketing speak). This is similar to how an interpreter works, but is faster (though you get a start-up delay while it is compiling).
This is very like VB6 if you take the option of compiling to P-Code.The 'VM' in MSVBVM60.dll stands for 'Virtual Machine'. It is this that translates VB P-Code to machine code.
2) .Net also has options to fully compile (or 'pre-compile') using .Net Native or Ngen to machine code. This mainly just removes the start-up delay (see above). You still need the common language runtime to be present even if you have compiled with .Net Native.
This is very like VB6 if (as is normal) you take the option of compiling to Native Code, which compiles to machine code (and speeds up loops and math) while still needing MSVBVM60.dll for some services (such as startup and shutdown code and functionality for intrinsic controls).
3) A 'Virtual Machine' is simply a fancy name for whatever goes between your intermediate code (IL code or P-Code) and machine-understandable code at runtime. Whether that is a compiler, interpreter, or combination of the two.
It's just a matter of semantics whether you regard a just-in-time compiler as a virtual machine or not.
Microsoft support VB6 programming on Windows 10 until at least 2025