c# - Does CLR still loads the assembly in the process even when it has Ngen'd copy of that assembly -
i reading article jeffrey richter' book clr via c#. , found nice paragraph ngen.exe
tool.
many people believe might possible ship ngen’d files without shipping files containing original il code, thereby keeping intellectual property secret. unfortunately, not possible. @ run time, clr requires access assembly’s metadata (for functions such reflection , serialization); requires assemblies contain il , metadata shipped.
i wanted clear few thing.
- does clr loads assembly when referencing types there in assembly.
- does verification check on it?
- when comes compiling code (jit compiler), ngen'd code , load compiled native cpu instructions file, or doesn't load assembly @ when ngen'd file there?
does clr loads assembly when referencing types there in assembly.
no. clr load assembly once method jitted, , depended assembly in order execute. jit instruct runtime load dll.
does verification check on it?
yes, binder, responsible loading dll verify valid assembly via it's metadata in clr header (see section below).
when comes compiling code (jit compiler), ngen'd code , load compiled native cpu instructions file, or doesn't load assembly @ when ngen'd file there?
not sure mean "ngened file there", native binder native dll part of loading process. this article explains details of loading assembly details:
first standard fusion binder kick in find assembly. can find either in:
gac, means named. way files placed in gac ensures binder can extract required information assembly without physically opening file
find appbase (e.g. local folder of program.exe). proceed open il file , read assemblies metadata.
- native binding proceed in default context (more in later post)
- the nativebinder finds ni file nic. reads in ni file details , metadata
- verifies ni indeed same il assembly. goes through rigorous matching process includes (but not limited to) full assembly name match (same name, version, public key tokens, culture), time stamp matching (ni has newer il), mvid (see below)
- also verifies ni has been generated same clr under going run (exact .net version, processor type, etc…) .
- also ensures ni’s dependencies valid. e.g. when ni generated bound against particular version of mscorlib. if mscorlib native image not valid ni image rejected
default context:
default context: context assembly loaded through implicit assembly references or assembly.load(…) call lands
Comments
Post a Comment