我正在阅读杰弗里里希特的书CLR中的一篇文章,通过C#.我发现了一个关于NGen.exe工具的好段落.

Many people believe that it might be possible to ship NGen’d files
without shipping the files containing the original IL code, thereby
keeping their intellectual property a secret. Unfortunately, this is
not possible. At run time, the CLR requires access to the assembly’s
metadata (for functions such as reflection and serialization); this
requires that the assemblies that contain IL and metadata be shipped.

我只想澄清一些事情.

>当程序集中存在引用类型时,CLR是否始终加载程序集.
>它是否进行验证检查？
>在编译代码(JIT编译器)时,它是否会查找NGen代码并从该文件加载已编译的本机CPU指令,或者当NGen文件已存在时根本不加载程序集？

最佳答案

Does CLR always loads the assembly when the referencing types are
there in the assembly.

不会.一旦方法被JITTED,CLR将加载程序集,并且依赖于程序集以执行. JIT将指示运行时加载该DLL.

Does it do verification check on it?

是的,负责加载dll的binder将通过它在CLR头中的元数据将其验证为有效的程序集(参见下面的部分).

When it comes to compiling the code (JIT compiler), does it look for
NGen’d code and load the compiled native CPU instructions from that
file, or doesn’t load the assembly at all when NGen’d file is already
there?

不确定“NGENED文件已存在”是什么意思,但本机绑定器将在加载过程中查找本机dll. This article解释了将装配加载到详细信息的详细信息：

1. First the standard fusion binder will kick in to find that assembly.
   It can find it either in:

   • GAC, which means it is strongly named. The way files are placed in GAC ensures that the binder can extract all the required
     information about the assembly without physically opening the file

   • Find it the APPBASE (E.g. the local folder of program.exe). It will proceed to open the IL file and read the assemblies metadata.

2. Native binding will proceed only in the default context (more about
   this in a later post)
3. The NativeBinder finds the NI file from the NIC. It reads in the NI
   file details and metadata
4. Verifies the NI is indeed for that very same IL assembly. For that
   it goes through a rigorous matching process which includes (but not
   limited to) full assembly name match (same name, version, public
   key tokens, culture), time stamp matching (NI has to be newer than
   IL), MVID (see below)
5. Also verifies that the NI has been generated for the same CLR under
   which it is going to be run (exact .NET version, processor type,
   etc…) .
6. Also ensures that the NI’s dependencies are also valid. E.g. when
   the NI was generated it bound against a particular version of
   mscorlib. If that mscorlib native image is not valid then this NI
   image is also rejected

默认上下文：

Default context: This is the context where assembly loaded through implicit assembly references or Assembly.Load(…) call lands