Net core sdk что это

.NET Core 2.1 Global Tools

Пару недель назад вышел .NET Core 2.1 RC1. Это первая версия SDK, где есть фича под названием «Глобальные утилиты .NET Core» («.NET Core Global Tools»). Она дает простой способ создания кросс-платформенных консольных утилит.

Мы познакомимся с основами использования .NET Core Global Tools и кратко посмотрим, что внутри. А еще вы можете скачать .NET Core 2.1 SDK и попробовать написать собственный пример.

Основы

.NET Core global tool — это специальный пакет NuGet, в котором находится консольное приложение. Когда вы устанавливаете его, .NET Core CLI скачивает пакет и делает его доступным в виде новой глобальной консольной команды.

Пользователи могут устанавливать утилиты с помощью команды dotnet tool install :

dotnet tool install -g

После установки консольные утилиты, находящиеся в пакете, будут глобально доступны по имени:

dotnet tool имеет и другие команды. Например:

dotnet tool list -g dotnet tool uninstall -g dotnet tool update -g

Под капотом

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

Когда вы запускаете dotnet tool install —global , происходит следующее:

Запускается dotnet restore со специальными параметрами, чтобы скачать пакет.
Файлы распаковываются в папку $HOME/.dotnet/.store// .
Генерируется запускаемый файл в папке $HOME/.dotnet/tools .

Сгенерированный запускаемый файл — это небольшое консольное приложение (написанное на C++), которое знает, где находится ваш .NET Core DLL файл и автоматически запускает его.

Вы также можете запустить dotnet tool install с аргументом —tool-path $installDir . Эта команда делает всё то же самое, но устанавливает консольное приложение в папку $installDir , а не в $HOME/.dotnet/tools .

Как создать свой пакет

Для создания глобальных консольных утилит вам нужен .NET Core SDK версии 2.1. В этой версии добавлено несколько дополнительных настроек проектов для управления неймингом и содержимым пакетов с глобальными консольными утилитами.

Минимальные необходимые параметры проекта:

  true Exe netcoreapp2.1

Дополнительные (не обязательные) параметры, управляющие сборкой пакета:

AssemblyName — задает название .dll файла вашего консольного приложения.
ToolCommandName — название команды, по которому пользователь будет запускать вашу консольную утилиту. По умолчанию оно совпадает с названием .dll файла (которое задано в параметре AssemblyName ).
- Название команды не обязательно должно начинаться с dotnet- . Можно использовать любое название без пробелов.
- Если название начинается с dotnet- , то утилиту можно будет запускать как команду утилиты dotnet (убедитесь, что команды с таким именем еще нет). Например, утилита dotnet-say-moo может быть вызвана и как dotnet-say-moo , и как dotnet say-moo .
Пример использования этих параметров:
```
  true Exe netcoreapp2.1 pineapple dole-cli 1.0.0-alpha-$(BuildNumber) Dole.Cli  
```
Сборка и установка пакета

Сборка пакета происходит как обычно — при помощи команды dotnet pack . SDK увидит, что установлен параметр PackAsTool=true и автоматически сгенерирует нужные дополнительные файлы.
```
dotnet pack --output ./packages
```
С помощью параметра —source-feed вы можете установить пакет, который еще не опубликован в репозитории пакетов NuGet. Это может быть полезно для проверки, что всё сделано правильно. Также, если версия пакета — не релизная (например, 3.0.0-alpha — содержит что-то, кроме трех чисел), нужно при установке явно указать её.
```
dotnet tool install -g my-package-name --version 3.0.0-alpha --source-feed ./packages/
```
Что внутри пакета

Как я писал выше, команда dotnet pack собирает пакет особым образом, если в файле проекта указан параметр PackAsTool=true .

Зависимости

В пакет попадают не только файлы, полученные через dotnet build , но и все другие зависимости вашего проекта (подключенные сторонние пакеты NuGet). Все файлы, необходимые для работы вашей консольной утилиты, должны быть включены в NuGet пакет. Команда dotnet-tool-install не устанавливает зависимости, указанные в резделе вашего .nuspec файла.

DotnetToolSettings.xml

Генерируется специальный файл DotnetToolSettings.xml , который содержит информацию о вашем консольном приложении. Если этого файла по какой-то причине не окажется в пакете (например, пытаетесь установить произвольный пакет как консольную утилиту), то при установке вы получите ошибку:

The settings file in the tool’s NuGet package is invalid: Settings file ‘DotnetToolSettings.xml’ was not found in the package.

Пример содержимого файла:

Сейчас есть следующие требования к файлу DotnetToolSettings.xml :
- Файл DotnetToolSettings.xml должен находиться в папке tools/$targetframework/any/ . Например: tools/netcoreapp2.1/any/DotnetToolSettings.xml .
- Пакет должен содержать только один файл DotnetToolSettings.xml .
- В файле DotnetToolSettings.xml должна быть описана только одна секция .
- Значение атрибута Runner должно быть «dotnet» .
- В качестве значения атрибута EntryPoint должно быть указано название .dll файла, который лежит в одной папке с файлом DotnetToolSettings.xml .
В .nuspec файл автоматически добавляется параметр . Например:

Если параметр packageType[name] не указан как DotnetTool , то при установке получите ошибку:

error NU1212: Invalid project-package combination for awesome-tool 1.0.0. DotnetToolReference project style can only contain references of the DotnetTool type

Конечно, это не очень понятное сообщение об ошибке. На Github есть issue, чтобы это улучшить.

Что может пойти не так

Глобальные утилиты — глобальные для пользователя, а не для компьютера

.NET Core CLI по умолчанию устанавливает глобальные утилиты в папку $HOME/.dotnet/tools (на Linux/macOS) или в папку %USERPROFILE%\.dotnet\tools (на Windows). Это значит, что вы не можете установить пакет глобально для всех пользователей компьютера с помощью dotnet tool install —global . Установленные утилиты доступны только для пользователя, который их установил.

Не хватает пути в переменной PATH

Обычно .NET Core автоматически добавляет путь к папке с установленными утилитами в переменную окружения PATH , чтобы они были доступны по имени, без указания полного пути. Но иногда это может не сработать. Например:
- если вы добавили переменную окружения DOTNET_SKIP_FIRST_TIME_EXPERIENCE (например, чтобы ускорить первый запуск .NET Core), то значение переменной PATH может быть не установлено при первом использовании
- macOS: если вы установили CLI из .tar.gz файла (а не из .pkg файла), то у вас может не быть файла /etc/paths.d/dotnet-cli-tool который настраивает переменную PATH .
- Linux: вам нужно вручную отредактировать свой shell environment file, т.е ~/.bash_profile или ~/.zshrc
В этом случае при запуске своей консолььной утилиты вы получите ошибку. Например:

bash: my-command-name: command not found

Чтобы всё заработало, нужно добавить в переменную PATH путь к папке с утилитами. Например так (после добавления нужно перезапустить терминал):
```
cat > ~/.bash_profile # Add .NET Core SDK tools export PATH EOF
```
Или вот так можно добавить для текущей сессии:
```
export PATH 
```
Примеры выше — для MacOS. Для других систем всё аналогично. Кроме того, при установке вашей глобальной консольной утилиты команда dotnet tool install проверит, что переменная PATH правильно настроена и предложит варианты решения, если это не так.

.NET Core CLI установлен не в папку по умолчанию

Если вы скачали .NET Core CLI как .zip/.tar.gz архив и распаковали его в папку, которая отличается от папки по умолчанию, то при запуске своей консольной утилиты вы можете получить ошибку:
- Windows: A fatal error occurred, the required library hostfxr.dll could not be found
- Linux: A fatal error occurred, the required library libhostfxr.so could not be found
- macOS: A fatal error occurred, the required library libhostfxr.dylib could not be found
В сообщении об ошибке будет также дополнительная информация:

If this is a self-contained application, that library should exist in [some path here].
If this is a framework-dependent application, install the runtime in the default location [default location] or use the DOTNET_ROOT environment variable to specify the runtime location.

Причина в том, что запускаемы файл, который генерируется командой dotnet tool install при установке пакета, ищет .NET Core в папке по умолчанию. Вы можете переопределить пути по умолчанию, установив переменную окружения DOTNET_ROOT . Например:
```
# Windows set DOTNET_ROOT=C:\Users\username\dotnet # MacOS/Linux export DOTNET_ROOT=/Users/username/Downloads/dotnet
```
Подробности в issue на GitHub.

Заключение

Мы познакомились с глобальными консольными утилитами в .NET Core. На мой взгляд, это очень крутая штука. Я крайне счастлив, что команда .NET Core её запилила. Не могу дождаться, когда все начнут её использовать 🙂

Net core sdk что это

Создадим первую программу на ASP.NET Core. Что нам для этого потребуется? Прежде всего необходим текстовый редактор для написания кода программы. В данном случае я буду использовать в качестве текстового редактора Visual Studio Code

Также для компиляции и запуска программы нам потребуется .NET SDK. Для его установки перейдем на официальный сайт по ссылке .NET SDK

Выберем последнюю на данный момент версию — .NET SDK 7 и загрузим его. Затем запустим программу установки:

После установки .NET SDK для первого проекта определим какую-нибудь папку. Например, в моем случае это будет папка C:\dotnet\aspnet\helloapp . Откроем терминал/командную строку и перейдем к созданной папке проекта с помощью команды cd
```
cd C:\dotnet\aspnet\helloapp
```
В данном случае мы для создания и запуска проекта мы будем использовать встроенную инфраструктуру .NET CLI, которая устанавливается вместе с .NET SDK.

Для создания проекта в .NET CLI применяется команда dotnet new , после которой указывается тип проекта. Для ASP.NET Core есть ряд встроенных типов проектов. В данном случае мы будем использовать самый простейший тип — web . Поэтому введем в терминале команду
```
dotnet new web
```
После выполнения этой команды у нас будет создан следующий проект:

Структура проекта ASP.NET Core

Рассмотрим базовую структуру простейшего стандартного проекта ASP.NET Core:
- Dependencies : все добавленные в проект пакеты и библиотеки, иначе говоря зависимости
- Properties : узел, который содержит некоторые настройки проекта. В частности, в файле launchSettings.json описаны настройки запуска проекта, например, адреса, по которым будет запускаться приложение.
- appsettings.json : файл конфигурации приложения в формате json
- appsettings.Development.json : версия файла конфигурации приложения, которая используется в процессе разработки
- helloapp.csproj : стандартный файл проекта C#, который соответствует назанию проекта (по умолчанию названию каталога) и описывает все его настройки.
- Program.cs : главный файл приложения, с которого и начинается его выполнение. Код этого файла настраивает и запускает веб-приложение
Например, посмотрим на содержимое файла helloapp.csproj
```
  net7.0 enable enable   
```
Ключевой компонент здесь — атрибут Sdk=»Microsoft.NET.Sdk.Web» , который собственно и определяет, что приложение будет использовать SDK «Microsoft.NET.Sdk.Web», который предназначен именно для веб-проектов.

Запуск проекта

Проект по умолчанию не представляет какой-то грандиозной функциональности, тем не менее этот проект мы уже можем запустить. Итак, запустим проект. Для этого выполним команду
```
dotnet run
```
При запуске в консоли мы можем увидеть адрес, по которому мы можем обращаться к приложению. В моем случае это адрес «http://localhost:5197/». И я могу обратиться по этому адресу к приложению в браузере и увидеть в нем строку «Hello World!» — результат работы кода по умолчанию из файла Program.cs :

Запуск приложения и файл Program.cs

Рассмотрим код файла Program.cs , который создает подобное приложение:
```
var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/", () => "Hello World!"); app.Run();
```
Это так называемое Minimal API — упрощенная минизированная модель для запуска веб-приложения в ASP.NET.

Приложение в ASP.NET Core представляет объект Microsoft.AspNetCore.Builder.WebApplication . Этот объект настраивает всю конфигурацию приложения, его маршруты, используемые зависимости и т.д.. Исходный код класса на github: https://github.com/dotnet/aspnetcore/blob/main/src/DefaultBuilder/src/WebApplication.cs

Для создания объекта WebApplication необходим специальный класс-строитель — WebApplicationBuilder . И в файле Program.cs вначале создается данный объект с помощью статического метода WebApplication.CreateBuilder :
```
var builder = WebApplication.CreateBuilder(args);
```
В качестве параметра в метод передаются аргументы, которые передаются приложению при запуске.

Получив объект WebApplicationBuilder , у него вызывается метод Build() , который собствено и создает объект WebApplication :
```
var app = builder.Build();
```
С помощью объекта WebApplication можно настроить всю инфраструктуру приложения — его конфигурацию, маршруты и так далее. В файле Program.cs по умолчанию для приложения определяется один маршрут:
```
app.MapGet("/", () => "Hello World!");
```
Метод MapGet() в качестве первого параметра принимает путь, по которому можно обратиться к приложению. В данном случае это путь «/», то есть по сути корень веб-приложения — имя домена и порта, после которых может идти слеш, например, https://localhost:7256/

В качестве второго параметра в метод MapGet() передаются обработчик запроса по этому маршруту в виде функции. Здесь это лямбда-выражение, которое возвращает строку «Hello World!». Именно поэтому при обращении к приложению мы увидим данную строку в браузере.

И в конце необходимо запустить приложение. Для этого у класса WebApplication вызывается метод Run() :
```
app.Run();
```
В итоге запустится приложение в виде консоли, и мы сможем обращаться к приложению из различных браузеров.

.NET Core – SDK

Чтобы узнать больше о прогрессе, вы можете скачать последнюю версию .NET Core SDK, прокрутив вниз, и вы увидите раздел «Установщик и двоичные файлы».

Вы можете увидеть последнюю версию инструментов предварительного просмотра для разных операционных систем, давайте выберем Установщик в соответствии с вашей операционной системой.

Мы работаем над предварительным просмотром 1 .NET Core 2.0.

Давайте теперь посмотрим на наши текущие инструменты, открыв командную строку и выполнив следующую команду.
```
dotnet --info
```
Вы увидите информацию об установленной на данный момент версии .NET Command Line Tools в вашей системе, как показано ниже.

Вы можете видеть, что в настоящее время у нас есть предварительный просмотр 2 инструментов. Теперь давайте запустим следующую команду, чтобы узнать о новой команде.
```
dotnet help new
```
Для нового командного языка проекта, вы можете выбрать как C # и F # и тип проекта и т. Д.

Давайте теперь посмотрим на изменения в последней версии .NET Core. После загрузки установщика дважды щелкните его, чтобы установить. Нажмите на Установить.

На следующем снимке экрана показан процесс установки.

Начнется процесс установки. После завершения установки закройте это диалоговое окно.

Откройте командную строку и выполните следующую команду.
```
dotnet --info
```
Вы увидите информацию об установленной на данный момент версии .NET Command Line Tools в вашей системе, как показано ниже.

Теперь вы можете видеть, что у нас есть предварительный инструментарий .NET Core 2. Теперь давайте запустим следующий код в командной строке, чтобы узнать о новой команде в .NET Core 2 preview1.
```
dotnet help new
```
Команда также помогает вам загружать пакеты в кеш пакетов.

Команда открывает следующую веб-страницу, которая содержит информацию о новой команде в .NET Core 2 preview1.

Давайте прокрутим вниз, теперь вы можете видеть, что мы можем создать приложение .NET Core с большим количеством шаблонов.

Теперь мы можем создавать проекты mstest, web, mvc и webapi, а также с помощью командной строки.

Расставим точки над .NET Core и .NET Standard

В последнее время в компании Microsoft произошло много изменений. Поддержка Docker контейнеров в Windows Server 2016, нативное подключение через SSH в CMD (ура! можно забыть о PuTTY!), изменения в рендоре консоли в Windows, Unix решения для Azure, поддержка Pyton в Visual Studio, мощьный открытый редактор Visual Studio Code и Visual Studio для Mac OS . Microsoft действительно стала «ближе» к Unix , ближе к Open Source. Конечно не осталась в стороне и платформа .NET. Тут тоже произошло много приятных подвижек и нововведений. Если раньше C# + Linux был уделом энтузиастов, то теперь — это прекрасная альтернатива Java. Именно об этих технологиях и будут написано несколько моих следующих статей. Но сначала давайте разберемся с точками в .NET.

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

