Net core runtime что это

.NET Core

.NET Core — это универсальная платформа разработки, которая поддерживается корпорацией Майкрософт и сообществом .NET на сайте GitHub. Она является кроссплатформенной: поддерживает Windows, Mac OS и Linux. Имеет открытый исходный код: распространяется по лицензиям MIT и Apache 2.

Начиная с .NET 5, версии называются .NET (без «Core» в названии), что символизирует объединение .NET Core, Mono и .NET Framework. Также в этой версии появилась поддержка архитектур Arm — Arm32 (armh, armv7) и Arm64 (aarch64, armv8).

Платформа .NET Core является кроссплатформенным аналогом .NET Framework на уровне библиотек базовых классов (BCL) .NET Framework. Она реализует спецификацию библиотеки .NET Standard.

Важным отличием от проекта Mono, который направлен на создание свободной среды, совместимой с .NET Framework, является то, что .NET Core не имеет реализации Windows Forms и не реализует API .NET Framework с использованием тех же имён сборок, то есть не позволяет запускать приложения, собранные для .NET Framework.

Для ALT p9, p10 и Sisyphus собран .NET 6, соответствующий спецификации .NET Standard 2.1.

В составе SDK поставляется компилятор C# с открытым исходным кодом из состава .NET Compiler Platform — Roslyn.

В качестве среды разработки удобно использовать Visual Studio Code (см. подробнее по ссылке), для которого имеется расширение, позволяющее отлаживать приложения, написанные на C# под .NET Core на Linux.

