CLR dependent assembly resolution at startup

Does CLR try to resolve [not necessarily load] all the dependent a开发者_开发百科ssemblies when the program starts up? That is, is the dependent assembly resolution done on demand? Please note that I am not talking about Assembly.Load* [reflective] kind of load.

It is the JIT compiler that directs the loading of assemblies, in response to translating IL to machine code. Type method calls are at first translated to call a stub function. When called, this stub activates the JIT compiler to load the IL (which loads the assembly if necessary) and translate it. Very much on-demand.

One wrinkle in this process are assemblies that were run through Ngen.exe, all the .NET framework assemblies were when they were installed on the machine. This is detected when an assembly is first loaded. The JIT compiler then skips the translation step and uses the pre-translated machine code as-is. While this will load all of the machine code produced by an assembly, it is still on-demand. The term "load" is relative here, Windows uses a memory mapped file to map the native image into the virtual memory space. No actual bytes are read from the file until code execution arrives at a memory page that hasn't been mapped into RAM yet. The technical term for this is "page fault", it is visible in Taskmgr.exe.

A dependant assembly is resolved when a type is needed that is defined in that assembly. So the assembly is loaded on demand.

From here

The CLR loader loads and initializes as little as it can get away with. Unlike the Win32 loader, the CLR loader does not resolve and automatically load the subordinate modules (or assemblies). Rather, the subordinate pieces are loaded on demand only if they are actually needed (as with Visual C++ 6.0's delay-load feature). This not only speeds up program initialization time but also reduces the amount of resources consumed by a running program.