Net core runtime что это
Share functionality among different apps and app types by using class libraries.
1. FDD vs SCD
- Portable (Framework-dependent deployment — FDD)
- Standalone (Self-contained deployment — SCD)
В Standalone (SCD)-приложении все компоненты для выполнения (CoreCLR, CoreFX), а также сторонние библиотеки, то есть абсолютно все зависимости, поставляются вместе с самим приложением (чаще всего в одной папке).
Важно понимать, что Standalone-приложение привязано к определенной ОС и архитектуре (например, Windows 7 x64 или OSX 10.12 x64). Такой идентификатор называется Runtime identifier (RID). Для каждой ОС/архитектуры существует своя версия библиотеки Core CLR (и прочих нативных компонентов), поэтому для Standalone-приложений на этапе компиляции в свойстве RuntimeIdentifier нужно указывать параметры целевой системы (RID).
Файлы фреймворка(-ов) хранятся в папке C:\Program Files\dotnet\shared.
Можно установить несколько версий фреймворка:
Для выполнения Portable-приложения необходимо запустить хост-процесс dotnet.exe и передать ему в качестве аргумента путь к управляемой сборке.
«C:\Program Files\dotnet» добавляется к значению переменной среды PATH, благодаря чему Portable-приложения теперь могут запускаться из командной строки:
Этот файл является обязательным для Portable-приложений.
Уменьшение количества файлов объясняется тем, что в Core FX 1.0 отсутствовали многие библиотеки, поэтому они шли в составе приложения, как обычные зависимости. В Core FX 2.0 эти сборки были добавлены, поэтому они больше не поставляются с приложением, а берутся из папки фреймворка.
Наблюдается картина, противоположная Portable-приложениям — чем больше становится Core FX, тем больше файлов поставляется с приложением.
Рекомендации по выбору типа развертывания
Выбор версии SDK в файле global.json
Файл global.json имеет очень простой формат, который просто задает, какую версию SDK нужно использовать:
Раньше файл global.json использовался еще и для того, чтобы указать папки с исходным кодом решения, но эта функциональность будет удалена в будущих версиях.
Когда вы запускаете dotnet new или dotnet build , dotnet ищет global.json , сначала в текущей папке, потом во всех родительских папках. Если global.json найден (и доступна версия SDK, указанная там!), то эта версия будет использована для всех запускаемых команд SDK внутри этой папки. Если не получилось найти ни один файл global.json , будет использована последняя доступная версия SDK, в моем случае, 2.0.0-preview1-005977 .
Entity Framework Core
LINQ позволяет писать декларативный код для работы с данными. Данные могут быть представлены разными формами (например, объектами в памяти, содержимым базы данных SQL или XML-документом), но обычно создаваемый код LINQ не отличается для каждого из источников данных.
Пакет SDK и среды выполнения
Загружаемый пакет SDK содержит следующие компоненты.
Загружаемая среда выполнения содержит следующие компоненты.
Дополнительные сведения см. в следующих ресурсах:
Интегрированные среды разработки
Онлайн-среда Visual Studio Code, которая в настоящее время доступна в виде бета-версии.
Working with unmanaged resources
JIT compiler and IL
Since JIT compilation occurs during execution of the application, the compilation time is part of the run time. Therefore, JIT compilers have to balance time spent optimizing code against the savings that the resulting code can produce. But a JIT compiler knows the actual hardware and can free developers from having to ship different implementations for different platforms.
Инструменты и производительность
Автоматическое управление памятью
Сборщик мусора (GC) управляет выделением и освобождением памяти для приложений. Каждый раз, когда код создает новый объект, среда CLR выделяет память для объекта из управляемой кучи. Пока в управляемой куче есть доступное адресное пространство, среда выполнения продолжает выделять пространство для новых объектов. Когда остается недостаточное свободное пространство адресов, сборщик мусора проверяет наличие объектов в управляемой куче, которые больше не используются приложением. Затем эта память освобождается.
GC — это одна из служб CLR, которая помогает обеспечить безопасность памяти. Программа является безопасной по памяти, если она обращается только к выделенной памяти. Например, среда выполнения гарантирует, что приложение не обращается к невыделенной памяти за пределами границ массива.
Дополнительные сведения о сборке мусора см. в статьях Автоматическое управление памятью и Основы сборки мусора.
Бесплатный и открытый исходный код
Работа с неуправляемыми ресурсами
Дополнительные сведения см. в разделе Очистка неуправляемых ресурсов.
SDK and runtimes
The SDK download includes the following components:
The runtime download includes the following components:
For more information, see the following resources:
Модели развертывания
Можно установить несколько версий среды выполнения параллельно, чтобы запускать зависящие от платформы приложения, предназначенные для разных версий среды выполнения. Дополнительные сведения см. в разделе Целевые платформы.
Исполняемые файлы создаются для конкретных целевых платформ, которые указываются с помощью идентификатора среды выполнения (RID).
Объединение формы API против объединения реализаций
Намного лучше унифицировать реализации: вместо того, чтобы только предоставлять хорошо декомпозированное описание, мы должные подготовить декомпозированную реализацию. Это позволит вертикалям просто использовать одну и ту же реализацию. Сближение вертикалей больше не будет требовать дополнительных действий; оно достигается просто за счет правильного конструирования решения. Конечно все равно будут случаи, в которых необходимы различные реализации. Хороший пример этого – это файловые операции, требующие использования разных технологий в зависимости от окружения. Однако, даже в этом случае намного проще попросить каждую команду, отвечающую за конкретные компонент, подумать, как из API будут работать в разных вертикалях, чем постфактум пытаться предоставить единый набор API поверх. Переносимость – это не есть что-то, что вы можете добавить после. К примеру, наш File API включает поддержку Windows Access Control Lists (ACL), которые не поддерживаются всем окружениями. При дизайне API нужно учитывать такие моменты и, в частности, предоставлять подобную функциональность в отдельных сборках, которые могут отсутствовать на платформах, не поддерживающих ACL.
Programming languages
An online Visual Studio Code environment, currently in beta.
Терминология
Система проектов и MSBuild
И вот один для веб-приложения:
Заключение
Конечно, в самой идее предлагать специализированный набор возможностей, удовлетворяющих определенными потребностям, нет ничего плохого. Это становится проблемой, когда отсутствует системный подход и специализация происходит на каждом слое без учета того, что происходит в соответствующих слоях других вертикалей. Последствием таких решения является набор платформ, которые имеют ряд общих API только потому, что они когда-то начинались из единой базы кода. Со временем, это приводит к росту различий, если только не проводить явные (и дорогие) упражнения для достижения единообразия API.
В какой момент возникает проблема с фрагментацией? Если вы нацелены только на одну вертикаль, то в реальности никакой проблемы нет. Вам предоставлен набор API, оптимизированный именно для вашей вертикали. Проблема проявляет себя, как только вы хотите делать что-то горизонтальное, ориентированное на множество вертикалей. Вот теперь вы задаетесь вопросом о доступности различных API и думаете, как производить блоки кода, которые работали бы на разных целевых вертикалях.
Free and open source
Runtime libraries
For more information, see the Runtime libraries overview. The source code for the libraries is in the GitHub dotnet/runtime repository.
JIT-компилятор и промежуточный язык
Так как JIT-компиляция происходит во время выполнения приложения, время компиляции является частью времени выполнения. Таким образом, JIT-компиляторы должны поддерживать баланс между временем оптимизации кода и экономии, к которой может привести результирующий код. Но JIT-компилятор знает фактическое оборудование и может освободить разработчиков от поставки различных реализаций для различных платформ.
Data access
Deployment models
You can install multiple versions of the runtime side by side to run framework-dependent apps that target different versions of the runtime. For more information, see Target frameworks.
Executables are produced for specific target platforms, which you specify with a runtime identifier (RID).
Расширения библиотек среды выполнения
Библиотеки для некоторых часто используемых функциональных возможностей приложения не включены в библиотеки среды выполнения, но доступны в пакетах NuGet, как показано ниже.
Пакет NuGet | Документация |
---|---|
Microsoft.Extensions.Hosting | Управление жизненным циклом приложения (универсальный узел) |
Microsoft.Extensions.DependencyInjection | Внедрение зависимостей |
Microsoft.Extensions.Configuration | Конфигурация |
Microsoft.Extensions.Logging | Logging |
Microsoft.Extensions.Options | Шаблон параметров |
Итоги
На нас лежит ответственность за продолжение выпуска критичных обновлений безопасности, не требующих работы со стороны разработчиков приложений, даже если затрагиваемые компоненты распространятся эксклюзивно как NuGet-пакеты.
А вот и другие наши статьи по схожей тематике:
Для совместного использования функциональных возможностей различных приложений и типов приложений используются библиотеки классов.
Terminology
Поддержка
Каждая реализация включает в себя среду выполнения и библиотеку классов. Сюда также могут входить платформы приложений и средства разработки.
Tools and productivity
Native interop
The main way to interoperate with native APIs is via "platform invoke" or P/Invoke for short. P/Invoke is supported across Linux and Windows platforms. A Windows-only way of interoperating is known as "COM interop," which works with COM components in managed code. It's built on top of the P/Invoke infrastructure, but it works in subtly different ways.
Фреймворки для всей машины против локальных фреймворков для приложения
- Централизованное обслуживание
- Уменьшает размер требуемого места на диске
- Позволяет разделять нативный код между приложениям
- Добавление интерфейса к существующему типу может нарушить работу приложений, так как это может повлиять на то, как тип сериализуется.
- Добавление перегрузки к методу, который раньше не имел любых перегрузок может нарушить работу с рефлексиями в тех случаях, когда в коде не обрабатывается вероятность найти более, чем один метод.
- Переименование внутреннего типа может нарушить приложения, если имя типа определялось через метод ToString().
Это все очень редкие случаи, но, когда у вас пользовательская база в 1.8 миллиарда машин, быть совместимым с 99.9% по-прежнему означает, что 1.8 миллиона машин затронуто.
Такой подход в общем-то почти полностью снимает все проблемы, мешающие вам обновиться до свежей версии. Ваши возможности перейти на новую версию ограничены только вашей возможностью выпустить новую версию вашего приложения. Это также означает, что вы контролируете, какая версия библиотеки используется конкретным приложением. Обновления производятся в контексте одного приложения, никак не затрагивая другие приложения на той же машине.
Это позволяет выпускать обновления в гораздо более гибкой манере. NuGet также предлагает возможность попробовать предварительные версии, что позволяет нам выпускать сборки без строгих обещаний относительно работы конктретных API. Такой подход позволяет нам поддерживать процесс, в котором мы предлагаем вам наш свежий взгляд на дизайн сборки – и, если вам не нравится, просто его изменить. Хороший пример это – это неизменяемые коллекции (immutable collections). Бета-период длился порядка 9 месяцев. Мы потратили много времени, пытаясь добиться правильного дизайна прежде, чем выпустить первую версию. Нет необходимости говорить, что финальная версия дизайна библиотеки, — благодаря вашим многочисленным отзывам, — намного лучше, чем начальная.
Доступ к данным
Языки программирования
Основа для открытого кода и кросс-платформенности
Из прошлого опыта мы знаем, что успех открытого кода зависит от сообщества вокруг него. Ключевой аспект этого – это открытый и прозрачный процесс разработки, который позволит сообществу участвовать в ревью кода, знакомиться с документам по проектированию и вносить свои изменения в продукт.
Конечно, отдельные компоненты, например, файловая система, требуют отдельной реализации. Модель доставки через NuGet позволяет нам абстрагироваться от этих различий. Мы можем иметь единый NuGet-пакет, предоставляющий различные реализации для каждого из окружений. Однако важный момент тут как раз в том, что это внутренняя кухня реализации компонента. С точки зрения разработчика это единый API, который работает на разных платформах.
Наличие всех трех элементов позволяет нам добиться широкого спектра гибкости и зрелости решений:
Нам кажется, что мы нашли хороший баланс между тем, чтобы заложить основу для будущего, сохраняя при этом хорошую совместимость с существующими стеками. Давайте посмотрим детальнее на часть из этих платформ.
5. Runtime Configuration Files
dotnet.exe ([AppName].exe) использует файл [AppName].deps.json для определения абсолютных путей всех зависимостей приложения при его запуске.
Структура [AppName].deps.json:
Секция targets определяет платформу и дерево зависимостей для нее в формате
[ID зависимости (пакета)]/[версия]: dependencies: < список зависимостей (пакетов) данного пакета >,
относительные пути к управляемым и нативным файлам данного пакета
>
Рассмотрим подробнее содержимое файла deps.json Standalone-приложения:
В свойстве dependencies перечислены зависимости (пакеты) конкретного пакета.
Свойство runtimeTargets используется в deps-файле Portable-приложения и определяет пути файлов библиотек для конкретного RID. Такие RID-specific библиотеки поставляются вместе с Portable-приложением в папке runtimes.
Свойства runtime и native содержат относительные пути управляемых (managed) и нативных библиотек соответственно. Свойство resources содержит относительные пути и локали локализованных сборок-ресурсов.
Пути относительны к NuGet package cache, а не deps-файлу.
Добавить сторонний deps-файл можно передав значение аргумента --additional-deps или переменную среды DOTNET_ADDITIONAL_DEPS.
Такая возможность доступна только для Portable приложений.
Когда dotnet.exe (MyApp.exe) определяет пути зависимостей приложения, для каждой отдельной библиотеки составляется список из runtime- и native-путей.
6.1. Запуск приложения
выполняется при помощи мультплексора (muxer) из командной строки (одинаково на любой ОС).
6.2. [corehost] Поиск и загрузка Framework Resolver (hostfxr.dll)
На этом этапе dotnet.exe идет в папку [own directory]/host/fxr/. Для Portable-приложений эта библиотека расположена в общей папке C:\Program Files\dotnet\host\fxr\[FXR version]\hostfxr.dll. Если версий будет несколько, dotnet.exe будет всегда использовать последнюю.
После загрузки hostfxr.dll (Framework Resolver) процесс запуска переходит в рамки этой библиотеки.
6.3. [hostfxr] Определение режима выполнения (standalone, muxer, split/FX)
Первая задача hostfxr — определить режим, в котором будет работать хост процесс и таким образом тип приложения — Portable (FDD) или Standalone (SCD). В Portable (FDD)-режиме он также определяет: это запускаемое приложение или команда SDK.
— если среди аргументов есть такой, значение которого оканчивается на .dll или .exe — процесс запуска продолжится в режиме выполнение указанного файла. Если такого аргумента нет, управление будет передано SDK. Для этого из папки [own directory]\sdk\[version] (если такая существует) будет запущен dotnet.dll (как Portable приложение), и этой сборке будут переданы аргументы текущего хост процесса.
Алгоритм проверки очень простой — если в папке, откуда был запущен мультиплексор [AppName].exe (в нашем случае dotnet.exe), отсутствует coreclr.dll или [AppName].dll, то приложение Portable. Если один из этих двух файлов существует, то далее идет проверка — приложение Portable (split/FX) или Standalone. Если существует [AppName].dll, то приложение Standalone, иначе — Portable (split/FX).
Запуск Portable-приложения может также осуществляться в так называемом Exec mode.
Для этого команда запуска первым аргументом должна содержать exec C:\> dotnet exec . .
При запуске в таком режиме можно явно указать пути к файлам конфигурации:
--depsfile
--runtimeconfig
которые будут использованы вместо файлов в папке приложения.
На текущем этапе hostfxr определяет (по данным файла конфигурации), является ли приложение Portable или Standalone.
При выборе версии учитывается параметр Roll Forward On No Candidate Fx, который указывает строгость соответствия заданной версии и имеющихся на машине.
6.5. [hostfxr] Поиск и загрузка hostpolicy.dll
На текущем этапе всё готово для определения путей runtime-компонентов. Этой задачей занимается библиотека hostpolicy.dll, которая называется Host library.
Если файл не был найден на предыдущем этапе, hostpolicy.dll будет найдено в папке фреймворка.
Как только опеределена hostpolicy.dll, hostfxr загружает эту библиотеку и передает ей управление.
6.6. [hostpolicy] Определение списка зависимостей
Библиотека hostpolicy.dll отвечает за определение абсолютных путей всех зависимостей приложения.
Прежде всего hostpolicy создаст компонент под названием Dependencies Resolver, который в свою очередь загрузит два deps-файла — файл фреймворка и файл приложения.
Сперва загружается список из deps-файл фреймворка, где будут определены такие зависимости, как CoreCLR и библиотеки CoreFX. Затем список из deps-файла приложения, в котором указаны сборки нашего приложения и их зависимости.
Для каждого deps-файла Dependency Resolver составляет список всех зависимостей для указанной runtimeTarget.
Для каждого пакета сначала составляется список файлов из всех секций runtimeTargets (RID specific зависимости), далее — список всех файлов из секций native и runtime. Такой объединенный список относительных путей всех зависимостей в условном формате
ID пакета — RID — тип asset'а (runtime, native) — пути к файлам называется Target assets.
После того, как были составлены эти два списка файлов зависимостей (RID и не RID), выполняется процесс под названием Reconciling libraries with targets (согласования). Он заключается в том, что для каждого пакета из секции libraries проверяется, существует ли RID specific-файлы, которые должны переопределить обычные.
6.7. [hostpolicy] Определение путей TPA, Core CLR и CLR Jit
Далее Dependency resolver составляет список абсолютных путей файлов управляемых сборок — зависимостей приложения. Этот список называется TPA (Trusted Platform Assemblies) и передается Core CLR для настройки AppDomain. Также составляется список абсолютных путей директорий, в которых находятся остальных файлы зависимостей (кроме coreclr, corejit).
Определение абсолютных путей управляемых сборок происходит путем поиска файлов в Probe paths (путей зондирования). По умолчанию их два — папка фреймворка и папка приложения, и они основаны на расположении deps-файлов. Также можно добавить дополнительные пути:
1) передав аргумент --additionalprobingpath, например
--additionalprobingpath %UserProfile%\\.nuget\\packages
В папке фреймворка и приложения наличие файла проверятся (при условии, что он был указан в соответствующем deps-файле) без учета относительного пути, в остальных директориях с учетом относительно пути, потому что эти директории рассматриваются как кеш NuGet-пакета.
- папка приложения;
- папка фреймворка
- Probe paths
После составления списка TPA, определяются пути CoreCLR и CLRJit.
При отсутствии deps-файла приложения, dotnet.exe вначале попытается найти эти библиотеки в [app directory]\lib\. При обычном выполнении пути берутся из папки фреймворка (отбросив относительный путь и взяв только имя файла).
Устанавливаются следующие настройки CoreCLR:
- TRUSTED_PLATFORM_ASSEMBLIES — список обсолютных путей всех управляемых библиотек приложения.
- NATIVE_DLL_SEARCH_DIRECTORIES — абсолютные пути директорий, где найдены нативные зависимости.
- PLATFORM_RESOURCE_ROOTS — абсолютные пути директорий, где найдены зависимости-ресурсы
- AppDomainCompatSwitch — константа «UseLatestBehaviorWhenTFMNotSpecified».
- APP_CONTEXT_BASE_DIRECTORY — папка приложения.
- APP_CONTEXT_DEPS_FILES — абсолютные пути deps-файлов приложения и фреймворка.
- FX_DEPS_FILE — абсолютный путь deps-файла фреймворка.
- PROBING_DIRECTORIES — дополнительные пути зондирования (если они были указаны).
Процесс запуска Standalone-приложения отличается от Portable только начальным этапом, а также местоположением компонентов, которые по умолчанию должны располагаться в папке приложения.
7.2. Процесс запуска
происходит так же, как у Portable-приложения, за исключением того, что существует только один deps-файл и все зависимости ищутся в папке приложения или по указанным --additionalprobepaths.
Если вы только-что установили 2.0 preview 1, то, если наберете в консоли dotnet --info, увидите примерно следующее:
Там целая куча разной информации, среди которой есть два разных номера версий:
- 2.0.0-preview1-005977 — версия SDK
- 2.0.0-preview1-002111-00 — версия среды исполнения
Следующий вопрос — как узнать, какая версия среды исполнения будет использоваться, когда вы запускаете свое приложение?
Всё очень просто: вам нужно указать нужную версию в .csproj файле!
В файле .csproj указано для значение netcoreapp2.0 и будет использована максимальная соответствующая ему версия (на моем компьютере — это 2.0.0-preview1-002111-00 ).
Overloaded terms
runtime
framework
SDK
platform
CLI
Понимание версий SDK
Если вы перейдете в папку C:\Program Files\dotnet\sdk (на маках нужно смотреть в папку /usr/local/share/dotnet/sdk ), вы увидите, какие версии SDK установлены на вашем компьютере. Как видите, у меня установлено две версии: 1.0.0 и 2.0.0-preview1-005977 .
Грубо говоря, SDK — это штука, которая предоставляет команды, связанные со сборкой: dotnet new , dotnet build , dotnet publish и т.п.
В общем случае, любая версия SDK, которая больше версии, использованной при создании проекта, может быть использована для его сборки ( dotnet build и dotnet publish ). Таким образом, вы можете просто использовать SDK версии 2.0 для работы с проектами, созданными в SDK версии 1.0.
Это значит, что в большинстве случаев вы можете использовать для всех проектов последнюю версию SDK. Другая версия SDK может понадобиться, например, если вы хотите собрать проект, использующий файл project.json (в этом случае вам будет нужен RC2 SDK).
Текущая версия SDK также влияет на новые проекты, создаваемые командой dotnet new . Если вы используете SDK версии 2.0 Preview 1, вы получите приложение на основе netcoreapp2.0 , если вы используете SDK версии 1.0, вы получите приложение на основе netcoreapp1.1 !
Следующий вопрос — как указать приложению, какую версию SDK нужно использовать.
NuGet
Дополнительные сведения см. в документации NuGet.
Дополнительные сведения см. в следующих ресурсах:
Execution models
Advanced scenarios
Extensions to the runtime libraries
Libraries for some commonly used application functionality aren't included in the runtime libraries but are made available in NuGet packages, such as the following:
NuGet package | Documentation |
---|---|
Microsoft.Extensions.Hosting | Application lifetime management (Generic Host) |
Microsoft.Extensions.DependencyInjection | Dependency injection (DI) |
Microsoft.Extensions.Configuration | Configuration |
Microsoft.Extensions.Logging | Logging |
Microsoft.Extensions.Options | Options pattern |
NuGet как первоклассный механизм доставки
Для слоя BCL у нас будет прямое соответствие между сборками и пакетами NuGet.
В дальнейшем NuGet-пакеты будут иметь те же имена, что и сборки. К примеру, неизменяемые коллекции перестанут распространяться под именем Microsoft.Bcl.Immutable и вместо этого будут в пакет, называющемся System.Collections.Immutable.
В дополнение, мы решили использовать семантический подход для версионности сборок. Номер версии NuGet-пакета будет согласован с версией сборки.
Согласованность именования и версионности между сборками и пакетами сильно облегчит их поиск. У вас не должно возникнуть вопроса, в каком пакете содержится System.Foo, Version=1.2.3.0 – он находится в пакете System.Foo с версией 1.2.3.
Библиотеки среды выполнения.
Windows Store и Windows Phone
Более детально выбор между двумя подходами описан в статье «Sharing code across platforms».
Готов для корпоративного использования
Automatic memory management
The garbage collector (GC) manages the allocation and release of memory for applications. Each time your code creates a new object, the CLR allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. When not enough free address space remains, the GC checks for objects in the managed heap that are no longer being used by the application. It then reclaims that memory.
The GC is one of the CLR services that help ensure memory safety. A program is memory safe if it accesses only allocated memory. For instance, the runtime ensures that an app doesn't access unallocated memory beyond the bounds of an array.
Модели выполнения.
Для получения дополнительной информации см. Common Language Runtime.
Project system and MSBuild
And here's one for a web app:
0. Pay-for-Play
BCL располагается в GAC, откуда приложения загружают необходимые для работы зависимости.
Примеры компонентов, которые поставляются через NuGet:
Этот подход называется «pay-for-play»; другими словами, приложения загружают только ту функциональность, которая им необходима, но каждая такая функциональность содержится в отдельной сборке.
Entity Framework Core
Language-integrated query (LINQ) lets you write declarative code for operating on data. The data can be in many forms (such as in-memory objects, a SQL database, or an XML document), but the LINQ code you write typically doesn't differ by data source.
Сложные сценарии
Компилятор AOT
- Для некоторых сценариев требуется 100-процентная компиляция AOT. Примером может служить iOS.
- В других сценариях большая часть кода приложения компилируется с помощью AOT, но для некоторых частей используется JIT-компилятор. Некоторые шаблоны кода не распознаются AOT (например, универсальные шаблоны). Примером такой формы компиляции AOT является параметр публикации ready-to-run. Такая форма AOT позволяет использовать преимущества компиляции без ее недостатков.
Support
Each implementation includes a runtime and a class library. It may also include application frameworks and development tools.
AOT compiler
- Some scenarios require 100% AOT compilation. An example is iOS.
- In other scenarios, most of an app's code is AOT-compiled but some is JIT-compiled. Some code patterns aren't friendly to AOT (like generics). An example of this form of AOT compilation is the ready-to-run publish option. This form of AOT offers the benefits of AOT without its drawbacks.
Unsafe code
Depending on language support, the CLR lets you access native memory and do pointer arithmetic via unsafe code. These operations are needed for certain algorithms and system interoperability. Although powerful, use of unsafe code is discouraged unless it's necessary to interoperate with system APIs or implement the most efficient algorithm. Unsafe code may not execute the same way in different environments and also loses the benefits of a garbage collector and type safety. It's recommended to confine and centralize unsafe code as much as possible and test that code thoroughly.
Текст объемный и рассчитан на:
Примеры процессов выполнения описаны для ОС Windows, но работают по тому же принципу и на других ОС (с учетом различных расширений исполняемых файлов и нативных библиотек).
Cross platform
Supported processor architectures include:
Небезопасный код
В зависимости от языковой поддержки среды CLR позволяет обращаться к внутренней памяти выполнять арифметические операции с указателями в коде unsafe . Эти операции необходимы для реализации определенных алгоритмов и системного взаимодействия. Хотя небезопасный код и предоставляет обширные возможности, использовать его не рекомендуется, если только это не требуется для взаимодействия с системными API или реализации максимально эффективного алгоритма. Небезопасный код может выполняться по-разному в разных средах, а также терять преимущества сборщика мусора и безопасности типов. Рекомендуется четко отделить и централизовать небезопасный код, а также тщательно протестировать его.
Взаимодействие на уровне машинного кода
Основным способом осуществления взаимодействия с собственными API является "вызов неуправляемого кода" или сокращенно P/Invoke. P/Invoke поддерживается на платформах Linux и Windows. Способ, который подходит только для Windows, называется "COM-взаимодействием" и используется для работы с COM-компонентами в управляемом коде. Он основан на инфраструктуре P/Invoke, но работает иначе.
Рождение переносимых библиотек классов (Portable Class Library, PCL)
К моменту выхода Windows 8 мы пришли к плану, как бороться с этой проблемой. Когда мы проектировали профиль Windows Store, мы ввели новую концепцию для лучшего моделирования подмножества: контракты.
Идея контрактов заключается в том, чтобы предоставить продуманный набор API, подходящих для задач декомпозиции кода. Контракты – это просто сборки, под которые вы можете компилировать свой код. В отличие от обычных сборок, сборки контрактов спроектированы именно под задачи декомпозиции. Мы четко прослеживаем зависимости между контрактами и пишем их так, чтобы они отвечали за что-то одно, а не были свалкой API. Контракты имеют независимую версионность и следуют соответствующим правилам, например, если добавляется новый API, то он будет доступен в сборке с новой версией.
Сегодня мы используем контракты для моделирования API во всех вертикалях. Вертикаль может просто взять и выбрать, какие контракты она будет поддерживать. Важным моментом является то, что вертикаль обязана поддерживать контракт целиком или не поддерживать вовсе. Другими словами, она не может включить в себя подмножество контракта.
Это позволяет говорить о различиях в API между вертикалями уже на уровне сборок в отличие от индивидуальных различиях в API, как это было раньше. Это позволяет нам реализовать механизм библиотек кода, которые нацелены на множество вертикалей. Такие библиотеки сегодня известны как переносимые библиотеки классов (portable class libraries).
Уточнение терминологии
Среда выполнения
платформа
Пакет SDK
platform
CLI
Кроссплатформенные
Поддерживаемые архитектуры процессоров:
NuGet
For more information, see NuGet documentation.
For more information, see the following resources:
Читайте также: