Dotnet runtime что это

.NET 5.0 является последней версией.

Поддерживаемые выпуски

Даты окончания жизненного цикла версий Windows 10 зависят от выпуска. В следующей таблице рассматриваются только выпуски Домашняя, Профессиональная, Pro для образовательных учреждений и Pro для рабочих станций. Дополнительные сведения см. в справочных материалах по жизненному циклу поддержки Windows.

Символ + представляет минимальную версию.

Неподдерживаемые выпуски

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

В Windows можно установить три различные версии среды выполнения:

Сведения о пакете SDK

Зависимости

.NET 5 поддерживает следующие версии Windows:

Символ + представляет минимальную версию.

.NET Core 3.1 поддерживает следующие версии Windows:

Символ + представляет минимальную версию.

.NET Core 3.0 поддерживает следующие версии Windows:

Символ + представляет минимальную версию.

.NET Core 2.2 поддерживает следующие версии Windows:

Символ + представляет минимальную версию.

.NET Core 2.1 поддерживает следующие версии Windows:

Символ + представляет минимальную версию.

Автономная установка для Windows 7

Обязательно ознакомьтесь с зависимостями ниже, необходимыми для Windows 7.

Windows 7 / Vista / 8.1 / Server 2008 R2 / Server 2012 R2

Приведенные выше требования также применяются, если возникает ошибка, связанная с любой из следующих библиотек DLL:

Установка с помощью функции автоматизации PowerShell

Сценарии dotnet-install используются для автоматизации непрерывной интеграции и ее осуществления без прав администратора. Вы можете скачать сценарий со страницы справочника по сценариям dotnet-install.

Установка с помощью Visual Studio

Если среда Visual Studio уже установлена, вы можете проверить ее версию, выполнив указанные ниже действия.

Выбор рабочей нагрузки

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

Установка вместе с Visual Studio Code

Visual Studio Code — это эффективный и облегченный редактор исходного кода, который работает на компьютере. Visual Studio Code доступен для Windows, macOS и Linux.

Установщик Windows

/quiet
Предотвращает отображение любого пользовательского интерфейса и запросов.

norestart
Предотвращает все попытки перезапуска.

В случае успешной установки установщик возвращает код 0; если требуется перезагрузка, установщик возвращает код 3010. Любое другое значение обычно является кодом ошибки.

Скачивание и установка вручную

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

Docker

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

Корпорация Майкрософт предоставляет образы, которые предназначены для конкретных сценариев. Например репозиторий ASP.NET Core содержит образы, которые предназначены для запуска приложений ASP.NET Core в рабочей среде.

Источник

.NET Core: номера версий и global.json

Стоит также отметить, что, если вы хотите создавать приложения ASP.NET Core 2.0 в Visual Studio, вам нужно будет установить предварительную версию Visual Studio 2017. Её можно устанавливать параллельно со стабильной версией.

Там целая куча разной информации, среди которой есть два разных номера версий:

Следующий вопрос — как узнать, какая версия среды исполнения будет использоваться, когда вы запускаете свое приложение?

Понимание версий SDK

В общем случае, любая версия SDK, которая больше версии, использованной при создании проекта, может быть использована для его сборки ( dotnet build и dotnet publish ). Таким образом, вы можете просто использовать SDK версии 2.0 для работы с проектами, созданными в SDK версии 1.0.

Это значит, что в большинстве случаев вы можете использовать для всех проектов последнюю версию SDK. Другая версия SDK может понадобиться, например, если вы хотите собрать проект, использующий файл project.json (в этом случае вам будет нужен RC2 SDK).

Следующий вопрос — как указать приложению, какую версию SDK нужно использовать.

Выбор версии SDK в файле global.json

Файл global.json имеет очень простой формат, который просто задает, какую версию SDK нужно использовать:

Раньше файл global.json использовался еще и для того, чтобы указать папки с исходным кодом решения, но эта функциональность будет удалена в будущих версиях.

Заключение

Источник

Долгосрочная поддержка

Файл appHost в macOS и заверение

Параметр командной строки

Дополнительные сведения о параметре UseAppHost см. в разделе Свойства MSBuild для Microsoft.NET.Sdk.

Windows Forms

Только для Windows

В Windows Forms внесены критические изменения.

Только для Windows

Чтобы добавить поддержку C++/CLI в Visual Studio 2019 версии 16.4, установите рабочую нагрузку Разработка классических приложений на C++. При использовании этой рабочей нагрузки в Visual Studio добавляется два шаблона:

Источник

Погружение в ASP.NET 5 Runtime

Данная статья является переводом ASP.NET 5 — A Deep Dive into the ASP.NET 5 Runtime — введения в архитектуру DNX и построенного на нем ASP.NET 5. Так как оригинальная статья была написана в марте 2015 года, во время, когда ASP.NET 5 был еще в стадии активной разработки (примерно beta 3), многое в ней устарело. Поэтому при переводе вся информация была актуализирована до текущей версии ASP.NET 5 (RC1), также были добавлены ссылки на связанные ресурсы (в основном на docs.asp.net) и исходный код на GitHub (смотрите только в случаях, если вам интересна реализация). Приятного погружения!

Логически архитектура DNX имеет пять слоев. Я опишу каждый из этих слоев вместе с их обязанностями.
Изображение взято из статьи DNX-structure wiki

Слой первый: Нативный процесс

Нативный процесс (имеется в виду процесс операционной системы) — это очень тонкий слой с обязанностью найти и вызвать нативный CLR host, передав в него аргументы, переданные в сам процесс. В Windows — это dnx.exe (находится в %YOUR_PROFILE%/.dnx/runtimes/%CHOOSEN_RUNTIME%). В Mac и Linux — это запускаемый bash script (тоже с именем dnx).

Примечание: DNX приложения (и консольные и веб-приложения ASP.NET 5) исполняются в адресном пространстве этого нативного процесса. С этого момента и далее под «нативным процессом» я буду подразумевать dnx.exe и его аналоги в других операционных системах.

Слой второй и третий: Нативные CLR host и CLR

Слой четвертый: Управляемая Entry Point

Слой пятый: Application Host

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

DNVM устанавливает DNX’ы из NuGet feed настроенного на использование DNX_FEED переменной среды. DNX’ы не являются NuGet пакетами в традиционном смысле — пакеты на которые вы можете ссылаться в качестве зависимостей. NuGet — это удобный способ доставки и управления версиями DNX. По умолчанию DNX устанавливается копированием и распаковкой архива с DNX в «%USERPROFILE%/.dnx».

Код нашего приложения:

dnx run — это просто сокращение, нативный процесс, фактически, развернет его в команду:

Что будет соответствовать шаблону:

Microsoft.DNX.ApplicationHost — последний слой DNX, все что находится выше можно считать ASP.NET 5.

ASP.NET 5

Хостинг веб-приложений

Для запуска веб-приложения Microsoft.DNX.ApplicationHost должен вызывать entry point метод github Microsoft.AspNet.Hosting.

Команды, на самом деле, только устанавливают дополнительные аргументы для dnx.exe и когда вы набираете dnx web для запуска веб-приложения, в реальности это преобразуется в:

В свою очередь, вызов entry point Microsoft.AspNet.Server.Kestrel github преобразуется в вызов:

Так что итоговая команда будет:

Пока статья про хостинг в документации docs.asp.net не готова, прочитать про ключи, используемые для настройки хостинга, можно здесь.

Стартовая логика веб-приложения

Слой хостинга также ответственен за запуск github стартовой логики docs веб-приложения. Раньше она находилась в файле Global.asax, теперь по умолчанию находится в классе Startup и состоит из Configure метода, используемого для построения конвейера обработки запросов и ConfigureServices метода, используемого для настройки сервисов веб-приложения.

Request delegate — это ключевая концепция ASP.NET 5. Request delegate — это обработчик входящего запроса, он принимает HttpContext и асинхронно делает нечто полезное с ним:

Обработка запроса в ASP.NET 5 — это вызов по цепочке зарегистрированных request delegate. Но принятие решения о вызове следующего request delegate в цепочке, остается за их автором, поэтому каждый request delegate может прекратить обработку запроса и вернуть ответ пользователю.

В качестве упрощения регистрации в конвейере обработки запросов request delegate не вызывающего следующий request delegate, вы можете использовать Run extension метод IApplicationBuilder.

Того же самого можно достичь используя Use extension метод и не вызывая следующий request delegate:

И пример с вызовом следующего в цепочке request delegate:

Middleware

Вызов следующего (если вы хотите вызвать следующий) в цепочке request delegate должен осуществляться внутри Invoke метода. Если вы разместите какую-нибудь логику ниже вызова следующего request delegate, то она будет выполнена после того, как все следующие за вашим обработчики входящего запроса отработают.

В конвейер обработки запросов вы можете включить middleware следующее этому соглашению с помощью UseMiddleware extension метода IApplicationBuilder:

Любые параметры, переданные в этот метод, будут внедрены в конструктор middleware после RequestDelegate next и запрошенных сервисов.
Конструктор middleware, принимающий дополнительно сервисы и параметры:

Включение middleware в конвейер обработки запросов и передача ему параметров:

По-соглашению, включение middleware в цепочку вызовов следует оформлять в виде «Use. » extension метода у IApplicationBuilder:

Чтобы включить этот middleware в конвейер обработки запросов, вам необходимо вызвать этот extension метод в Configure методе:

Сервисы

Startup класс также поддерживает внедрение зависимостей, для этого достаточно запросить их в качестве параметров конструктора.

Вы можете добавлять собственные сервисы в IoC-контейнер. Добавляемые сервисы могут быть одними из трех типов: transient (AddTransient метод IServiceCollection ), scoped (AddScoped метод IServiceCollection ) или singleton (AddSingleton метод IServiceCollection ).

Transient сервисы создаются при каждом их запросе из контейнера. Scoped сервисы создаются, только если они еще не создавались в текущем scope. В веб-приложениях scope-контейнер создается для каждого запроса, поэтому можно думать о них как о сервисах, создаваемых для каждого http-запроса. Singleton сервисы создаются только один раз за цикл жизни приложения.

Конфигурация приложения

Пример файла appsettings.json:

Пример получения конфигурации приложения, используя Configuration API:

Запросить данные, вы можете используя метод GetSection и имя ключа:

Или обратившись по индексу:

Механизм Options позволяет использовать Plain Old CLR Object (POCO) классы в качестве объектов с настройками. Вы можете добавить его в ваше приложение, вызвав AddOptions extension-метод у IServiceCollection в ConfigureServices методе:

В пример выше MvcOptions github — это класс, который MVC-фреймворк использует для получения от пользователя своих настроек.

Вы также можете легко передать часть конфигурационных настроек в options:

В этом случае ключи настроек из конфигурации будут мапиться на имена свойств POCO класса настроек.

Внутренне механизм Options работает через добавление IConfigureOptions в сервис-контейнер, где TOptions — класс с настройками. Стандартная реализация IOptions будет собирать все IConfigureOptions одного типа и «суммировать их свойства», а затем предоставлять конечный экземпляр — это происходит потому что вы можете множество раз добавлять объект с настройками одного и того же типа в сервис-контейнер, переопределяя настройки.

Веб-сервер

Например, feature интерфейс для Http-request:

Источник

Команда dotnet

Краткий обзор

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

Выполнение команды (требуется установка пакета SDK):

Описание

Команда dotnet выполняет две функции:

Параметры

Параметры для dotnet

—info

—version

—list-runtimes

—list-sdks

-?|-h|—help

Выводит список доступных команд.

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

-d|—diagnostics

Включает вывод диагностических данных.

-v|—verbosity

-?|-h|—help

command options

Для каждой команды определяются относящиеся к ней параметры. Список доступных для команды параметров можно просмотреть на соответствующей ей странице.

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

Путь, содержащий политику проверки и проверяемые сборки.

Путь к дополнительному файлу .deps.json. Файл deps.json содержит список зависимостей, зависимости компиляции и сведения о версии, используемые для устранения конфликтов сборок. Дополнительные сведения см. в разделе Файлы конфигурации среды выполнения на GitHub.

—runtimeconfig

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

Определяет поведение, когда требуемая общая платформа недоступна. Параметр N может принимать следующие значения:

Дополнительные сведения о накате можно найти в этой статье.

—fx-version

Команды dotnet

Общее

Ссылки на проекты

Пакеты NuGet

Команды NuGet

Команды рабочей нагрузки

Команды глобального, установочного и локального средства

Дополнительные средства

Примеры

Сборка проекта и его зависимостей в указанном каталоге:

Источник