Я пытаюсь разобраться с низким уровнем ядра .NET, чтобы понять, что происходит, я знаю, что CoreCLR предоставляет сборщик мусора, JIT-компилятор, базовые типы .NET и другие низкоуровневые классы,что в конечном итоге означает, что оно является частью любого работающего приложения.Когда я искал его в проекте ASP.NET Core, я обнаружил, что он не установлен, более того, он доступен для загрузки в виде пакета NuGet.Затем я обнаружил эту интересную часть в файле README репозитория CoreCLR :
Но основная причина, по которой вы не можете многое сделать с CoreCLR, заключается в том, что ВСЕ типы вбиблиотека классов LOOK, как они определены каркасом CoreFX, а не CoreCLR.Любой определенный здесь библиотечный код находится в одной DLL, называемой System.Private.CoreLib.dll, и, как следует из названия, является закрытой (скрытой).Вместо этого для любого конкретного типа PUBLIC, определенного в CoreCLR, мы нашли «правильный» пакет в CoreFX, где он, естественно, принадлежит, и используем этот пакет в качестве общедоступной точки публикации.Затем этот «фасадный» пакет пересылает ссылки на (приватную) реализацию в System.Private.CoreLib.dll, определенной здесь.Например, пакет System.Runtime, определенный в CoreFX, объявляет имя PUBLIC для таких типов, как System.Object и System.String.Таким образом, с точки зрения приложений эти типы живут в System.Runtime.dll.Тем не менее, System.Runtime.dll (определенный в репозитории CoreFX) перенаправляет ссылки в конечном итоге на System.Private.CoreLib.dll, который определен здесь
Что я понимаю из этого (не уверен), чтокаждый тип в CoreCLR (например, String) определяется дважды, один в CoreCLR (фактическое определение), а другой в CoreFX, который является фасад определением, которое в конечном итоге указывает на упакованный CoreCLR (System.Private.CoreLib.dll), а также то, что пакет Microsoft.NETCore.Runtime.CoreCLR, отображаемый в NuGet, бесполезен, поскольку я могу получить к нему доступ только через CoreFX.
Надеюсь, кто-то тожеподтвердите или поправьте меня.