Dotnet run asp net linux

Разворачиваем и демонизируем ASP.NET Core приложение под Linux в виде фонового сервиса

Далее, мы можем просто установить dotnet-пакет при помощи apt-get:

sudo apt-get install dotnet-dev-1.0.4

Теперь можем смело приступать к созданию приложения

Создание приложения

При помощи команды dotnet new мы можем создать шаблон для нашего приложения, подобно шаблонам из Visual Studio. Подробная документация к команде.

На текущий момент (07.2017), команда dotnet new поддерживает следующие шаблоны:

Мы создадим веб-приложение ASP.NET Core:

На выходе консоль выдаст нам следующее сообщение:

Чтобы убедиться, что шаблон сгенерировался правильно, заглянем в содержимое папки при помощи команды ls -la .

Все необходимые папки для сборки приложения на месте, приступим! Для начала, восстановим все пакеты при помощи dotnet restore .

Теперь можем собрать приложение:

Запустим приложение с помощью:

Консоль говорит нам, что приложение запустилось по адресу localhost:5000/. Проверим:

Желающих подробнее узнать, как работает web-сервер отсылаю к официальному источнику.

Теперь убьём процесс нажав Ctrl + C и опубликуем приложение командой dotnet publish. Эта команда упаковывает приложение и все его зависимости для дальнейшего развёртывания (желающим интимных подробностей сюда).

В случае проблем с правами доступа Вам поможет команда sudo chmod и эта страница документации.

Если мы хотим развернуть наше приложение под linux-сервером, необходимо настроить прокси и демонизировать процесс запуска приложения. Для проксирования мы будем использовать nginx, для демонизации процесса systemd. Краткое описание утилиты

Как следует из документации выше, с asp.net core в коробке идет kestrel — веб-сервер для asp.net приложений. Зачем нам тогда нужен прокси-сервер? Ответ даётся на официальной странице Microsoft:

Если вы выставляете ваше приложение в интернет, Вы должны использовать IIS, Nginx или Apache как обратный прокси-сервер.

Обратный прокси-сервер получает HTTP запросы из сети и направляет их в Kestrel после первоначальной обработки, как показано на след диаграмме:

Главная причина, по которой следует использовать обратный прокси сервер — безопасность. Kestrel относительно нов и ещё не имеет полного комплекта защиты от атак.

Ещё одна причина, по которой следует использовать обратный прокси-сервер — наличие на сервере нескольких приложений, использующих один порт. Kestrel не поддерживает разделение одного порта между несколькими приложениями.

Так же, использование обратного прокси-сервера может облегчить распределение нагрузки и поддержку SSL.

Как говорилось выше, в качестве прокси-сервера мы будем использовать nginx.

Т.к. в качестве прокси-сервера у нас используется не IIS, следует добавить следующие строки в метод Configure файла Startap.cs.

app.UseForwardedHeaders(new ForwardedHeadersOptions < ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto >); 

Здесь мы включаем поддержку ForwardedHeaders мидлвера из пакета. Microsoft.AspNetCore.HttpOverrides, который будет вставлять в Http-запрос заголовки X-Forwarded-For и X-Forwarded-Proto, использующиеся для определения исходного IP адреса клиента и передачи его прокси-серверу. Определение мидлверов и практическое использование так же будет рассмотрено в дальнейших частях этого гайда.

Если у Вас nginx не установлен, выполните следующую команду.

sudo apt-get install nginx

Далее, нам необходимо сконфигурировать nginx для проксирования http-запросов.

Создадим файл /etc/nginx/sites-available/aspnetcore.conf. Папка sites-avalible укахывает nginx-у, какие веб-сайты доступны на текущем сервере для обработки. Добавим в него следующие строки:

Создадим символическую ссылку на aspnetcore.conf в папку sites-enabled, в которой отражаются запущенные nginx-ом сайты.

sudo ln -s /etc/nginx/sites-available/aspnetcore.conf /etc/nginx/sites-enabled/aspnetcore.conf

(символическая ссылка — специальный файл в файловой системе, в котором вместо пользовательских данных содержится путь к файлу, открываемому при обращении к данной ссылке (файлу)(С) Википедия — прим. авт.)

Nginx настроен на то, чтобы принимать запросы с localhost:8888. Перезапускаем nginx командой sudo service nginx restart , чтобы созданные нами конфигурационные файлы вступили в силу. Проверяем:

502-я ошибка говорит, что сервер перенаправляет нас в другое место и в этом месте что-то пошло не так. В нашем случае — я убил процесс с нашим веб-приложением, которое было ранее запущено командой dotnet run. Потому что могу 🙂

На самом деле, потому что запускать dotnet run в консоли и вечно держать эту вкладку открытой грустно. Именно поэтому процесс будем демонизировать, то есть настроем автозапуск после перезагрузки и автоматическую работу в фоне с помощью systemd.

Для этого создадим файл в директории /etc/systemd/system/ с расширением .service