Среда .NET.

Перед тем как углубляться в детали, обсудим среду .NET в целом и место, которое в ней занимают .NET Core и .NET Standard.

Платформа .NET Framework появилась 15 лет назад(!). Тогда в её состав входил только один стек технологий .NET, с помощью которого можно было разрабатывать приложения для ПК под управлением Windows и веб-приложения. Но шло время и с тех пор появились и другие реализации .NET, например, Xamarin для разработки мобильных приложений для iOS и Android и классических приложений для macOS. Потом пришел mono фреймворк, появилась идея о .NET vNext в 2014г. Стало понятно, что классический .NET Freamwork не обладает должной гибкостью. Так возникла идея о стандартизации базовых API.

Какое же место здесь занимают .NET Core и .NET Standard?
- .NET Core — это самая новая реализация .NET. Это проект Open Source с версиями для нескольких ОС. .NET Core позволяет создавать кроссплатформенные консольные приложения, а также приложения и облачные службы ASP.NET Core.
- .NET Standard — это набор базовых API (другое их название — BCL, библиотека базовых классов), которые должны поддерживаться во всех реализациях .NET. .NET Standard позволяет создавать библиотеки, подходящие для любых приложений .NET, вне зависимости от реализации .NET или операционной системы, в которой они выполняются.
.NET Core

.NET Core — это открытая универсальная платформа разработки, которая поддерживается корпорацией Майкрософт и сообществом .NET на сайте GitHub. Она является кроссплатформенной, поддерживает Windows, Mac OS и Linux и может использоваться на устройствах, в облаке, во внедренных системах и в сценариях IoT (Интернета вещей). В её основе лежат технологии .NET Framework и Silverlight. Она оптимизирована для мобильных и серверных рабочих нагрузок, поскольку обеспечивает поддержку самодостаточных развёртываний XCOPY.

Чтобы лучше понять, что такое .NET Core, давайте попробуем разработать небольшое приложение для .NET Core. При этом мы познакомимся с новыми программами командной строки. Разрабатывать решения .NET Core можно в Visual Studio 2017, но раз уж вы читаете эту статью, я предположу, что с Visual Studio вы знакомы неплохо, и буду рассказывать в первую очередь о новых возможностях.

При создании .NET одним из главных приоритетов была высокая скорость разработки приложений для Windows. На практике это означает, что разработка .NET была неразрывно связана с Visual Studio. Безусловно, Visual Studio — замечательный инструмент. Он позволяет работать эффективно, а его отладчик — однозначно лучший из тех, которые мне доводилось использовать.

Но в некоторых случаях Visual Studio — не самый удобный вариант. Допустим, вы хотите поэкспериментировать с .NET, чтобы изучить C#. Для этого не хотелось бы скачивать и устанавливать IDE объемом в несколько гигабайт… Ладно, существует Sharp Develop , скажите вы. Но, допустим, вы подключаетесь к компьютеру с Linux через SSH? Тогда работать через IDE вообще не получится. А может быть, вам просто нравится командная строка?

Для таких случаев создана отличная программа для работы в командной строке — .NET Core CLI . Основной компонент .NET Core CLI называется dotnet . Его можно использовать для решения практически любых задач разработки, в частности, для создания, сборки, тестирования и упаковки проектов. Давайте посмотрим, как это работает.

Пример 1

Для начала создадим и запустим консольное приложение Hello World (я буду использовать PowerShell для Windows, но в Bash для macOS или Linux все делается аналогично).

На сегодняшний день C# стал полностью кроссплатформенным языком, что конечно не может не радовать! Я лишь буду ждать и наедятся на то, что Java побыстрее умрет))) Смерть жабе!

Дополнительная литература.
- # Руководство по .NET Core
- О будущем .NET
- C# .NET Core programs vs Java. Скорость.
Похожие публикации: