Разработка net под линукс

Установка пакета SDK для .NET или среды выполнения .NET вручную

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

Также можно установить .NET с помощью пакета Snap. Дополнительные сведения см. в разделе Установка пакета SDK для .NET или среды выполнения .NET с использованием пакета Snap.

Если вы хотите разрабатывать приложения .NET, установите пакет SDK (включает среду выполнения). Если нужно просто запустить приложения, установите среду выполнения. Если вы устанавливаете среду выполнения, мы рекомендуем установить среду выполнения ASP.NET Core, так как она включает в себя среды выполнения .NET и ASP.NET Core.

Если вы уже установили пакет SDK или среду выполнения, с помощью команд dotnet —list-sdks и dotnet —list-runtimes узнайте, какие версии установлены. Дополнительные сведения см. в статье Проверка того, установлена ли платформа .NET.

Выпуски .NET

В следующей таблице перечислены выпуски .NET (и .NET Core):

✔️ Поддерживается	❌ Не поддерживается
5,0	3.0
3.1 (LTS)	2.2
2.1 (LTS)	2,0
1,1
1.0

Дополнительные сведения о жизненном цикле выпусков .NET см. в разделе Политика поддержки .NET Core и .NET 5.

Зависимости

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

Общие сведения о зависимостях см. в статье об автономных приложениях Linux.

Зависимости RPM

Если ваш дистрибутив не указан в приведенном выше списке и построен на основе RPM, могут потребоваться следующие зависимости:

Если в целевой среде выполнения установлена версия OpenSSL 1.1 или более поздняя, необходимо установить compat-openssl10.

Зависимости DEB

Если ваш дистрибутив не указан в приведенном выше списке и построен на основе Debian, могут потребоваться следующие зависимости:

Общие зависимости

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

Вы можете установить последнюю версию libgdiplus, добавив в систему репозиторий Mono. Для получения дополнительной информации см. https://www.mono-project.com/download/stable/.

Установка с помощью скрипта

Сценарии dotnet-install используются для автоматизации установок пакета SDK и среды выполнения и осуществления таких установок без прав администратора. Скрипт можно скачать на странице https://dot.net/v1/dotnet-install.sh.

![ВАЖНО] Для выполнения скрипта требуется Bash.

Этот сценарий по умолчанию устанавливает последнюю версию SDK с долгосрочной поддержкой (LTS), которой сейчас является .NET Core 3.1. Чтобы установить текущий выпуск, который может не быть версией LTS, используйте параметр -c Current .

Чтобы вместо пакета SDK установить среду выполнения .NET, используйте параметр —runtime .

Вы можете установить определенную версию, указав ее в параметре -c . Следующая команда устанавливает пакет SDK для .NET 5.0.

Установка вручную

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

Сначала скачайте двоичный выпуск пакета SDK или среды выполнения с одного из следующих сайтов. При установке пакета SDK для .NET не нужно устанавливать соответствующую среду выполнения:

Затем извлеките скачанный файл и используйте команду export , чтобы задать для переменной DOTNET_ROOT расположение извлеченной папки, а затем проверьте включение .NET в переменную PATH. После этого команды .NET CLI станут доступны в терминале.

Кроме того, после скачивания двоичного файла .NET можно выполнить следующие команды из каталога, в котором сохранен файл, для извлечения среды выполнения. После этого команды .NET CLI также станут доступны в терминале, и будут заданы нужные переменные среды. Обязательно измените значение DOTNET_FILE на имя скачанного двоичного файла:

Приведенные выше команды export сделают команды .NET CLI доступными только для сеанса терминала, в котором производился запуск.

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

Оболочка Bash:

/.bashrc
Оболочка Korn:

/.kshrc или .profile
Оболочка Z:

Измените соответствующий исходный файл оболочки и добавьте :$HOME/dotnet в конец существующего оператора PATH . Если оператор PATH не указан, добавьте новую строку с export PATH=$PATH:$HOME/dotnet .

Кроме того, добавьте export DOTNET_ROOT=$HOME/dotnet в конец файла.

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

Источник

Есть ли под Линукс средства разработки под .NET?

Привет! Я вот хотел бы узнать есть ли под Линукс средства разработки типа Visual Studio, сервер типа ISS, ну и FrameWork? Чтоб можно было создавать приложения так как их создают в Винде?

Re: Есть ли под Линукс средства разработки под .NET?

Re: Есть ли под Линукс средства разработки под .NET?

Иди себе юзай свой «avast! 4 Professional» дальше!

Re: Есть ли под Линукс средства разработки под .NET?

и не забудь почистить реестр, вдруг троян с лора пролез через IE!

Re: Есть ли под Линукс средства разработки под .NET?

Однако знай, что разработка с использованием виндузячих подходов в культуре Unix приравнивается к гомогейству, а смыть позор однократного запуска IIS можно лишь обрядом перекомпилирования GNU Emac/s/.

Re: Есть ли под Линукс средства разработки под .NET?

>а смыть позор однократного запуска IIS можно лишь обрядом перекомпилирования GNU Emac/s/

Нельзя смыть, это смертельный грех, за это маководами делают.

Re: Есть ли под Линукс средства разработки под .NET?

Ты наши статусы сравни, когда будет как у меня тогда вякай. а так хлеборезку держи закрытой.

Источник

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

Подготовка окружения

Для начала, добавим dotnet-репозиторий:

На выходе получаем примерно следующее:

Теперь обновим индекс наших пакетов:

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

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

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

При помощи команды 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.

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

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

и запустите его командой:

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

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

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

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

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

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

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

Назовём его kestrel-test:

И положим в него следующее содержимое:

[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

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

Проверим статус сервиса:

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

Источник

Программирование на .NET в Linux

Часть 1. Обзор возможностей

В последние годы здорово набирает популярность новая технология программирования от Microsoft, названная .NET. И несмотря на то, что в ней нет ничего революционного по сравнению с другими технологиями (взять хоть бы те же Java, Ruby, Perl и пр.), все же это немалый шаг вперед. Неудивительно, что программистам всего мира так понравились новые возможности, предложенные Microsoft. Каждый, кто пишет программу, должен задать себе вопрос: чего он хочет? Применить все свои таланты, чтобы за огромные сроки написать на низкоуровневом языке красивый с точки зрения других программистов код или быстро разработать качественный продукт? Посмотрим правде в глаза: каким бы красивым ни был код, если он ничего толкового не делает или в нем пропала необходимость из-за задержек в разработке. ну, вы меня поняли:-).

Платформа .NET позволяет быстро разрабатывать приложения любой сложности. Среди программистов ходит байка, дескать, некто сравнивал работу на языках С, С++ и C# (.NET). И вышло, что при кодировании на С 30% времени уходило непосредственно на написание текста программы, а 70% — на отладку написанного. В C++ этот показатель был уже 50/50%, а в C# — 70/30%. Что ж, на мой взгляд, это истинная правда. Какое-то время только пользователи MS Windows имели возможность применять такую классную технологию, как .NET. Но Microsoft зарегистрировала свою платформу .NET как стандарт ECMA. Поэтому появилась возможность для сторонних разработчиков реализовать свою собственную платформу, совместимую с MS .NET. Мне известно по крайней мере о двух таких проектах: dotGNU и Mono. Оба разрабатываются сообществом OpenSource, и безусловным лидером среди них является Mono. Именно о Mono и пойдет речь в этой статье. Mono — это открыто разрабатываемая платформа .NET, спонсируемая Novell, UNIX-версия платформы разработки Microsoft .NET. Цель Mono — дать возможность UNIX-разработчикам писать кроссплатформенные приложения .NET. Идея свободной кроссплатформенной реализации .NET принадлежит хакеру Мигелю де Икаца (Miguel de Icaza), он же и выполнил основную часть работы по созданию framework’а. Ранее Мигель занимался разработкой ядра Linux, много сделал для GNOME. А еще, думаю, всем пользователям *nix-платформ известен его файл-менеджер Midnight Commander. Мигеля всегда беспокоила проблема повторного использования кода. В UNIX эта технология была не слишком распространена, и он попытался создать новое решение — компонентную архитектуру Bonobo на основе CORBA. Однако это решение, в чем-то напоминающее COM из MS Windows, было недостаточно эффективным (IMHO, оно устарело еще до своего «рождения», учитывая существование на тот момент Java). Надо отдать должное Мигелю, он признал свою ошибку и взялся за реализацию самой передовой на 2001 год технологии — .NET. Но главная цель, которой он хотел достичь, осталась той же — внести в мир UNIX средства быстрой разработки приложений. На данный момент Mono реализует уже почти все технологии MS .NET, стандартизированные в ECMA. Чтобы не быть голословным, приведу пару примеров реализованных технологий.

1. Common Language Environment (CLR) — основа виртуальной машины .NET. При компиляции программы .NET-компилятор создает код на общем промежуточном языке (Common Intermediate Language — CIL). Во время исполнения CLR транслирует CIL в настоящий процессорный байт-код, что позволяет приложению .NET быть таким же эффективным по скорости, как и традиционные приложения. Для CLR, реализованного в Mono, уже разработано несколько высокоуровневых языков: C#, VB.NET, Java, Nemerlie, Boo.

2. Garbage Collector (GC). Основан на библиотеке сбора мусора Boehm. Эта библиотека работает по старому проверенному алгоритму и ищет объекты без ссылок на них только в памяти, выделенной GC. Это значит, что все объекты, создаваемые в Mono традиционным способом, будут взяты «на карандаш» самой платформой, а за объектами памяти, созданными при помощи malloc, должен следить программист.

3. Кроме самой платформы .NET, в Mono реализованы различные технологии. Среди них — и три наиважнейших: ADO.NET, ASP.NET, Remoting. Список этот можно продолжать долго. Но Mono — это не просто клон MS .NET. Здесь есть свои собственные технологии, библиотеки. Вот несколько компонент Mono, которых нету в MS .NET:

1. Gtk# — привязки к популярной библиотеке графических интерфейсов Gtk. Gtk хороша тем, что она реализована как под UNIX-системы, так и под MS Windows. А это значит, что любое оконное приложение, правильно разработанное под Linux, без изменений и даже без повторной компиляции будет работать и в Windows.
2. Tao Framework — привязки к OpenGL. Думаю, комментариев не требуется: в игры ведь все играли;-)?
3. Mono.Data — поставщики данных для ряда баз данных: PostgreSQL, MySql, Sybase, DB2, SqlLite, Tds (SQL server protocol) и Oracle.
4. Mono.Remoting.Channels.Unix — Remoting, основанный на UNIX-сокетах.
5. Mono.Security — расширенная и улучшенная платформа криптографии.

Чего нет в Mono, что есть в MS .NET? Разработчики Mono посчитали, что некоторые редко используемые технологии реализовывать чересчур накладно или долго. Поэтому часть компонент, реализованных Microsoft, но не стандартизированных в ECMA, решили не разрабатывать. Это, например, Passport и software-as-a-service. Думаю, сюда же нужно добавить и Windows.Forms. На самом деле они, конечно, реализованы в Mono (для UNIX-систем на основе Wine), и притом неплохо. Вот только их реализация от Microsoft меняется чаще, чем погода осенью, и совместимости с ней добиться слишком сложно. Что касается взаимодействия Microsoft и Novell по реализации Mono, то официально его нет. Но неофициально у программистов обеих компаний хорошие отношения, и они часто помогают друг другу. Так, в FAQ’е Mono выражается признательность сотрудникам Microsoft, которые помогли лучше понять стандарт .NET и правильно его реализовать.

Рассказывая о платформе разработки, нельзя не упомянуть о средствах разработки. В Microsoft прекрасно понимают всю важность инструментов для разработчиков и прилагают все усилия, чтобы их Visual Studio была лучшей в мире средой для программистов. И если вы хотите разработать коммерческое приложение .NET, и у вас есть лишних тысячи полторы американских денег на покупку среды разработки, то, безусловно, ваш выбор — MS Visual Studio! Вот только для большинства венчурных проектов такая сумма слишком велика, а штрафы за нелегальное использование MS VS в коммерческих целях грандиозны. Ситуация с Mono совершенно иная. Здесь как платформа, так и среда разработки MonoDevelop совершенно бесплатны и доступны в исходных кодах. Mono можно использовать в любых целях в соответствии с лицензией GPL, по которой она распространяется. Дистрибутив Mono размером примерно 60 Мб поставляется вместе со средой разработки MonoDevelop, документацией, напоминающей MSDN, и массой полезных компонент. Скачать все это можно здесь: сайт

MonoDevelop — уже вполне толковая IDE, внешне очень похожая на MS Visual Studio. Здесь похожее управление проектами, приличный редактор кода с подсветкой и автодополнением, редактор соединений с базами данных и т.д. Однако проект Mono все еще на стадии разработки, и некоторые вещи сделаны не до конца. Так, например, дебагер пока не интегрирован в среду разработки. Впрочем, разработчики Mono клятвенно обещают, что уже скоро он будет встроен в MonoDevelop. Интересная ситуация с визуальным редактором интерфейсов. Проще говоря, его нет. Зато есть компонент, позволяющий строить интерфейсы на основе файлов ресурсов, которые генерирует Glade2.

Кроме того, уже достаточно давно ведется разработка своего собственного редактора интерфейсов Stetic. Он пока доступен только из SVN- репозитория, но, опять же, по обещаниям разработчиков, скоро будет встроен в MonoDevelop. Ну и на закуску расскажу о нескольких проектах, связанных с Mono. X-Develop — коммерческая среда разработки от Omnicore для Mono и JVM. У нее очень красивый интерфейс и масса полезной функциональности. Даже если сравнивать хотя бы редактор кода с аналогичными в тех же MonoDevelop или MS VS, то сразу бросается в глаза, что он умеет несколько больше, чем его конкуренты. В X-Develop так почти все: как у конкурентов, но немножко лучше. Есть даже свой собственный .NET- дебагер, которого так не хватает MonoDevelop’у. Единственное, что меня не очень впечатлило — встроенный редактор интерфейсов. Мне, больше привыкшему к qt-designer’у или Visual Studio, он показался несколько неудобным. На этом перед MonoDevelop преимущества X-Develop заканчиваются, а начинаются перед MS VS. Как уже было сказано, лицензия на Visual Studio стоит больше тысячи «вечнозеленых», а на X-Develop — около $300. При этом политика лицензирования у Omnicore довольно гибкая: так, к Новому году эта цена была на целый месяц снижена до $150; кроме того, есть отдельные виды лицензии для студентов, преподавателей, членов каких-то загадочных организаций и т.д. Короче говоря, самая низкая цена лицензии на X-Develop составляет. $15.

Ну, а тот, кто не уверен, нужна ли ему X-Develop, может воспользоваться ею бесплатно в течение 20 дней в ознакомительных целях. Коммерческих приложений Mono уже достаточно. Но традиционно в мире UNIX отдают предпочтения свободному софту. Пожалуй, лучшим примером OpenSource-приложений Mono будет поисковой движок Beagle от Novell. Думаю, все пользователи Windows наслышаны о тех революционных возможностях, которые будут реализованы в назревающей Windows Vista. Среди них — интеграция интернет-поисковика Microsoft с локальной файловой системой. Но насколько это будет гениально, инновационно и уникально — судить пока рано, т.к. релиза этой ОС еще не было. А поисковик по файловой системе давно есть, правда, не от Microsoft. И, надо сказать, он меня здорово порадовал. Представьте себе эдакий google.com, работающий только по вашему компьютеру! Beagle в фоновом режиме индексирует документы по всем каталогам, на которые он настроен, после чего поиск становится практически мгновенным. А знает он следующие типы документов: файлы электронной почты, логи чат-клиентов и интернет- пейджеров, web-страницы, RSS-ленты, документы Open Office и Microsoft Office разных форматов, документы AbiWord, документы в Rich Text Format, pdf, исходные тексты программ на разных языках, документация в форматах Man Pages, TeX, chm, изображения разных форматов, аудио разных форматов и т.д., и т.п.

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

Дмитрий Бушенко, nop@list.ru

Компьютерная газета. Статья была опубликована в номере 03 за 2006 год в рубрике программирование

Источник