• 1 Установка
• 2 Создание приложения «Hello, world!»
  • 2.1 Вывод команд

  Установка

  Для установки среды выполнения (CoreCLR) с необходимыми библиотеками установите мета-пакет dotnet:

  apt-get install dotnet

  Для разработки приложений установите SDK для .NET Core (пакет dotnet-sdk):

  apt-get install dotnet-sdk

  Создание приложения «Hello, world!»

  (Необходимо иметь в домашнем каталоге >2 ГБ свободного места)

  dotnet new console -o hwapp cd hwapp dotnet restore dotnet build dotnet run

  Вывод команд

  $ dotnet new console -o hwapp Welcome to .NET Core! --------------------- Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs. Telemetry -------------- The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell. You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry. Configuring. ------------------- A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once. Decompressing 100% 7675 ms Expanding 100% 14205 ms Getting ready. The template "Console Application" was created successfully. Processing post-creation actions. Running 'dotnet restore' on hwapp/hwapp.csproj. Restore succeeded. $ cd hwapp $ dotnet run Hello World!

  Основные команды

  Всё взаимодействие с .NET Core из командной строки осуществляется через команду

  $ dotnet

  Для запуска приложения:

  $ dotnet программа

  Для запуска команды управления пакетами NuGet:

  $ dotnet nuget

  Для скачивания и подготовки всех необходимых для сборки проекта пакетов:

  $ dotnet restore

  $ dotnet msbuild

  Для запуска тестов MSTest или xUnit:

  $ dotnet test

  Диагностика

  $ dotnet run --verbosity diag

  Desktop-приложения

  Сама по себе платформа .NET Core покрывает и поддерживает только модель консольных приложений и приложений ASP.NET Core. Реализация WPF (Windows Presentation Foundation) отсутствует для платформы Linux.

  В настоящее время (июль 2017) шаги к портированию WPF на .NET Core заключаются в обсуждении стандарта XAML Standard, которым описываются UI-элементы, чтобы появилась возможность реализовать System.XAML. После чего возникнет теоретическая возможность портировать/реализовать WPF поверх .NET Core.

  ASP.NET

  Частью ASP.NET Core является кросс-платформенный веб-сервер KestrelHttpServer.

  • Начинаем работать с ASP.NET Core.
  • ASP.NET 5 мёртв — представляем ASP.NET Core 1.0 и .NET Core 1.0

  Установить пакет dotnet-aspnetcore

  apt-get install dotnet-aspnetcore

  $ mkdir aspnetcoreapp $ cd aspnetcoreapp $ dotnet new web $ dotnet run

  Если требуется доступ отовсюду, то запускаем так

  Однако, по рекомендации MS, если приложение смотрит в Интернет, нужно использовать обратный прокси-сервер (IIS, Nginx или Apache).

  Особенности

  • Поддерживается только 64-битная платформа (x86_64).
  • В настоящий момент nuget нормально не поддерживает работу в оффлайн-режиме (с предварительно подготовленным кэшем), и даже с использованием локального репозитория есть проблемы.

  ARM

  Ссылки

  • Архитектурные компоненты .NET
  • .NET Core
  • .NET Cli для начинающих
  • публикация приложения
  • Перенос кода в .NET Core из .NET Framework
  • Представлен .NET 5 (релиз в ноябре 2020 года)

  Исходный код

  • dotnet/runtime — содержит .NET Core runtime, называемый CoreCLR и базовую библиотеку (mscorlib) с низкоуровневыми классами и базовыми типами данных.
  • dotnet/sdk — исходный код команд, касающихся сборки проекта (таких, как ‘dotnet build’, ‘dotnet restore’ и ‘dotnet publish’).
  • corewf — неофициальный порт Windows Workflow Foundation на .NET (без XAML не работает) (состояние портирования)
  • referencesource — исходный код части модулей .NET Framework 4.7 (для сверки)

  В чем отличие между .NET Core SDK и .NET Core Runtime?

  В чем отличие между .NET Core SDK и .NET Core Runtime и что нужно ставить разработчику и пользователю моей программы?

  Отслеживать
  задан 15 янв 2018 в 17:53
  user233225 user233225

  1 ответ 1

  Сортировка: Сброс на вариант по умолчанию

  • SDK (Software Developer Kit) — для разработки ПО и т.д.
  • Runtime — для запуска ПО.

  Пользователю вашей программы нужно ставить Runtime (как не странно).

  Отслеживать
  ответ дан 15 янв 2018 в 18:08
  Volodymyr Rets Volodymyr Rets
  2,417 13 13 серебряных знаков 26 26 бронзовых знаков

  Вообще по идеи, да, но я решил проверить прав ли я в Гугле, но ответа не нашел. А нужно ли мне ставить Runtime? (я разработчик)

  – user233225
  15 янв 2018 в 18:10
  @Editaw5, github.com/dotnet/cli/issues/7235 .Если ты установишь SDK то получишь сразу и Runtime
  15 янв 2018 в 18:13

  Важное на Мете

  Похожие

  Подписаться на ленту

  Лента вопроса

  Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

  Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697

  Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

  Структура и модель выполнения .NET Core приложений

  В этой статье я рассмотрю компоненты платформы .NET Core 2.0, необходимые для загрузки и выполнения .NET Core-приложений, а также артефакты для двух возможных типов развертывания.

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

  • начинающих разработчиков, которые только знакомятся с платформой .NET Core;
  • опытных разработчиков, выполняющих роль DevOps-инженеров в produсtion-окружении.

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

  0. Pay-for-Play

  

  Каждому .NET-разработчику известно с пелёнок: чтобы запустить любое .NET-приложение, на целевом компьютере должен быть установлен .NET Framework, а именно CLR + BCL.

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

  Архитектура .NET Core в общем виде выглядит так же: .NET Core = Core CLR + Core FX (новое название для BCL), но отличается способом разрешения этих компонентов, а также способом загрузки среды выполнения (CLR). Вместо заголовка в управляемой сборке MyApp.exe в .NET Framework, в .NET Core MyApp.exe сам по себе является нативной программой загрузки Core CLR.

  В .NET Core все компоненты программы, которые мы определяем на этапе компиляции, являются зависимостями приложения (включая Core CLR, JIT), которые инфраструктура .NET Core рассматривает как пакеты. Такой пакет называется asset, при этом он может быть как NuGet-пакетом, так и обычным файлом.

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

  • Microsoft.NETCore.Runtime.CoreCLR — Core CLR.
  • Microsoft.NETCore.Jit — JIT-компилятор.
  • System.Private.CoreLib — базовые типы System.Object, System.Int32, System.String (аналог mscorlib.dll).
  • System.Console — доступ к консоли.

  Благодаря такой модели .NET Core-приложение состоит из пугающе огромного количества мелких модулей, но это сделано, чтобы уменьшить объем ненужных зависимостей.

  Этот подход называется «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).

  Такое приложение будет работать на любом компьютере с определенной ОС/архитектурой, независимо от того, установлен ли .NET Core или нет.

  2. .NET Core Runtimes (shared frameworks)

  Для выполнения Portable-приложений на целевой машине должен быть установлен хотя бы один .NET Core Runtime (shared framework).

  .NET Core Runtime устанавливается в папку C:\Program Files\dotnet:

  

  Файлы фреймворка(-ов) хранятся в папке C:\Program Files\dotnet\shared.

  Основные составляющие .NET Core Runtime:

  • «Утилита» dotnet.exe для запуска .NET Core-приложения. Она называется мультплексор (muxer), и является основным драйвером инфраструктуры .NET Core. Эта программа служит «точкой входа» для запуска любых приложений и выполнения команд разработки. если установлена .NET Core SDK, то есть является хост-процессом любого приложения — corehost.
  • Runtime-компоненты (CoreCLR, CoreFX, и т.д.), устанавливаются в отдельную папку фреймворка C:\Program Files\dotnet\shared\[Framework name]\[Framework version].
  • Host framework resolver — нативная библиотека, находится в папке
    C:\Program Files\dotnet\host\[версия]\hostfxr.dll. При запуске приложения, максимальная версия этой библиотеки выполняет разрешение версии фреймворка для последующего выполнения приложения.

  Можно установить несколько версий фреймворка:

  

  Для выполнения Portable-приложения необходимо запустить хост-процесс dotnet.exe и передать ему в качестве аргумента путь к управляемой сборке.

  «C:\Program Files\dotnet» добавляется к значению переменной среды PATH, благодаря чему Portable-приложения теперь могут запускаться из командной строки:

  В папке приложения (там, где находится [AppName].dll) должен лежать файл [AppName].runtimeconfig.json. В нём указаны имя и версия фреймворка, которые должны быть использованы для выполнения Portable-приложения. Например:

  MyApp.runtimeconfig.json

  Этот файл является обязательным для Portable-приложений.

  Имея вышеприведенную конфигурацию, компоненты среды выполнения будут загружены из папки C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.0.

  3. Структура Portable (FDD) .NET Core-приложения

  Любое Portable .NET Core-приложение состоит из таких обязательных файлов:

  • [AppName].dll — IL-код приложения, точка входа.
  • [App dependencies]*.dll — все зависимости приложения, не входящие в состав CoreFX (сборки проектов, сторонние библиотеки, FCL).
  • [AppName].runtimeconfig.json — конфигурация среды выполнения, здесь указаны имя и версия .NET Core-фреймворка (runtime-компонентов). Файл является чем-то вроде MyApp.exe.config в .NET Frameowork. Эту конфигурацию можно изменять, если необходимо явно указать конкретный фреймворк.
  • [AppName].deps.json — перечень всех зависимостей приложения. Не рекомендуется изменять этот файл, потому что он генерируется при компиляции. Файл не является обязательным, но если его удалить, хост-процесс при запуске не сможет проверить пути всех файлов зависимостей, и выполнение начнется на свой страх и риск.

  Артефакты одного и того же Portable-приложения для различных версий платформы .NET Core:

  

  Уменьшение количества файлов объясняется тем, что в Core FX 1.0 отсутствовали многие библиотеки, поэтому они шли в составе приложения, как обычные зависимости. В Core FX 2.0 эти сборки были добавлены, поэтому они больше не поставляются с приложением, а берутся из папки фреймворка.

  4. Структура Standalone (SCD) .NET Core приложения

  Такая же, как для Portable (FDD)-приложения, но дополнительно содержит все runtime-компоненты (CoreCLR, CoreFX) и собственный мультиплексор dotnet.exe, переименованный в [AppName].exe. Для .NET Core до версии 2.0 мультиплексор для запуска Standalone-приложения идентичен C:\Program Files\dotnet.exe (тот же файл, только переименованный). Для .NET Core 2.0 используется мультиплексор из NuGet-пакета Microsoft.NETCore.DotNetAppHost. В пакете находится один файл apphost.exe, в который при компиляции «зашивается» в имя сборки (MyApp.dll), а сам файл переименовывается в MyApp.exe. При старте Standalone-приложения проверяется «привязка» исполняемого файла (MyApp.exe) к имени сборки, которую он может запустить (MyApp.dll).

  Содержимое одного и того же Standalone-приложения для различных версий платформы .NET Core:

  

  Наблюдается картина, противоположная Portable-приложениям — чем больше становится Core FX, тем больше файлов поставляется с приложением.

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

  • Всегда отдавайте предпочтение Portable-развертыванию, потому что этот тип гораздо меньше по объему и более стабилен при запуске крупных приложений с большим количеством зависимостей. Кроме того, Portable-приложения легче в настройке, ведь они не зависят от RID.
  • Выбирайте Standalone, если нет возможности установить .NET Core Runtime, или если критична продолжительность запуска приложения. В Standalone-версии можно выиграть 1-2 секунды при запуске за счет удаления файла конфигурации [AppName].deps.json (помните, что при этом на вас ложится ответственность за наличие всех файлов зависимостей).

  5. Runtime Configuration Files

  Файлы [AppName].runtimeconfig.json и [AppName].deps.json называют Runtime Configuration Files (*.deps.json называют dependency manifest file). Они создаются в процессе компиляции и содержат всю информацию, необходимую для запуска dotnet.exe и выполнения приложения.

  В [AppName].runtimeconfig.json задаются имя и версия .NET Core runtime (там же указывается, будет ли учтена patch-версия (SemVer) при поиске фреймворка), а также устанавливаются параметры работы Core CLR (режим работы сборщика мусора). Этот файл обязателен для Portable- и не обязателен для Standalone-приложения.

  dotnet.exe ([AppName].exe) использует файл [AppName].deps.json для определения абсолютных путей всех зависимостей приложения при его запуске.

  Структура [AppName].deps.json:

  Термином target называют целевую платформу (имя и версия), на котором должно выполняться данное приложение (напр., .NET Framework 4.6.2, .NET Core App 1.1, Xamarin.Mac 1.0, .NET Standard 1.6). Эта конфигурация аналогична NuGet target framework.

  Секция targets определяет платформу и дерево зависимостей для нее в формате

  [ID зависимости (пакета)]/[версия]: dependencies: < список зависимостей (пакетов) данного пакета >,
  относительные пути к управляемым и нативным файлам данного пакета
  >

  Для выполнения любого приложения, target должен обязательно содержать RID, например .NETCoreApp,Version=v1.1/win10-x64. Файл deps.json Standalone-приложения всегда один и содержит RID целевой платформы. Для Portable-приложения файлов deps.json два — один в папке фреймворка, второй в папке приложения. RID для Portable-приложений указан в файле [FrameworkName].deps.json в папке фреймворка. После того, как dotnet.exe определил фреймворк для выполнения приложения, он сперва загружает deps-файл этого фреймворка (например, C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.0\Microsoft.NETCore.App.deps), а затем deps-файл приложения. Deps-файл приложения имеет более высокий приоритет.

  Рассмотрим подробнее содержимое файла deps.json Standalone-приложения:

  SampleApp.deps.json

  "targets": < ".NETCoreApp,Version=v1.1/win7-x64": < . "libuv/1.9.1": < "dependencies": < "Microsoft.NETCore.Platforms": "1.1.0" >, "native": < "runtimes/win7-x64/native/libuv.dll": <>> >, . "system.data.sqlclient/4.3.0": < "dependencies": < "System.Data.Common": "4.3.0", "System.IO.Pipes": "4.3.0", "System.Text.Encoding.CodePages": "4.3.0", "runtime.native.System.Data.SqlClient.sni": "4.3.0" >, "runtimeTargets": < "runtimes/unix/lib/netstandard1.3/System.Data.SqlClient.dll": < "rid": "unix", "assetType": "runtime" >, "runtimes/win/lib/netstandard1.3/System.Data.SqlClient.dll": < "rid": "win", "assetType": "runtime" >> >, . "runtime.win7-x64.microsoft.netcore.runtime.coreclr/1.1.1": < "runtime": < "runtimes/win7-x64/lib/netstandard1.0/SOS.NETCore.dll": <>, "runtimes/win7-x64/lib/netstandard1.0/System.Private.CoreLib.dll": <>, "runtimes/win7-x64/lib/netstandard1.0/mscorlib.dll": <> >, "native": < "runtimes/win7-x64/native/System.Private.CoreLib.ni.dll": <>, "runtimes/win7-x64/native/clretwrc.dll": <>, "runtimes/win7-x64/native/coreclr.dll": <>, "runtimes/win7-x64/native/dbgshim.dll": <>, "runtimes/win7-x64/native/mscordaccore.dll": <>, "runtimes/win7-x64/native/mscordbi.dll": <>, "runtimes/win7-x64/native/mscorlib.ni.dll": <>, "runtimes/win7-x64/native/mscorrc.debug.dll": <>, "runtimes/win7-x64/native/mscorrc.dll": <>, "runtimes/win7-x64/native/sos.dll": <> > > 

  В свойстве dependencies перечислены зависимости (пакеты) конкретного пакета.
  Свойство runtimeTargets используется в deps-файле Portable-приложения и определяет пути файлов библиотек для конкретного RID. Такие RID-specific библиотеки поставляются вместе с Portable-приложением в папке runtimes.

  Свойства runtime и native содержат относительные пути управляемых (managed) и нативных библиотек соответственно. Свойство resources содержит относительные пути и локали локализованных сборок-ресурсов.

  Пути относительны к NuGet package cache, а не deps-файлу.

  Добавить сторонний deps-файл можно передав значение аргумента —additional-deps или переменную среды DOTNET_ADDITIONAL_DEPS.

  Такая возможность доступна только для Portable приложений.

  Значение аргумента может содержать полный путь к deps-файлу, а также путь к директории, где расположены общие deps-файлы. Внутри этой директории deps-файлы должны быть расположены в структуре \shared\[FX name]\[FX version]\*.deps. Например, shared\Microsoft.NETCore.App\2.0.3\MyAdditional.deps.json.

  Такой подход использует Visual Studio для неявного добавления в проект Application Insights через файл
  C:\Program Files\dotnet\additionalDeps\ Microsoft.AspNetCore.ApplicationInsights.HostingStartup\
  shared\Microsoft.NETCore.App\ 2.0.3\ Microsoft.AspNetCore.ApplicationInsights.HostingStartup.deps.json

  Когда dotnet.exe (MyApp.exe) определяет пути зависимостей приложения, для каждой отдельной библиотеки составляется список из runtime- и native-путей.

  • тип зависимости (project, package, reference),
  • serviceable (только для типа package) — индикатор того, является ли пакет Serviceable (определяет, может ли сборка пакета быть пропатчена (заменена) внешними службами, Windows Update или .NET Core Servicing Index).
  • хэш пакета (для package зависимостей)
  • др. данные

  6. Процесс запуска Portable .NET Core-приложения

  На целевом компьютере должен быть установлен .NET Core Runtime, соответствующий конфигурации запускаемого приложения.

  6.1. Запуск приложения
  выполняется при помощи мультплексора (muxer) из командной строки (одинаково на любой ОС).

  dotnet.exe — переименованный corehost.exe, эта программа является хост-процессом любого .NET Core-приложения, с неё начинается процесс запуска.

  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 приложение), и этой сборке будут переданы аргументы текущего хост процесса.

  Также для Portable (FDD)-приложения hostfxr определяет фреймворк (.NET Core Runtime), откуда будут загружены компоненты для выполнения.

  Алгоритм проверки очень простой — если в папке, откуда был запущен мультиплексор [AppName].exe (в нашем случае dotnet.exe), отсутствует coreclr.dll или [AppName].dll, то приложение Portable. Если один из этих двух файлов существует, то далее идет проверка — приложение Portable (split/FX) или Standalone. Если существует [AppName].dll, то приложение Standalone, иначе — Portable (split/FX).

  Режим Split/FX используется для запуска xunit и означает, что приложение запускается происходит как Portable, с собственным hostfxr.dll. Этот режим не используется в версии .NET Core 2.0.

  Запуск Portable-приложения может также осуществляться в так называемом Exec mode.
  Для этого команда запуска первым аргументом должна содержать exec C:\> dotnet exec . .

  При запуске в таком режиме можно явно указать пути к файлам конфигурации:
  —depsfile
  —runtimeconfig
  которые будут использованы вместо файлов в папке приложения.

  6.4. [hostfxr] Определение .NET Core Runtime
  Первым делом hostfxr определяет и загружает файлы конфигурации deps и runtimeconfig. Если ничего не переопределено в аргументах, эти файлы берутся из папки приложения.

  На текущем этапе hostfxr определяет (по данным файла конфигурации), является ли приложение Portable или Standalone.

  После загрузки файлов конфигурации и определения режима hostfxr определяет папку фреймворка (.NET Core Runtime).

  Для этого hostfxr сначала определит, какие версии установлены в папке shared, а затем выберет из этого списка релиз-версию, с учетом значений в [AppName].runtimeconfig.json.

  При выборе версии учитывается параметр Roll Forward On No Candidate Fx, который указывает строгость соответствия заданной версии и имеющихся на машине.

  6.5. [hostfxr] Поиск и загрузка hostpolicy.dll
  На текущем этапе всё готово для определения путей runtime-компонентов. Этой задачей занимается библиотека hostpolicy.dll, которая называется Host library.

  Процесс поиска hostpolicy.dll заключается в последовательных проверках различных локаций. Но сначала определяется версия hostpolicy из deps-файла фреймворка (напр. C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.0\Microsoft.NETCore.App.deps). В этом файле будет найден пакет с именем Microsoft.NETCore.DotNetHostPolicy и взята его версия.

  Затем ищется патч (замена) hostpolicy.dll (с учетом версии, если она была определена на предыдущем шаге, и RID) в папке .NET Core Servicing (для Windows — в папке C:\Program Files[ (x86)]\coreservicing\pkgs). Если такой файл найден, он загружается для дальнейшего использования.

  Если файл не был найден на предыдущем этапе, 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

  2) указав в файле [AppName].runtimeconfig.json (приоритет ниже, чем у аргумента), например

  В папке фреймворка и приложения наличие файла проверятся (при условии, что он был указан в соответствующем 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 — дополнительные пути зондирования (если они были указаны).

  7. Процесс запуска Standalone (SCD) .NET Core приложения

  Процесс запуска Standalone-приложения отличается от Portable только начальным этапом, а также местоположением компонентов, которые по умолчанию должны располагаться в папке приложения.

  Этот файл (apphost.exe) поставляется через NuGet в пакете Microsoft.NETCore.DotNetAppHost.
  Внутри файла содержится текстовый placeholder (его значение — SHA-256 хэш строки foobar).
  При выполнении команды SDK dotnet build значение placeholder’а меняется на имя запускаемой сборки (напр., MyApp.dll), а apphost.exe переименовывается в MyApp.exe. Таким образом происходит привязка исполняемого файла к сборке. При запуске приложения .NET Core >= 2.0 вначале проверяется эта «привязка».

  7.2. Процесс запуска
  происходит так же, как у Portable-приложения, за исключением того, что существует только один deps-файл и все зависимости ищутся в папке приложения или по указанным —additionalprobepaths.

  8. Подведем итоги

  • Компонентная модель .NET Core (Runtime, BCL) полностью состоит из NuGet-пакетов.
  • Существует два типа развертывания — FDD и SCD. По возможности рекомендуется использовать Framework Dependent-развертывание, чтобы избежать сложностей с платформозависимыми компонентами и не поставлять лишние зависимости.
  • Как мы могли убедится, есть достаточно много возможностей повлиять на процесс запуска на целевой машине, и при необходимости переопределить/пропатчить файлы зависимостей, а также добавить неявные (динамически запускаемые) зависимости.
  • Не рекомендуется без особых причин удалять или изменять файл Dependency manifest (*.deps.json) .
  • Используя —additional-deps и —additionalprobepaths мы можем размещать runtime-компоненты в нужной нам файловой структуре.
  • Используя Exec mode можно переопределить файлы конфигурации приложения.
  • Посмотреть Trace-лог процесса запуска можно, установив переменную среды COREHOST_TRACE=1

  Возможности .NET Core

  В последние годы все более популярной становится бесплатная платформа .NET. Она используется многими разработчиками для создания и тестирования приложений, это возможно за счет открытого исходного кода. Одним из вариантов горизонтального увеличения платформы в различные операционные системы стала .NET Core. С ее помощью обеспечивается возможность работы с приложениями, которые разрабатывались для Windows и прочих ОС.

  Что это такое

  

  Активное развитие .NET Core стало закономерным итогом работы над приложениями. Одной из главных причин для головной боли практически каждого разработчика являются непредсказуемые условия, в которых будет запускаться та или иная программа. На каждом устройстве используется собственная версия операционной системы, конфигурация, драйверы и т. д., что не всегда позволяет учесть все заранее и сделать приложение рабочим.

  Именно по этой причине начались поиска способа унифицировать среду для запуска приложений. И одной из наиболее успешных попыток в этой области можно назвать «Дот Нет», которая была разработана более 20 лет назад компанией Microsoft.

  Главная идея ее создания заключалась в том, чтобы добавить специальную программную «прослойку», которая располагалась бы между операционкой и приложением. Именно на эту прослойку были возложены функции сглаживания особенностей конкретной конфигурации ОС, тем самым упрощая запуск программы в имеющейся среде.

  Модель .NET активно применяется для разработки приложений следующих видов:

  • веб-API и микрослужбы;
  • классические и мобильные приложения;
  • web-приложения;
  • службы «Виндоус»;
  • консольные программы и т. д.

  Плюс использования платформы заключается в том, что файлы кода и проекта выглядят идентично и не зависят от типа разрабатываемого приложения.

  Помимо Windows ОС, платформа dot NET Core также доступна в различных дистрибутивах Linux. Разработчики публикуют новый выпуск практически для всех дистрибутивов «Линукса», почти всегда в них имеется диспетчер пакетов для установки. По этой причине платформа становится все более популярной у программистов и постепенно вытесняет схожие решения.

  Начиная с 2016 года было выпущено более 10 версий дополнения. Первые из них назывались .NET Core, однако начиная с 2019 года это название было сокращено до .NET.

  Архитектура

  .NET Core базируется на архитектуре .NET Framework. Однако есть и несколько кардинальных отличий: например, платформа имеет возможность использования облачных технологий, функционал для кроссплатформенности и модульности. Также в версии Core произошло отделение среды выполнения от библиотеки.

  Так как дополнение является модульным, то каждый его компонент обновляется через отдельный менеджер пакетов. Это позволяет обновлять каждый модуль по отдельности. В итоге программа или приложение может работать с отдельными модулями и не зависеть от обновления всей платформы.

  Дополнение было разработано корпорацией Microsoft, поэтому является ее собственностью. Однако инструмент был и остается бесплатным для использования.

  Удаленный офис
  и онлайн-продажи
  За 1 день.
  С бесплатным тестовым периодом.
  Конфигуратор удаленных рабочих мест
  Рабочие места для команды за 1 день

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

  Одно из основных характеристик «Дот Нет» является гибкое развертывание. Вы можете устанавливать платформу как часть приложения, так и отдельно. При использовании FDD удается уменьшить пакет развертывания, минимизировать использование памяти и дискового пространства.

  Развертывание приложений на платформе осуществляется в нескольких режимах:

  • При размещении приложения, находящегося в зависимости от платформы, генерируются исполняемые и двоичные файлы, включая ПО и его зависимости. Конечному пользователю для запуска программы необходимо дополнительно запустить среду выполнения. Исполняемый файл напрямую зависит от платформы, а двоичный – DLL – является кроссплатформенным.
  • При тестирования автономного приложения используется исполняемый файл, содержащий среду выполнения, библиотеки, а также само ПО и его зависимости. За счет этого пользователи могут открыть программу на устройстве, на котором ранее не устанавливалась среда .NET. Автономные приложения находятся в прямом подчинении у платформы, но при необходимости их можно опубликовать в виде компиляции AOT.

  Параллельно возможно использовать разные версии среды для загрузки приложения. Это позволит запускать программы, зависящие от платформы. Исполняемые файлы генерируются для определенной платформы, которые обозначаются специальным идентификатором среды.

  Общий код для .NET Core и других платформ

  

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

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

  На сегодня «Дот Нет» поддерживает несколько языков программирования, в том числе C#, F# и Visual Basic .NET.

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

  Как все знают, в мире существует множество разнообразных ОС, поэтому разработчики заинтересованы в том, чтобы их приложения распространялись в разных операционках. И случаев, когда запустить программу, разработанную для другой операционной системы, невозможно, становится все больше и больше. В этом случае для запуска требуется «портировать» приложение и только потом пытаться установить его в текущей ОС.

  В ряде случаев этого можно добиться простым перекомпилированием исходного текста программы. Однако чаще всего это не помогает, а это значит, что программу придется переписывать практически с нуля.

  Однако Microsoft учли этот момент при разработке .NET Core. По сути платформа стала играть роль «стандартизирующей» прослойки, которая позволила добиться адаптации исходного кода под среду ОС. Это значит, что приложение для одной операционки без труда будет запускаться в другой.

  Такой подход позволил избежать портирования отдельных программ, а портировать только программную прослойку. Для достижения цели Microsoft решили портировать один из компонентов модели .NET, в результате чего и появилась платформа «Дот Нет». Ее функциональность практически полностью совпадает с исходной версией и в чем-то даже стала намного шире.

  Сегодня .NET Core активно применяется в трех операционных системах: помимо Windows, это еще Linux и macOS. Это позволяет запускать новые приложения во всех ОС без дополнительных изменений. Именно это качество платформы называется кроссплатформенностью.

  Конечно, нужно понимать, что добиться 100% совместимости программ с любыми ОС практически нереально. Даже сейчас на платформе .NET не реализованы WebForms и Windows Forms.

  В рамках кросс-совместимости платформа включает в себя и модульную инфраструктуру. Это позволяет получить доступ к пакетным данным и функциям. Благодаря этому значительно упрощается процесс создания ПО, повышается производительность и безопасность процессов.

  Кроме этого, модульная инфраструктура помогает быстрее обновлять платформу, так как модули выпускаются и обновляются по отдельности.

  Выводы

  Характер платформы .NET делает ее незавершенной, поэтому она находится в постоянной доработке и обновлении. Если ранние версии инструмента использовались для приложений с большой функциональностью, то на современных этапах сделан акцент на развитие поддержки API и поддержку Visual Basic.

  Главная функция дополнения заключается в предоставлении разработчикам большей свободы и одновременно контроля над процессами, особенно при обновлении и развертывании программ. Не удивительно, что .NET Core становится основным инструментом для разработки приложений разного типа и сложности.

  Надеемся, что вы разобрались в том, что такое .NET Core и для чего эта платформа используется в программировании. Если у вас остались вопросы, то задайте их специалистам нашей компании Xelent!

  Похожие публикации:

  1. Ado net что это
  2. Как скачать картинку с deviantart
  3. Скрещенный или скрещенный как правильно
  4. Что такое res в информатике