sudo nano /etc/systemd/system/kestrel-test.service

[Unit]
Description=Example .NET Web API Application running on Ubuntu

[Service]
WorkingDirectory=/home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish #путь к publish папке вашего приложения
ExecStart=/usr/bin/dotnet /home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish/test-lesson.dll # путь к опубликованной dll
Restart=always
RestartSec=10 # Перезапускать сервис через 10 секунд при краше приложения
SyslogIdentifier=dotnet-example
User=root # пользователь, под которым следует запускать ваш сервис
Environment=ASPNETCORE_ENVIRONMENT=Production

Теперь включим и запустим сервис при помощи следующих команд:

sudo systemctl enable kestrel-test.service sudo systemctl start kestrel-test.service

sudo systemctl status kestrel-test.service

Если всё было сделано правильно, на эта команда выдаст нам следующее:

Перейдём по ссылке ещё раз:

Ну вот, дело в шляпе. Спасибо за внимание!

Источник

dotnet run

dotnet run — выполняет исходный код без дополнительных явных команд компиляции или запуска.

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

dotnet run [-a|--arch ] [-c|--configuration ] [-f|--framework ] [--force] [--interactive] [--launch-profile ] [--no-build] [--no-dependencies] [--no-launch-profile] [--no-restore] [--os ] [--project ] [-r|--runtime ] [-v|--verbosity ] [[--] [application arguments]] dotnet run -h|--help 

Описание

dotnet run — это удобное средство для запуска приложения из исходного кода одной командой. Это полезно для быстрой последовательной разработки из командной строки. В отношении сборки кода эта команда зависима от команды dotnet build . Любые требования к сборке, например, то, что проект сначала нужно восстановить, применяются и к dotnet run .

dotnet run не учитывает такие аргументы, как /property:property=value , которые учитывает dotnet build .

Выходные файлы записываются в расположение по умолчанию, которым является bin// . Например, если у вас есть приложение netcoreapp2.1 и вы запускаете dotnet run , выходные данные помещаются в bin/Debug/netcoreapp2.1 . При необходимости файлы перезаписываются. Временные файлы помещаются в каталог obj .

Когда в проекте задано несколько платформ, выполнение dotnet run приводит к ошибке, если только для указания платформы не используется параметр -f|—framework .

Команда dotnet run используется в контексте проектов, а не созданных сборок. Если вместо этого вы пытаетесь запустить библиотеку DLL платформозависимого приложения, следует использовать dotnet без команды. Например, для выполнения myapp.dll используйте:

Дополнительные сведения о драйвере dotnet см. в разделе Средства интерфейса командной строки (CLI) .NET.

Для запуска приложения команда dotnet run разрешает зависимости приложения, выходящие за пределы общей среды выполнения, из кэша NuGet. Из-за использования кэшированных зависимостей не рекомендуется применять команду dotnet run для запуска приложений в рабочей среде. Вместо этого создайте развертывание с помощью команды dotnet publish и разверните опубликованные выходные данные.

Неявное восстановление

Вам не нужно выполнять, dotnet restore так как он выполняется неявно всеми командами, которые требуют восстановления, например dotnet new , dotnet build , dotnet run , dotnet test dotnet publish , и dotnet pack . Чтобы отключить неявное восстановление, используйте параметр —no-restore .

Команду dotnet restore по-прежнему удобно использовать в некоторых сценариях, где необходимо явное восстановление, например в сборках с использованием непрерывной интеграции в Azure DevOps Services или системах сборки, где требуется явно контролировать время восстановления.

Сведения об управлении веб-каналами NuGet см. в документации по dotnet restore .

Эта команда поддерживает параметры dotnet restore при передаче в длинной форме (например, —source ). Параметры в краткой форме, например -s , не поддерживаются.

Скачивание манифестов рабочих нагрузок

При выполнении этой команды запускается асинхронное фоновое скачивание оповестительных манифестов для рабочих нагрузок. Если скачивание по-прежнему выполняется по завершении этой команды, оно останавливается. Дополнительные сведения см. в разделе Оповестительные манифесты.

Параметры

• — Отделяет аргументы, предназначенные для dotnet run , от аргументов для выполняемого приложения. Все аргументы после разделителя передаются выполняемому приложению.

• -a|—arch Указывает целевую архитектуру. Это сокращенный синтаксис для настройки идентификатора среды выполнения (RID), где указанное значение объединяется с RID по умолчанию. Например, если на компьютере win-x64 указать —arch x86 , идентификатору RID присваивается значение win-x86 . При использовании этого параметра не используйте параметр -r|—runtime . Этот параметр доступен начиная с выпуска .NET 6 предварительной версии 7.

--property:=;= --property:= --property:=

dotnet run -- --property name=value 

dotnet run --project ./projects/proj1/proj1.csproj 

dotnet run --property:Configuration=Release 

dotnet run --configuration Release -- --help