Microsoft net runtime что это

Обновлено: 03.07.2024

Для совместного использования функциональных возможностей различных приложений и типов приложений используются библиотеки классов.

Кроссплатформенные

Поддерживаемые архитектуры процессоров:

Открытый исходный код

Поддержка

Инструменты и производительность

Языки программирования

Интегрированные среды разработки

Онлайн-среда Visual Studio Code, которая в настоящее время доступна в виде бета-версии.

Пакет SDK и среды выполнения

Загружаемый пакет SDK содержит следующие компоненты.

Загружаемая среда выполнения содержит следующие компоненты.

Дополнительные сведения см. в следующих ресурсах:

Система проектов и MSBuild

И вот один для веб-приложения:

NuGet

Дополнительные сведения см. в документации NuGet.

Дополнительные сведения см. в следующих ресурсах:

Модели выполнения.

Для получения дополнительной информации см. Common Language Runtime.

JIT-компилятор и промежуточный язык

Так как JIT-компиляция происходит во время выполнения приложения, время компиляции является частью времени выполнения. Таким образом, JIT-компиляторы должны поддерживать баланс между временем оптимизации кода и экономии, к которой может привести результирующий код. Но JIT-компилятор знает фактическое оборудование и может освободить разработчиков от поставки различных реализаций для различных платформ.

Компилятор AOT

  • Для некоторых сценариев требуется 100-процентная компиляция AOT. Примером может служить iOS.
  • В других сценариях большая часть кода приложения компилируется с помощью AOT, но для некоторых частей используется JIT-компилятор. Некоторые шаблоны кода не распознаются AOT (например, универсальные шаблоны). Примером такой формы компиляции AOT является параметр публикации ready-to-run. Такая форма AOT позволяет использовать преимущества компиляции без ее недостатков.

Автоматическое управление памятью

Сборщик мусора (GC) управляет выделением и освобождением памяти для приложений. Каждый раз, когда код создает новый объект, среда CLR выделяет память для объекта из управляемой кучи. Пока в управляемой куче есть доступное адресное пространство, среда выполнения продолжает выделять пространство для новых объектов. Когда остается недостаточное свободное пространство адресов, сборщик мусора проверяет наличие объектов в управляемой куче, которые больше не используются приложением. Затем эта память освобождается.

GC — это одна из служб CLR, которая помогает обеспечить безопасность памяти. Программа является безопасной по памяти, если она обращается только к выделенной памяти. Например, среда выполнения гарантирует, что приложение не обращается к невыделенной памяти за пределами границ массива.

Дополнительные сведения о сборке мусора см. в статьях Автоматическое управление памятью и Основы сборки мусора.

Работа с неуправляемыми ресурсами

Дополнительные сведения см. в разделе Очистка неуправляемых ресурсов.

Модели развертывания

Можно установить несколько версий среды выполнения параллельно, чтобы запускать зависящие от платформы приложения, предназначенные для разных версий среды выполнения. Дополнительные сведения см. в разделе Целевые платформы.

Исполняемые файлы создаются для конкретных целевых платформ, которые указываются с помощью идентификатора среды выполнения (RID).

Библиотеки среды выполнения.

Расширения библиотек среды выполнения

Библиотеки для некоторых часто используемых функциональных возможностей приложения не включены в библиотеки среды выполнения, но доступны в пакетах NuGet, как показано ниже.

Пакет NuGet Документация
Microsoft.Extensions.Hosting Управление жизненным циклом приложения (универсальный узел)
Microsoft.Extensions.DependencyInjection Внедрение зависимостей
Microsoft.Extensions.Configuration Конфигурация
Microsoft.Extensions.Logging Logging
Microsoft.Extensions.Options Шаблон параметров

Доступ к данным

Entity Framework Core

LINQ позволяет писать декларативный код для работы с данными. Данные могут быть представлены разными формами (например, объектами в памяти, содержимым базы данных SQL или XML-документом), но обычно создаваемый код LINQ не отличается для каждого из источников данных.

Уточнение терминологии

Среда выполнения

платформа

Пакет SDK

platform

CLI

Сложные сценарии

Взаимодействие на уровне машинного кода

Основным способом осуществления взаимодействия с собственными API является "вызов неуправляемого кода" или сокращенно P/Invoke. P/Invoke поддерживается на платформах Linux и Windows. Способ, который подходит только для Windows, называется "COM-взаимодействием" и используется для работы с COM-компонентами в управляемом коде. Он основан на инфраструктуре P/Invoke, но работает иначе.

