此存储库包含 .NET Core运行时的完整源代码。
.NET Core最好被认为是“敏捷.NET”。一般来说它是一样的
Desktop .NET Framework
作为Windows操作系统的一部分分发，但它是一个跨平台
（Windows，Linux，macOS）和可以部署的跨体系结构（x86，x64，ARM）子集
作为应用程序的一部分（如果需要），因此可以快速更新以修复错误或添加功能。
具体而言，此存储库最好被认为是以下NuGet包的源代码：
- ** Microsoft.NETCore.Runtime.CoreCLR ** - 表示对象分配器，垃圾收集器（GC），类
加载器，类型系统，互操作和.NET类库的最基本部分（例如
System.Object，System.String …）
它还包含以下密切相关的支持包的源代码。
-
Microsoft.NETCore.Jit - Just In Time（JIT）编译器 .NET中间语言(IL)
-
Microsoft.NETCore.ILAsm - 用于的汇编程序 .NET中间语言(IL)
-
Microsoft.NETCore.ILDAsm
-
Microsoft.NETCore.TestHost - 这包含corehost.exe程序，这是一个小包装器 使用.NET运行时运行在命令行上传递给它的IL DLL。
-
Microsoft.TargetingPack.Private.CoreCLR - 一组表示编译时表面的程序集 由运行时本身实现的类库的区域。
与CoreFX存储库的关系
就其本身而言，Microsoft.NETCore.Runtime.CoreCLR包实际上还不够。
其中一个原因是CoreCLR包试图最小化它实现的类库的数量。
仅包括对运行时的内部工作具有强依赖性的类型（例如，
System.Object，System.String，System.Threading.Thread，System.Threading.Tasks.Task和大多数基础接口）。
相反，大多数类库都是作为独立的NuGet包实现的，它只使用.NET Core
运行时作为依赖项。 许多最熟悉的类（System.Collections，System.IO，System.Xml等），存在dotnet/corefx 存储库中定义的包中。
但是你对CoreCLR做不了多少的主要原因是 类库LOOK中的类型ALL **
就像它们是由CoreFX框架而不是CoreCLR定义的。这里定义的任何库代码
它位于一个名为System.Private.CoreLib.dll的DLL中，顾名思义就是私有（隐藏）。
相反，对于CoreCLR中定义的任何特定PUBLIC类型，我们在CoreFX中自然地找到了“正确”的包
属于并使用该包作为public publishing**点。那个’facade’ 包然后转发引用
到这里定义的System.Private.CoreLib.dll中的（私有）实现。
例如，CoreFX中定义的*System.Runtime *包声明类似的类型的PUBLIC名称
System.Object和System.String。因此，从应用程序的角度来看，这些类型存在于System.Runtime.dll中。
但是，System.Runtime.dll（在CoreFX repo中定义）最终将引用转发给System.Private.CoreLib.dll
这是在这里定义的。
因此，为了运行应用程序，您需要同时使用Microsoft.NETCore.Runtime.CoreCLR NuGet包
（在此存储库中定义）以及您实际引用的任何已定义的包
在CoreFX存储库中（至少包括System.Runtime包）。你还需要一些
加载CoreCLR包以及CoreFX包并启动代码的“host”可执行文件（通常是
你使用dotnet.exe这个）。