Небезопасный код

В зависимости от языковой поддержки среды CLR позволяет обращаться к внутренней памяти выполнять арифметические операции с указателями в коде unsafe . Эти операции необходимы для реализации определенных алгоритмов и системного взаимодействия. Хотя небезопасный код и предоставляет обширные возможности, использовать его не рекомендуется, если только это не требуется для взаимодействия с системными API или реализации максимально эффективного алгоритма. Небезопасный код может выполняться по-разному в разных средах, а также терять преимущества сборщика мусора и безопасности типов. Рекомендуется четко отделить и централизовать небезопасный код, а также тщательно протестировать его.

Почему так происходит? Что это такое и зачем нужен NET Framework ?

Наверное, вы знаете, что основное занятие программистов — написание кода. При этом они используют различные языки программирования, позволяющие сказать компьютеру, что он должен делать:

Microsoft NET Framework - что это такое?

Но есть одна проблема — языки программирования довольно примитивны. С их помощью можно легко выполнять простые действия вроде сложения и умножения. А всё остальное требует долгой и усердной работы. Хотите вывести текст или изображения на экран? Тогда придётся написать много кода, используя самые простые элементы языка.

Microsoft NET Framework - что это такое? - 2

Как установить Microsoft NET Framework

На момент написания статьи самая свежая версия — Microsoft NET Framework 4,7 . Именно её мы и будем устанавливать:

Как установить Microsoft NET Framework

Microsoft Net Framework можно установить и через Центр обновления Windows . Но многие отключают обновление Windows , поэтому данный метод будет предпочтительнее.

Перед установкой — Microsoft Net Framework можно установить на Windows 10 , Windows 8.1 и Windows 7 SP1 как на 32-битные, так и на 64-битные системы. Чтобы установка прошла без ошибок, Microsoft рекомендует иметь на жестком диске минимум 2.5 ГБ свободного пространства.

Microsoft предлагает два вида установщиков: веб-установщик и автономный установщик. Веб-установщик весит меньше 2 МБ, и скачивает все необходимые компоненты во время инсталляции. Поэтому вам потребуется стабильное соединение с интернетом.

Автономный установщик весит около 60 МБ, и не требует доступа к интернету во время инсталляции.

Оба установщика содержат одинаковые версии NET Framework , но мы предпочитаем использовать автономный установщик. Он надёжнее, и всегда будет под рукой, если потребуется переустановить NET Framework . После скачивания процесс установки не должен вызвать затруднений — просто следуйте инструкциям, появляющимся на экране. И тогда вы быстрее поймете, зачем нужен NET Framework 4 .

Как установить Microsoft NET Framework - 2

Обратите внимание, что версия 4.7 — это выполняемое обновление версий 4 , 4.5 , 4.5.1 , 4.5.2 , 4.6 , 4.6.1 и 4.6.2 . Поэтому не удаляйте предыдущие версии после установки. NET Framework 3.5 SP1 и более старые версии устанавливаются отдельно.

По умолчанию NET Framework инсталлирует английскую версию независимо от того, какой вы используете установщик. Для локализации нужно скачать соответствующий языковой пакет. На данный момент языковые пакеты для версии 4.7 доступны только в виде автономных установщиков.

Ещё кое-что о Microsoft Net Framework

Еще одна причина, зачем нужен NET Framework . Несколько лет назад Microsoft открыла исходный код NET Framework , позволив всем желающим вносить свой вклад в разработку платформы. В результате Microsoft стала самой активной организацией на GitHub .

Дайте знать, что вы думаете по данной теме в комментариях. Мы очень благодарим вас за ваши комментарии, лайки, отклики, дизлайки, подписки!

Пожалуйста, оставьте ваши отзывы по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики огромное вам спасибо!

если исключить тех, кто на зарплате, т.е. инженеров Microsoft/Mono/Xamarin, их очень немного.


Как только список был готов, я залез в Википедию (см. список источников). В результате получилась следующая хронологическая последовательность:


Timeline maker
(Для интерактивной версии пройдите по ссылке)

Если я пропустил какие-то среды выполнения, дайте знать.

Чтобы облегчить восприятие хронологии, я поместил каждую среду в одну из следующих категорий:

Оставшаяся часть поста посвящена детальному описанию разных сред выполнения. Почему они появились, что они могут и зачем их сравнивать.

Другие среды выполнения Microsoft

Silverlight

Несмотря на то что платформа находится в режиме поддержки (или вообще умерла/движется к закату в зависимости от вашей точки зрения), интересно вернуться к первоначальному анонсу и посмотреть, для чего предназначалась Silverlight:

В 2007 г. в Silverlight 1.0 были реализованы следующие возможности (платформа даже работала на Linux):

  • поддержка встроенных кодеков для проигрывания видеофайлов VC-1 и WMV, а также аудиофайлов в форматах MP3 и WMA в браузере. ;
  • Silverlight поддерживает возможность постепенного скачивания и проигрывания медиаконтента с любого веб-сервера…;
  • Silverlight также опционально поддерживает встроенную потоковую передачу медиафайлов…;
  • с помощью Silverlight вы можете создавать многофункциональные пользовательские интерфейсы и анимацию, соединять векторную графику и HTML для создания привлекательного контента. ;
  • Silverlight облегчает создание насыщенного интерактивного видеоконтента.

Также, как подсказали в комментах, Silverlight был и на Symbian S60

Среды выполнения Mono/Xamarin

Для меня неважно, кто был первым, потому что я считаю Mono средством достижения цели: технологией, которая поможет Linux закрепиться на настольных компьютерах.

В этом же посте описано, как всё началось:

Проекты сообществ

Исследовательские проекты

Shared Source Common Language Infrastructure (SSCLI) (или Rotor)

Midori

Midori – кодовое имя операционной системы с управляемым кодом, которая разрабатывалась Microsoft совместно с Microsoft Research. Сообщалось, что она может стать коммерческой реализацией операционной системы Singularity, исследовательского проекта, начатого в 2003 г. для создания высоконадёжной операционной системы, в которой ядро, драйвера устройств и приложения состоят из управляемого кода. Она проектировалась для параллельных вычислений и могла запускать программу, распределённую по нескольким узлам одновременно. В ней так же была реализована модель безопасности на основе запуска приложений в изолированной среде. Microsoft предложила несколько возможных путей миграции с Windows на Midori. Работа над операционной системой была прекращена в 2015 году, хотя многие реализованные в ней идеи попали в другие проекты Microsoft.

Singularity (операционная система) (также Singularity RDK)

Singularity – экспериментальная операционная система, которая разрабатывалась Microsoft Research между 2003 и 2010 гг. Предполагалось, что это будет высоконадёжная операционная система, в которой ядро, драйвера устройств и приложения состоят из управляемого кода. Средства внутренней безопасности используют безопасность типов вместо аппаратной защиты памяти.

Redhawk

И последняя, но не менее важная среда – Redhawk:
кодовое название для экспериментальной, минимальной версии среды выполнения с управляемым кодом, которая превратилась в CoreRT.

Ссылки на источники

Ниже приведены статьи Википедии, которые я использовал для создания хронологической шкалы:

Нашлись ещё варианты

Net60

В комментариях bmforce подсказал, что была ещё одна платформа, Net60. Информации о ней не так много, но удалось найти упоминание на форуме + статья на CodeGuru:

Moonlight

Не упоминается Moonlight, который основан на Mono — Opensource версию Silverlight:

Moonlight — это open source реализация Silverlight, сделанная в основном для Linux и других Unix/X11 операционных систем. Последний релиз Moonlight (Moonlight 4 Preview 1) предоставляет поддержку основного набора возможностей Silverlight 3, плюс совместимость с Silverlight 4.

Blazor

PageFX

Текст объемный и рассчитан на:

Примеры процессов выполнения описаны для ОС Windows, но работают по тому же принципу и на других ОС (с учетом различных расширений исполняемых файлов и нативных библиотек).

0. Pay-for-Play


BCL располагается в GAC, откуда приложения загружают необходимые для работы зависимости.

Примеры компонентов, которые поставляются через NuGet:

Этот подход называется «pay-for-play»; другими словами, приложения загружают только ту функциональность, которая им необходима, но каждая такая функциональность содержится в отдельной сборке.

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, тем больше файлов поставляется с приложением.

Рекомендации по выбору типа развертывания

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 <PАTH>
--runtimeconfig <PАTH>
которые будут использованы вместо файлов в папке приложения.

На текущем этапе 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.

Читайте также: